面试题学习笔记 | MySQL 调优
MySQL 中的索引数量是否越多越好？为什么？
索引本质上是一种特殊的数据结构，它带来一定的时间和空间开销，因此并不是越多越好。我们可以从时间和空间两个角度来分析：
1. 时间开销：
数据修改操作：每次增、删、改操作都需要更新相关的索引。如果索引过多，更新的地方也越多，尤其是在 B+ 树页分裂和合并等操作下，时间开销会显著增加。
查询优化：MySQL 查询优化器需要选择最优的执行计划。在选择索引时，如果索引数量过多，会导致优化器在计算查询成本时花费更多时间，甚至可能做出错误的选择。
2. 空间开销：
每新增一个二级索引，就需要额外创建一个 B+ 树。如果数据量庞大且索引过多，会消耗大量存储空间。
启示：
在创建索引时，我们应根据实际需求和字段特点进行权衡：
避免盲目创建索引：避免不必要的空间和性能消耗。
慎重处理重复数据：对于重复值多的字段，索引可能无法提升查询效率，因此需要谨慎考虑。
避免对长字段建立索引：长字段会占用较多空间。
考虑字段更新频率：如果写操作多、读操作少，不建议为字段建立索引。
频繁检索的字段可以建立索引：对于经常作为检索条件的字段，尤其是多个字段经常一起查询时，可以考虑建立联合索引。
优化排序、分组、去重操作：对经常出现在
ORDER BY、GROUP BY或DISTINCT后面的字段，可以考虑建立索引以提高效率。
如何使用 MySQL 的 EXPLAIN 语句进行查询分析？
在查询前加上 EXPLAIN，执行后查看输出结果，关注以下几个重要字段：
type（访问类型）
key（实际使用的索引）
rows（扫描的行数）
extra（额外信息）
其中，type 字段尤为关键：
MySQL 中常见的索引结构为 B+ 树，叶子节点存储实际数据。我们通常说索引生效的情况，是指通过 B+ 树的搜索树特性进行查询，这时查询效率较高。以下是常见的 type 值：
system：表只有一行（例如系统表），最优。
const：最多有一行匹配（通常是主键或唯一索引），优化器将其视为常量。
eq_ref：每一行组合最多匹配一行。通常用于主键或唯一索引扫描。
ref：每一行组合可能匹配多行。通常用于非主键或非唯一索引扫描。
range：检索给定范围的行，使用索引选择行。常用于范围查询（如
BETWEEN、< >等）。
当索引未生效时，数据查询通过叶子节点的链表进行遍历，通常会出现以下两种情况：
index：全索引扫描，类似全表扫描，但只遍历索引树，通常比全表扫描更快。
all：全表扫描，最差。
这些是我们在实际使用中需要避免的情况。
如何进行 MySQL SQL 调优？
SQL 调优的核心思想是通过分析慢查询语句，使用 EXPLAIN 来查看执行计划，评估索引使用情况，并识别性能瓶颈，进而进行针对性优化。常见的调优思路包括：
合理设计索引：避免回表操作，减少随机 I/O
避免使用
SELECT *：仅查询必要字段，减少不必要的数据读取避免在查询条件中使用计算：计算操作会导致索引失效，影响查询效率
联合索引遵循最左前缀原则：确保查询条件从左到右与索引字段顺序一致
避免对无索引字段排序：无索引字段排序会导致全表扫描，影响性能
检查表连接时字符集一致性：确保不同表连接时，相关字段字符集一致，避免隐性转换带来的性能问题