問題描述

數(shù)據(jù)量：數(shù)據(jù)量大約3000w+ ，數(shù)據(jù)大小10g，索引30g，如下圖。

需求：需要比較多的group by 操作和全量數(shù)據(jù)操作。

問題：各種group by 特別慢。

1：嘗試放es，但操作非常不方便。

2：數(shù)據(jù)表分表，成本比較大，從時間和業(yè)務(wù)角度都沒有比較好的分表方案。

3：讀寫分離，分離之后效果提升不大。

4：在嘗試postgresql，但需要業(yè)務(wù)較大的變動，暫未試試。

求存儲或者優(yōu)化方案，最好是存儲在mysql上優(yōu)化，其他存儲介質(zhì)也可以。

問題解答

大表優(yōu)化無非就建索引、數(shù)據(jù)水平切分、豎直切分，該用的你都測了，沒見你把表結(jié)構(gòu)和索引截出來也不好說，索引不要建太多。建議是從業(yè)務(wù)層面上去優(yōu)化，看是否需要分頁，即使是全量數(shù)據(jù)操作，用預(yù)統(tǒng)計是否合適，是否需要冗余字段來讓group by更充分利用索引。

group by 優(yōu)化方案Loose Index Scan和Tight Index Scan 。中文叫做松散索引掃描和緊湊索引掃描具體可以參考官方文檔http://dev.mysql.com/doc/refm...

sphinx 試試？

postgresql對多表關(guān)聯(lián)和count支持速度怎樣？測試的mysql多表關(guān)聯(lián)，慢！索引優(yōu)化確實很關(guān)鍵;還有就是多表關(guān)聯(lián)后的視圖，排序、count分頁等速度更加難以想象。這里想回問下你們怎么解決多表關(guān)聯(lián)、視圖、分頁的問題，看樣索引是真沒少建啊。

該用的你都測試了，全量數(shù)據(jù)操作我也沒想出來什么好的辦法了。對于group by操作，如果是固定的sql（業(yè)務(wù)需要），

1）可以考慮用存儲過程將常用sql的結(jié)果定時生成新表的數(shù)據(jù)。2）將常用的sql字段分拆，再優(yōu)化