問題描述

環(huán)境：DB: mysql 5.7.xxOS: windows server 2012 r2CPU: E3 1220-V5內存: 4G。

數(shù)據(jù)庫配置（基本上是默認配置）：join_buffer_size = 128Msort_buffer_size = 2Mread_rnd_buffer_size = 2M innodb_buffer_pool_size = 128M

表現(xiàn)：

有個表service_log，其中有ID, DIAL_NUMBER, contact_name, contact_result, remark, CREATE_TIME等20多個常規(guī)字段。ID是PK，在contact_name，create_time等列上建有單獨索引。

此表每日產(chǎn)生的新數(shù)據(jù)大概在1萬左右，目前有數(shù)據(jù)近300萬。

有一個查詢，查詢字段較多：select id, dial_number, contact_name ....from service_logwhere create_time between ’2016-10-01’ and ’2016-10-02’

從300萬數(shù)據(jù)中，查詢出近8000條數(shù)據(jù)，耗時大概在40秒左右。查看執(zhí)行計劃，已經(jīng)用了create_time上的索引。

顯然這個效率很難接受，但是索引已經(jīng)用上，實在想不出其他辦法了。

請問除了分區(qū)，還有什么好辦法嗎？

問題解答

innodb_buffer_pool_size 這個太小了改成2G先試試，磁盤和內存的性能差了幾十倍，128M讓你的數(shù)據(jù)操作對磁盤進行了IO, innodb_buffer_pool_size這個加大應該就好好多了這個和索引已經(jīng)沒有關系了，是磁盤io造成的問題，你看看任務管理器的磁盤性能，隨著buffer加大，磁盤負載會下降，這個就和系統(tǒng)內存小會卡一樣，給mysql的內存小也會卡。別的也會造成卡，應該沒有innodb_buffer_pool_size這個明顯回答2：

一次性取到太大的結果集不一定就是好。除了加大對應的配置參數(shù)之外，可以考慮把一條sql查分為N條sql，這個可以具體的自己測試，比如每次取三個小時四個小時這樣試試看得到一個平衡。

并發(fā)高嗎，重復查詢的概率高不高，可以嘗試打開或者關閉查詢緩存。

你要看時間花在哪里，是查找上，還是傳輸上。。。查找的話就說明優(yōu)化沒做好

建立組合索引，最頻繁使用的列放在左邊；查看列的選擇性（即該列的索引值數(shù)量與記錄數(shù)量的比值），比值越高，效果越好。

感謝各位回答，后來發(fā)現(xiàn)這個問題的癥結在哪兒了，時間耗在回表操作了。select id, dial_number, contact_name ....from service_logwhere create_time between ’2016-10-01’ and ’2016-10-02’這個查詢，如果改成這樣：select idfrom service_logwhere create_time between ’2016-10-01’ and ’2016-10-02’速度飛快，因為SELECT 后面只有一個主鍵PK，直接在索引里就能確定每個滿足條件的記錄的ID了。而如果SELECT后面還有其他字段，則需要根據(jù)PK去表里找出相應記錄，找出其他字段的值，這就是回表操作了，這個過程很慢。這個應該是屬于IO問題吧？