一、資料庫中的鋪地資料100w，
二、使用到的where條件
三、優化歷程
索引的選擇，因為含有order by，所以後面的字段必須要加到索引裡面，查詢效果：
第一種方式，alter table table_name add index slp_t_ttkd_order_index9(zex_id,order_time);,explain不走檔案掃瞄，查詢結果如下，執行耗時1.4s，不是很理想
第二種方式，alter table table_name add index slp_t_ttkd_order_index9(zex_id,cust_account,order_time); ，explain和查詢的結果跟第一種方式差不多，不理想。
第三種方式，在上面的索引基礎上面新增print_count的字段，alter table table_name add index slp_t_ttkd_order_index9(zex_id,cust_account,print_count,order_time); explain走檔案掃瞄，查詢效率應該不是很高，但是查詢耗時只用了2ms，速度很快，
為什麼呢？加了print_count欄位就很快呢，我看一下print_count這個欄位的資料都是0，於是我here條件中print_count > 0 替換成 print_count >= 0，出現了下面的情況
第四種情況，我把where條件中print_count > 0 替換成 print_count >= 0，索引選擇了其他索引，查詢速度也是很慢。
第五種情況：根據上面的結果，我新增了兩個組合字段索引。alter table table_name add index slp_t_ttkd_order_index9(zex_id,cust_account,order_time);
alter table table_name add index slp_t_ttkd_order_index10(zex_id,cust_account,print_count,order_time);
其中print_count>0的執行效果如下，explain走檔案掃瞄，執行效果很好
另乙個print_count>=0的執行效果如下，explain走index9這個索引，執行效果比較好
總結，mysql優化器，在選擇索引的時候會根據where條件中的字段來判斷是否值得走索引，走索引有的時候不一定會比檔案掃瞄快。
記一次MySQL索引優化
兩張表是主 check drawings 從 check drawings img 關係。check drawings，主表資料 3591條。select count from check drawings 3591 check drawings img，從表資料107203條，資料量並不大，從表通...
一次優化經歷
問題 excel資料匯入，儲存到資料庫中，為了優化查詢效率和其他一些業務需求，需要將資料的一列屬性切分後儲存到redis中，插入資料庫前要保證其中乙個屬性不重複，另外乙個屬性已經在資料庫中。為了將問題描述簡單些，我們假設excel中有兩列資料a和b，其中資料a要保證資料庫中不重複，資料b保證資料庫中...
一次優化記錄
備註 由於隱私 部分使用了偽 偽sql 直接查十點查全部 select from 使用者優惠券表 where 優惠券id in select id from 優惠券表 where 限制 新使用者 and 90天內 總時間40 秒 這裡用exlpain分析 優惠券id是有索引的，但是實際上沒有走索引。...