問題描述

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

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

表現：

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

此表每日產生的新數據大概在1萬左右，目前有數據近300萬。

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

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

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

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

問題解答

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

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

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

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

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

感謝各位回答，后來發現這個問題的癥結在哪兒了，時間耗在回表操作了。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后面還有其他字段，則需要根據PK去表里找出相應記錄，找出其他字段的值，這就是回表操作了，這個過程很慢。這個應該是屬于IO問題吧？