前言

今天给大家总结一下，设计索引需要考虑哪些问题。典型的八股文，新必看呀 ！欢迎大家一键三连呀✌️

设计索引需要考虑哪些问题查询的频率和数据结构和数量

对于频繁查询的列，并且有一定的数据量，数据的区分度高可以创建索引来加速查询。

比如我们的会员信息，数据量到达了百万级别，但是姓名字段，就两个值，数据高度重合，因此也是没有必要创建索引的。

高度重合得数据一定不能创建索引吗？

高度重合的数据需要创建索引的话，就得有充分的理由了。

比如 我的表中有个字段 为status ，值的分布情况是95% 的数据都为1，5% 的数据为2，可能我们后台定时任务每5分钟执行一次，都去扫描 5% 的数据数据，进行更新操作。这种情况我们建一个索引，还是能够通过索引过滤掉大部分数据，查询效率也有很大的提升。

选择适合的索引类型

MySQL提供了多种索引类型，如B+Tree索引、哈希索引和全文索引等。不同类型的索引适用于不同的查询操作，需要根据实际情况选择适合的索引类型。

考虑联合索引

联合索引是将多个列组合在一起创建的索引。当多个列一起被频繁查询时，可以考虑创建联合索引。

考虑索引覆盖

联合索引可以通过索引覆盖而避免回表查询，可以大大提升效率，对于频繁的查询，可以考虑将select后面的字段和where后面的条件放在一起创建联合索引。

age: select a,b from where a =1 ,b=2 ；

存在一个 ab 联合索引，此时查询索引就能得到结果集，避免了回表查询

避免创建过多的索引

创建过多的索引会占用大量的磁盘空间，影响写入性能。并且在数据新增和删除时也需要对索引进行维护。所以在创建索引时，需要仔细考虑需要索引的列，避免创建过多的索引。

索引的维护还会带来额外的一些页分裂、页合并等操作，当然也会产生存储碎片

避免使用过长的索引，合理设置索引长度

索引列的长度越长，索引效率越低。在创建索引时，需要选择长度合适的列作为索引列。对于文本列，可以使用前缀索引来减少索引大小。

索引不建议太长，但是也要合理设置，如果设置的太短，比如身份证号，但是只把前面6位作为索引，那么可能会导致大量锁冲突。

执行计划分析

复杂的查询，多用执行计划分析，因为随着数据库的数据量变化、索引数量变化，最终使用的索引可能也会偏离预期，所以再复杂的查询中需要看看执行计划，看看是否按照预期的索引查询数据。

走错索引的影响因素不准确的统计信息：如果表中的数据频繁更新、插入或删除，而 MySQL 没有及时更新索引的统计信息，优化器可能会基于过时的统计数据做出错误的索引选择。或者统计时候采样不准确。复杂的查询逻辑：对于复杂的查询，尤其是那些包含多表join、子查询、函数等的查询，优化器可能难以准确判断哪个索引最有效。系统和配置因素：MySQL的配置设置和系统资源限制（如内存不足，cup处理能力不足）也会影响优化器的决策。走错索引如何解决呢优化查询（推荐）：简化查询逻辑、调整索引列顺序、创建合适索引比如覆盖索引。优化统计信息：执行ANALYZE TABLE mytable;手动更新表的统计信息;innodb_stats_sample_pages参数来调整统计信息的采样率.使用索引提示：

强制使用指定索引，SELECT * FROM mytable FORCE INDEX (index_name) WHERE...，但这种方法需要谨慎使用，因为可能会导致其他查询性能下降。

忽略指定索引：使用IGNORE INDEX关键字可以让优化器在选择索引时忽略指定的索引，从而避免优化器选择错误的索引调整相关参数，优化器相关参数，内存参数等总结

本篇文章，总结创建索引之前我们需要考虑哪些问题，以及创建完成之后我们还要去查看执行计划，是否使用我们预期的索引来查询数据。最后也给大家简单阐述了 索引不按照预期执行的情况，以及解决方案。

今天就到这儿呢，如果大家觉得有帮助，投我几票吧！ 感谢！

最近因为在开展活动，所以出了好几篇都是属于八股文类型的文章，活动之后，还是会回归到 实际开发中遇到的问题来写。