Say sqlyog deceived me!

emax_task_apply The data in this table reaches 700 More than ten thousand , The system becomes slow to query data . This time, I'm going to talk about what this table involves sql To optimize .

 

emax_task_apply Now the index ：

SHOW INDEX FROM  emax_task_apply

 

 

 

I always use it SQLyog This client tool .

Here are two sql sentence , I am here SQLyog By performing a comparison multiple times , The former is obviously better than the latter .

then , Swear to tell your colleagues ：

Execute these two sql, Compare the , The performance is obvious

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';

 

 

My colleagues later reported that , No, where are you going , Perform comparison several times to see , On the contrary, the former is a little slower than the latter .

later , Only then discovered , Colleagues use Navicat Premium 12 Test done .

 

How the same sql、 alike db, There is such a difference between the two tools ？

Let's look at their implementation plan ,2 A tool for 2 individual sql The analysis results are the same .

 

 

 

 

 

 

I'm looking for another colleague , stay DataGrip Internal execution , Find out ...

 

It seems ,“ Little dolphin ”SQLyog You lied to me .

however , I still can't believe this fact .

therefore , I put 2 individual sql Put it in the program , stay IDEA Run in testcase, It is found that the test results are consistent with Navicat Agreement .

 

Why is there such a difference , We'll trace it later . Also take this to remind students who encounter the same problem .