持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第21天，点击查看活动详情
大家好！ 我是慕歌，一只想教你学习 后端技术的野生coder！ 欢迎来到慕歌的数据库系列教程，希望通过这个教程带大家深入学习数据库技术，该教程所有知识点均来源于本人的日常学习与开发中，如有疑问请与我联系！
前言
在上一节的分享中，慕歌向大家分享关于数据库性能分析的知识，对数据的查询性能进行一种概述的评价。这里提供了三种分析方式：慢日志查询分析，执行成本分析，执行计划分析。通过慢日志的分析，可以获取到那些在执行过程中时间消耗非常长的查询语句。对这些语句在进行细致的分析，再进一步获取到那些值得优化的点，最重要的方式是建立索引。
执行成本的分析主要考虑，在CPU，内存，磁盘方向的消耗，这些消耗是底层执行的真实反映，这个层面的问题可以通过调整对服务器进行性能拓展。最后也是对性能分析最关键的工具，explain 分析查询语句，其中有多条指标对查询的性能进行处理。table，id，rows，type 等字段是非常重要的指标，用于分析最真实的执行，对于其中的索引使用情况是有效提升执行的方式。
以上就是对数据库优化方面的知识回顾，一条执行语句的具体性能是怎样的，将所有的执行达到我们需要达到的理想情况。这一节用于探索如何能够在发现问题后，进行相应的优化处理，重点是对索引的分析优化。
优化概述
优化点：
- MYSQL中最有效提升数据访问性能的方式就是为数据表建立合适的索引，索引结构具有极好的数据范围以及顺序查询能力
- 使用索引可以快速定位表中的数据，提高数据查询的数据
- 如果查询时未使用索引就会扫描表中的数据全表扫描
索引失效：
- 全值匹配，对数据进行完整扫描
- 非最左前缀，满足最左前缀能够使用建立的索引
- 主键非顺序插入，数据索引树维护的数据具有有序性
- 函数计算，函数转换导致索引失效
- 多条件匹配的时候，右侧索引列失效
- 模糊匹配以%开始，导致索引失效
关联查询优化：
- 子查询优化，子查询的时候使用临时表将会导致无法使用索引，可通过连接查询进行部分子查询的替代
- 排序优化，在进行where和order by 的时候可以采用带有索引的列，或者在这些列上建立索引，如果能够承受索引建立的代价
- 分组优化，先排序在进行分组，通过最左匹配原则，where语句中能够执行的操作，不要写在having 语句中
- 索引覆盖，在某些索引结构中以及存在部分数据，如果能够利用那部分数据，就可以避免回表操作
- count 函数的定向优化，部分情况下count（*）与count（1）性能一致
- select（）不建议使用，进行解析需要花费时间，并且无法使用覆盖索引
结语
这一节的分享到这里就结束了，下一节将带来数据库事务的分享学习！
如果您觉得本文不错，欢迎点赞支持，您的关注是我坚持的动力！
