場景：一個(gè)表每天新增幾萬數(shù)據(jù)，目前單表總數(shù)據(jù)量在幾百萬數(shù)據(jù)。會(huì)查詢粒度大的統(tǒng)計(jì)數(shù)據(jù)，也會(huì)查詢粒度比較小的數(shù)據(jù)，當(dāng)天更新的數(shù)據(jù)查詢頻率最密，最近幾天的數(shù)據(jù)次之。
隨著數(shù)據(jù)越來越多，數(shù)據(jù)庫的性能開始變低。那么應(yīng)該從哪些角度出發(fā)思考優(yōu)化方案？
1.從時(shí)間特征出發(fā)：看看大約的更新時(shí)間點(diǎn)，在這個(gè)時(shí)間點(diǎn)之前的當(dāng)天數(shù)據(jù)查詢，直接返回“沒有更新”提示，不用查庫；
2.從數(shù)據(jù)特征出發(fā)：
1）熱點(diǎn)數(shù)據(jù)是當(dāng)天的數(shù)據(jù)，所以可以設(shè)立一張當(dāng)天數(shù)據(jù)表，在更新到原表的同時(shí)，也更新到當(dāng)天數(shù)據(jù)表。查當(dāng)天數(shù)據(jù)的時(shí)候就訪問這張表，由于數(shù)據(jù)量更小，所以查詢速度會(huì)更快。第二天將此表清空，再次同步數(shù)據(jù)。但這個(gè)方案的缺陷是數(shù)據(jù)會(huì)冗余，而且萬一要看前幾天的數(shù)據(jù)，那和查前幾個(gè)月的數(shù)據(jù)一樣慢；
2）有時(shí)候需要查詢粒度大的數(shù)據(jù)，所以可以在同步數(shù)據(jù)的同時(shí)，統(tǒng)計(jì)數(shù)據(jù)并存儲(chǔ)起來，加快查詢統(tǒng)計(jì)數(shù)據(jù)的速度；不過也是會(huì)造成數(shù)據(jù)冗余；
3.從查詢優(yōu)化出發(fā)：優(yōu)化sql：
1）減少嵌套子查詢、查詢連續(xù)數(shù)據(jù)時(shí)用between and代替in等；
2）加上索引，但加索引可能會(huì)影響更新效率，用explain執(zhí)行計(jì)劃查看優(yōu)化效率，結(jié)合理論知識(shí)找出權(quán)衡最佳的索引組合；
4.單表數(shù)據(jù)量太大，負(fù)荷過重，會(huì)影響sql執(zhí)行的性能。為了加快查詢和更新速度，最佳的解決方法是分表，可以根據(jù)數(shù)據(jù)的冷熱、更新時(shí)間（數(shù)據(jù)連續(xù)）、某個(gè)的哈希值（數(shù)據(jù)不連續(xù)）來進(jìn)行水平拆分。但要確保每個(gè)單表的數(shù)據(jù)量在一定的范圍內(nèi)；
以上是適合上述場景的優(yōu)化方案，事實(shí)上優(yōu)化處理的方式還有很多，但務(wù)必結(jié)合具體的場景情況分析。