云计算服务
服务器租用
DDOS 防护
虚拟主机
域名服务
基础设施
关于我们
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一致。
为什么会有这样的差异呢，以后再追查。也借此给遇到同样问题的同学提个醒儿。
.png)
.png)
