測試是在筆記本上進行的， 伺服器的話應該會快一些， 關鍵欄位的索引也建立了 就是查詢非常慢 ，主要有描述欄位是 區分特性 element， 時間 time 這些建立了索引了 剩下365個欄位是日曆每一天一個欄位，所以有365個欄位 ， 現在沒法變更表結構了 想問下怎麼解決查詢速度慢

------------ 1. 內容補充 ----------------------

以上查詢部分欄位就是這樣一個語句花了11至17秒之間變動

結果5770條，選擇率達到百分之2，不算小，且行太長，先計算這些記錄佔了多少磁碟空間，在結合你io的能力，測算一些17秒是否有優化空間。如果這樣是合理，只有改表結構降低行size一條路，另外where裡面順序無關結果。

都用到like了，還考慮什麼性能。有些東西是可以交給程序來做的，我現在就是這樣開發，sql儘可能的簡單，一些判斷拿到程序裏，db只做一些簡單的數據存儲的動作。畢竟我現在看中的是時間效率

看執行計劃，你這個表，太大，索引欄位只在時間上並不能太大減少你的io。可以給個建議數據量特別大的話可以考慮行轉列，使得數據變為兩列鍵值對形式，提高壓縮比和索引性能？
把需要的提出來，做一個臨時表，加索引，優化sql，提示：你這表設計的不合理。以後有查詢很累！
index3是跟那個where條件有關的索引？調調索引應該能快一些，執行查詢時注意觀察一下cpu和磁碟使用率，目前這個速度可能是索引掃出來的數據太多了
表設計太奇葩

select count(1) from a

查詢記錄數要17秒？

推薦閱讀：
相關文章