话说SQLyog欺骗了我！

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欺骗了我。

不过，还是不敢相信这个事实。

于是，我把2个sql放到程序里，在IDEA里跑testcase，发现测试结果与Navicat一致。

 

为什么会有这样的差异呢，以后再追查。也借此给遇到同样问题的同学提个醒儿。