emax_task_apply這張表的資料達到了700多萬，系統查詢資料變得慢了起來。這次要對這張表涉及到的sql進行優化。
emax_task_apply現在的索引：
SHOW INDEX FROM emax_task_apply
我一向用SQLyog這個用戶端工具。
如下兩個sql語句，我在SQLyog通過多次執行比較，前者明顯優于後者。
然後，信誓旦旦的告訴同僚：
執行這兩個sql， 比較一下， 性能很明顯
SELECT SQL_NO_CACHE * FROM emax_task_apply WHERE task_id >= 1 AND enterprise_id>=1 AND user_id = 1587702862385631 AND apply_status != 'TASKAPPLY_INVALID';
SELECT SQL_NO_CACHE * FROM emax_task_apply WHERE user_id = 1587702862385631 AND apply_status != 'TASKAPPLY_INVALID';
同僚後來回報說，沒有快到哪裡呀，多次執行比較來看，反而前者比後者還稍慢一些呢。
後來，才發現，同僚是用Navicat Premium 12 做的測試。
怎麼同樣的sql、同樣的db，兩個工具卻存在這樣的差異呢？
再來看他們的執行計劃，2個工具對2個sql的分析結果是一樣的。
我又找另一個同僚，在DataGrip裡執行，發現。。。
看來，“小海豚”SQLyog欺騙了我。
不過，還是不敢相信這個事實。