在应用程序开发的早期，数据量很小，开发人员的开发功能更加关注功能实施。随着生产数据的增长，许多SQL声明开始暴露出绩效问题，对生产的影响正在增加。这些问题是整个系统性能的瓶颈。
1.通过缓慢的检查日志以较低的执行效率定位SQL语句
2.解释SQL的执行计划的分析
有必要专注于类型，行，过滤，额外的。
从上到下，效率越来越高
额外的
3.显示个人资料分析
了解SQL执行的线程的状态和时间。
默认值是关闭的，语句“ set propilling = 1;”
4.跟踪
如何选择跟踪分析优化器的执行计划，以及通过跟踪文件，我们可以进一步理解为什么在无需选择Periham执行计划的情况下选择了优惠券。
5.确定问题并采取相应的措施
案例1.左派比赛
指数
SQL语句
从左到右匹配的查询匹配。要使用order_no进行索引，您必须检查携带shop_id或index的条件（shop_id，order_no）
案例2，隐藏转换
指数
SQL语句
矢状转换等效于对索引进行操作，这将使索引失败。摩托车是字符类型。使用数字，它应与字符串匹配，否则MySQL将使用隐藏的替换，从而导致索引故障。
案例3，大分页
指数
SQL语句
对于大型分页方案，您可以优先考虑产品优化需求。如果没有优化，则有两种优化方法。
一种是传递最后一次数据，即上述C，然后执行“ C < xxx”处理，但是这种一般需要改接口协议，并不一定可行。
另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下
案例4、in + order by
索引
SQL语句
in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。
in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。
处理方式，可以(order_status, created_at)互换前后顺序，并且调整SQL为延迟关联。
案例5、范围查询阻断，后续字段不能走索引
索引
SQL语句
范围查询还有“IN、between”
案例6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）
在索引上，避免使用NOT、!=、<>，，！<、!>，不存在，不在，不喜欢等等。
案例7.优化器选择不使用索引
如果访问所需的数据量很少，那么优化器仍将选择辅助索引，但是当访问数据计算整个表中的大部分数据（通常约为20％）时，优化器将选择找到一个聚类索引以查找搜索搜索以查找搜索搜索搜索。
查询所有未付订单，通常此订单很小。即使构建索引，也不能使用索引。
情况8.复杂查询
如果是来自某些数据的统计数据，则可以用来解决该位置。
如果业务上有如此复杂的查询，则可能不建议继续使用SQL，而是以其他方式解决该问题，例如使用ES解决它。
案例9，ASC和DESC混合
混合使用时DESC和ASC会导致指数失败
案例10，大数据
对于推送业务的数据存储，数据量可能非常大。如果选择该方案，最终选择将其存储在MySQL上，并将其保存7天和其他有效期。
因此，应该注意的是，频繁的清洁数据将显示在数据片段中，并且需要与DBA联系以获取数据片段。
PS：防止本文被发现无法找到本文。