MySQL性能优化之sql改写案例
案例一：
问题描述
某客户集团反馈某模块崩溃，导致系统异常，系统无法登陆；
关闭该模块浏览模块后，系统才恢复正常且问题重复出现多次。
处理过程
协助排查问题优化过程中发现查询该模块的一个长SQL导致性能问题，其中引发问题的主要原因在下图中的部分SQL片段：
以上SQL中t2.字段在表中存放的为int类型，而子句中的content确为char类型，两个类型不同的字段进行关联比较时，导致索引失效。
修改conten的字段类型为int之后SQL性能恢复正常。
在表设计初期，应将需要进行关联的字段类型设置为同一类型。否则会带来严重的性能问题，后期修改的难度将更大。
案例二：
问题描述
配合客户上线压测期间，发现某接口查询SQL在数据量比较大时性能无法满足客户要求，需进行改造优化
处理过程
该SQL的查询逻辑耗时主要在排序分页上，SQL精简之后的逻辑如下：
优化的思路如下：
类似这种分页+排序的SQL，第一种书写的逻辑，在使用createdate和createtime进行排序时，需要通过主键回表查询带出其他附带的字段信息，
虽然可以利用到索引，但是这种逻辑并非最高效的，尤其再分页越靠后的时候，随着偏移量加大，需要拿到内存中的数据就更多，查询耗时就更久。
而第二种SQL的书写方法，requestid和createdate，createtime字段上均有索引，在进行排序和分页时，只需要检索索引即可完成(MySQL的覆盖索引概念)，
只获取到分页之后的requestid值再与外部表进行inner join，查询速度会极大的提升，并且查询效率不会因为分页靠后而明显下降。
案例三：
问题描述
客户环境数据库CPU出现告警信息，协助进行排查数据库相关问题。
处理过程
通过慢日志分析对数据库的整体性能分析并进行了优化。
此处列举我们程序中常用的一个问题逻辑：
部分SQL片段如下
代码中较多的SQL发现开发人员习惯使用exists逻辑来过滤数据，但是在MySQL中，exists的性能并不是最高的，即使在字段存在索引的情况下，在结结果集比较大情况下，
exists的检索速度远不如inner join的hash连接，而且过多的使用exists容易导致SQL的执行计划异常，而inner join逻辑相对更加直接，简化。
推荐的优先逻辑：join > exists > in
