【背景】：
目前经常出现慢 sql 导致的线上问题。
比如，开发的小伙伴优化了索引以后，发上线，结果发现执行的 sql 走了其他的索引，反而导致变慢了。
或者测试环境正常的 sql，在线上的大批量数据下，就开始出现异常。
【解决思路】
所以针对这类问题，应该怎么建立 sql 层的准出标准或者类似的保障机制？
我之前想了下，大概有下面几点，大家帮忙看看有没有什么可以补充的
1、索引变更场景，先用 explain 逐条分析 sql，拿到受影响的 sql，再单条执行 sql 对比执行时间
2、已存在的 sql 优化场景，就执行单条 sql，对比执行时间。
3、新增 sql 场景，同步线上涉及表数据到测试环境，执行 sql 获取执行时间
另外可以想办法 copy 数据库的执行语句，针对 sql 进行压测，随着压力增长或者数据量增长，是否存在性能瓶颈。
我们也遇到了相同的问题
因为 SQL1 存在慢查询，修改索引，测试人员只针对 SQL1 进行压测（sysbench）
但是，导致正常的 SQL2 存在性能问题
针对这种，有没有好的方式可以识别出来？
建立重要 get 接口的性能基线？
huangshengnan
回复
服务层的性能测试我们已经在做了，而且这块如果有风险，线上就可以进行扩容等操作进行处理。
mysql 这块，就没法线上扩容，所以导致出现问题比较棘手
卡丁车卡丁丁
回复
sql1 对应 index1， sql2 对应 index2，本来是没有问题的。
不过可能会出现一种情况就是 index1 修改以后，sql1 查询变快了，不过 sql2 查询 不走原来的 index2 索引，会走 index1 索引，导致 sql2 变慢。
你们如何测试的 sql 性能呀
mysql 和 oracle 优化器都会基于数据分布特征去选择是否走索引、走哪个索引，所以搞清楚业务形态和数据分布特征非常重要，不然无法有效优化
测试的方法很简单：性能基线对比，直接用接口性能压测进行对比就可以了，基线里面有两点：
- sql 所涉及的所有表的数据量的分布情况，分析结果的时候需要参考这种变化，并且深刻理解优化器原理
- 测试结果 (RT) 的值，观测各 sql 在修改前后的响应时间
至于 explain 结果，其实不用那么麻烦去同步数据，请 dba 把线上的 explain 结果导出来给你就行了，你拿测试环境 explain 的结果去比对看一下是否一致，不一致的地方就是开发需要关注甚至优化的地方