当前位置:网站首页>话说SQLyog欺骗了我!

话说SQLyog欺骗了我!

2022-07-07 00:35:00 51CTO

emax_task_apply这张表的数据达到了700多万,系统查询数据变得慢了起来。这次要对这张表涉及到的sql进行优化。

 

emax_task_apply现在的索引:

SHOW INDEX FROM  emax_task_apply

话说SQLyog欺骗了我!_数据

 

 

 

我一向用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的分析结果是一样的。

话说SQLyog欺骗了我!_sql_02

 

话说SQLyog欺骗了我!_ide_03

 

 

 

 

 

我又找另一个同事,在DataGrip里执行,发现。。。

 

看来,“小海豚”SQLyog欺骗了我。

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

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

 

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

原网站

版权声明
本文为[51CTO]所创,转载请带上原文链接,感谢
https://blog.51cto.com/u_15708799/5449045