MySql查询优化

Posted 2021-03-28 草莓酱的Java之旅

      mysql数据库由于其开源性成为当今比较流行的一种选择，掌握一些基础的相关优化还是很有必要的，特别在百万级体量下sql查询，如果处理不好，接口的返回不可能符合TP9999的要求（再往上则得考虑分库分表），接下来说说自己的一些优化经验。

       如果环境上出现接口超时情况，并且服务器一切正常，日志中也打出了相关api信息，并明确的打出了相关慢sql，那么可根据下方的一些步骤排查。

1. 拉出sql在数据库中执行查看执行时间，最好加上sql_no_cache去除缓存影响

2. explain执行计划，可以看sql有没有走上自己预设的索引啊，走上索引之后扫描的行数等等，如下图。这里有个坑，MySQL引擎会自行判断最优路线，有可能他会觉得预设的索引不符合他的最优路线从而导致走不上索引，完全让你摸不着头脑。

         a.建立合理的索引，索引并非越多越好，在MySQL的存储中，索引也是以b树的形式被当做数据存储下来的，过多的索引会加重插入的时间以及内存的压力。为了尽量避免回表的发生，查询过多的绑定字段最好以联合索引的形式存在

         b.遵守相关的匹配原则，譬如like '**%'等还是可以走上索引的

         c.如果出现上述很坑的情况，MySQL无论如何不按照你相应的索引查询，谨慎使用强制索引（慎重）

        d.尽量不使用left join等关联，改为inner join等，关联时字段不使用函数

3. show profile,如果explain执行计划符合你的预期，但是查询依然还是很慢.那建议开启show profile查看sql语句执行相关的资源消耗。

       a.设置profiling参数为on，执行sql语句，show profile 查询sql执行Id

           b.show profile cpu,block io for query id(上述查询ID)，查看sql执            行过程，可以看到一些cpu,以及磁盘io的一些状况。重点关注sending data 这一块消耗时间，它代表了MySQL从磁盘读取数据返回的时间，如果你发现时间过长，io次数很多。那你得看看自己返回字段中是否有大字段（blob，clob）等占用了读取的大量时间，这个方面的优化就不在这里进行阐述。没有大字段的话得返回sql查看自己索引是否有大量回表的可能性。如果这都没有问题，那你可以尝试给服务器换一个固态硬盘。好的硬盘读取效率直接飙升N倍。

              

     4.合理的磁盘刷盘时机，redo log写满后的落盘时机尽量设置的合理，MySQL的读写分离也能大大减少服务器的压力，这点也很有意思，之后可以再讲讲，还有数据的分库分表，如何合理的去设计分的维度这点非常重要，一定要切合业务需求。

      重要的不是我们在何处，而在于我们朝着什么方向走。各位加油。