目录
问题描述
问题分析
1、了解前后信息
2、分析执行计划
3、分析生产环境系统负载
4、分析数据库性能
5、初步锁定根因为长时间未提交事务导致
6、最终根因定位
7、原理分析
问题描述：
开发反馈执行某条select语句的时候，生产环境和测试环境耗时相差非常大，生产耗时要18S，测试环境耗时不到1秒钟。
问题分析：
1、了解前后信息
a、该SQL是近期新上的
b、生产执行耗时要18S，测试环境耗时不到1秒钟
c、该SQL属于业务人员点击页面发起的查询
d、普通select语句
2、分析执行计划
比较了生产和测试环境的执行计划，执行计划完全相同，比较数据量也相差不大，因此排除执行计划不同导致的耗时差异。
3、分析生产环境系统负载
检查生产环境io、cpu、内存负载情况，系统负载不高，未发现瓶颈。
4、分析数据库性能
a、计算缓冲池命中率，可以达到99.99%，说明数据库内存配置合理
b、检查数据库会话信息，活跃连接数量、连接数使用率不高，未发现瓶颈
c、检查数据库异常会话，依次检查数据库是否有锁等待、长时间未提交事务，发现数据库有一条insert into select 的SQL语句已经执行超过半个月还没有提交，该insert语句中的select子查询为多表关联，其中一张表与耗时慢的SQL涉及的表相同，故怀疑耗时慢的select语句是受到长时间未提交事务影响。
d、查看该慢SQL在主库和从库的执行计划、耗时，发现主从执行计划相同，主库执行耗时18S，从库执行耗时11S，从库执行明显比主库快。
5、初步锁定根因为长时间未提交事务导致
a、手动将长时间未提交事务杀掉
b、再次查看该慢SQL在主库的耗时，发现耗时已经降到11S，和从库一致。至此，已经解决了主从执行耗时不一致的问题。还剩下一个问题，就是生产和测试执行耗时不同。
c、继续分析慢SQL，该select语句用到了group by和order by，并且生产和测试都用到了file sort，去掉order by，发现测试用于排序的行记录数比生产少很多，测试返回给排序的行记录数为几百条，而生产上返回给排序的行记录是几百万行，故生产耗时比测试多也是意料之中。毕竟，测试数据是做过脱敏处理，并且测试和生成数据也有区别。
6、最终根因定位
即长时间未提交事务导致主库对应的select语句性能下降，解决方案为杀掉长时间未提交的事务。
7、原理分析
给大家留个思考，我们下次再展开讨论，大家可以在评论区发表自己的看法。
