主题
面试速答（先看这里）
**一句话结论：**对于频繁查询的列，可以创建索引来加速查询，但对于不经常查询或者数据量较少的列，可以不创建索引。
60秒标准回答：
考虑查询的频率和效率 ：在决定创建索引之前，需要分析查询频率和效率
对于频繁查询的列，可以创建索引来加速查询，但对于不经常查询或者数据量较少的列，可以不创建索引
选择适合的索引类型 ：MySQL提供了多种索引类型，如B+Tree索引、哈希索引和全文索引等
**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点
**记忆锚点：**避免创建过多的索引 → 考虑联合索引 → 际情况选择适合的索引 → 度不高的字段作为索引 → 组合在一起创建的索引 → 放在一起创建联合索引
关键取舍：
- 不同类型的索引适用于不同的查询操作，需要根据实际情况选择适合的索引类型。
- 避免创建过多的索引 ：创建过多的索引会占用大量的磁盘空间，影响写入性能。
易错提醒：
- 考虑区分度： 尽量不要选择区分度不高的字段作为索引，比如性别。
- 考虑索引覆盖： 联合索引可以通过索引覆盖而避免回表查询，可以大大提升效率，对于频繁的查询，可以考虑将select后面的字段和where后面的条件放在一起创建联合索引。
加分表达：
- 但是也并不绝对，对于一些数据倾斜比较严重的字段，虽然区分度不高，但是如果有索引，查询占比少的数据时效率也会提升。
- 合适的索引长度 ：虽然索引不建议太长，但是也要合理设置，如果设置的太短，比如身份证号，但是只把前面6位作为索引，那么可能会导致大量锁冲突。
追问准备：
- 围绕「避免创建过多的索引」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「考虑联合索引」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「际情况选择适合的索引」：底层原理是什么？使用时有哪些边界和常见坑？
- 如果线上出现异常，你会如何定位、验证并规避？
典型回答
考虑查询的频率和效率：在决定创建索引之前，需要分析查询频率和效率。对于频繁查询的列，可以创建索引来加速查询，但对于不经常查询或者数据量较少的列，可以不创建索引。
选择适合的索引类型：MySQL提供了多种索引类型，如B+Tree索引、哈希索引和全文索引等。不同类型的索引适用于不同的查询操作，需要根据实际情况选择适合的索引类型。
**考虑区分度：**尽量不要选择区分度不高的字段作为索引，比如性别。但是也并不绝对，对于一些数据倾斜比较严重的字段，虽然区分度不高，但是如果有索引，查询占比少的数据时效率也会提升。
考虑联合索引：联合索引是将多个列组合在一起创建的索引。当多个列一起被频繁查询时，可以考虑创建联合索引。
**考虑索引覆盖：**联合索引可以通过索引覆盖而避免回表查询，可以大大提升效率，对于频繁的查询，可以考虑将select后面的字段和where后面的条件放在一起创建联合索引。
- 避免创建过多的索引：创建过多的索引会占用大量的磁盘空间，影响写入性能。并且在数据新增和删除时也需要对索引进行维护。所以在创建索引时，需要仔细考虑需要索引的列，避免创建过多的索引。
避免使用过长的索引：索引列的长度越长，索引效率越低。在创建索引时，需要选择长度合适的列作为索引列。对于文本列，可以使用前缀索引来减少索引大小。
合适的索引长度：虽然索引不建议太长，但是也要合理设置，如果设置的太短，比如身份证号，但是只把前面6位作为索引，那么可能会导致大量锁冲突。
执行计划分析：多用执行计划分析，因为随着数据库的数据量变化、索引数量变化，最终使用的索引可能也不太一样，所以需要经常查看索引是否有使用对。