标签：SQLyog task emax sql apply 欺骗 id

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。