话说SQLyog欺骗了我!
作者:互联网
emax_task_apply这张表的数据达到了700多万,系统查询数据变得慢了起来。这次要对这张表涉及到的sql进行优化。
emax_task_apply现在的索引:
SHOW INDEX FROM emax_task_apply
我一向用SQLyog这个客户端工具。我在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一致。
为什么会有这样的差异呢,以后再追查。也借此给遇到同样问题的同学提个醒儿。
标签:SQLyog,task,emax,sql,apply,欺骗,id 来源: https://www.cnblogs.com/buguge/p/15154042.html