前言
😊今天给大家总结一下，设计索引需要考虑哪些问题。典型的八股文，新🐒必看呀 ！欢迎大家一键三连呀✌️
设计索引需要考虑哪些问题
查询的频率和数据结构和数量
对于频繁查询的列，并且有一定的数据量，数据的区分度高可以创建索引来加速查询。
比如我们的会员信息，数据量到达了百万级别，但是姓名字段，就两个值，数据高度重合，因此也是没有必要创建索引的。
😍高度重合得数据一定不能创建索引吗？
高度重合的数据需要创建索引的话，就得有充分的理由了。
比如 我的表中有个字段 为status ，值的分布情况是95% 的数据都为1，5% 的数据为2，可能我们后台定时任务每5分钟执行一次，都去扫描 5% 的数据数据，进行更新操作。这种情况我们建一个索引，还是能够通过索引过滤掉大部分数据，查询效率也有很大的提升。
选择适合的索引类型
MySQL提供了多种索引类型，如B+Tree索引、哈希索引和全文索引等。不同类型的索引适用于不同的查询操作，需要根据实际情况选择适合的索引类型。
- B + 树索引：适合处理范围查询和排序操作，能快速定位到符合条件的记录所在的数据页。
- Hash 索引：基于哈希表实现，查找速度快，理论上时间复杂度为 O (1)，适用于等值查询，但不支持范围查询和排序。
- 全文索引：通常采用倒排索引结构，适用于在大量文本数据中进行关键词搜索和模糊查询,维护成本较高，适合更新频率低的数据（实际开发中，常用Elasticsearch代替）
考虑联合索引
联合索引是将多个列组合在一起创建的索引。当多个列一起被频繁查询时，可以考虑创建联合索引。
考虑索引覆盖
联合索引可以通过索引覆盖而避免回表查询，可以大大提升效率，对于频繁的查询，可以考虑将select后面的字段和where后面的条件放在一起创建联合索引。
age: select a,b from where a =1 ,b=2 ；
存在一个 ab 联合索引，此时查询索引就能得到结果集，避免了回表查询
避免创建过多的索引
创建过多的索引会占用大量的磁盘空间，影响写入性能。并且在数据新增和删除时也需要对索引进行维护。所以在创建索引时，需要仔细考虑需要索引的列，避免创建过多的索引。
索引的维护还会带来额外的一些页分裂、页合并等操作，当然也会产生存储碎片👍
避免使用过长的索引，合理设置索引长度
-
索引列的长度越长，索引效率越低。在创建索引时，需要选择长度合适的列作为索引列。对于文本列，可以使用前缀索引来减少索引大小。
-
索引不建议太长，但是也要合理设置，如果设置的太短，比如身份证号，但是只把前面6位作为索引，那么可能会导致大量锁冲突。
👍执行计划分析
复杂的查询，多用执行计划分析，因为随着数据库的数据量变化、索引数量变化，最终使用的索引可能也会偏离预期，所以再复杂的查询中需要看看执行计划，看看是否按照预期的索引查询数据。
走错索引的影响因素
- 不准确的统计信息：如果表中的数据频繁更新、插入或删除，而 MySQL 没有及时更新索引的统计信息，优化器可能会基于过时的统计数据做出错误的索引选择。或者统计时候采样不准确。
- 复杂的查询逻辑：对于复杂的查询，尤其是那些包含多表join、子查询、函数等的查询，优化器可能难以准确判断哪个索引最有效。
- 系统和配置因素：MySQL的配置设置和系统资源限制（如内存不足，cup处理能力不足）也会影响优化器的决策。
- optimizer_switch 参数：该参数用于控制优化器的一些行为和策略，如果设置不当，可能会导致优化器选择错误的索引。
- query_cache_size 参数：查询缓存的大小会影响查询的执行效率和索引的选择。如果查询缓存设置过大，可能会导致缓存命中率下降，增加查询的 I/O 成本。
走错索引如何解决呢
- 优化查询（推荐👍）：简化查询逻辑、调整索引列顺序、创建合适索引比如覆盖索引。
- 优化统计信息：执行
ANALYZE TABLE mytable;手动更新表的统计信息;innodb_stats_sample_pages参数来调整统计信息的采样率. - 使用索引提示：
强制使用指定索引，SELECT * FROM mytable FORCE INDEX (index_name) WHERE...，但这种方法需要谨慎使用，因为可能会导致其他查询性能下降。
忽略指定索引：使用IGNORE INDEX关键字可以让优化器在选择索引时忽略指定的索引，从而避免优化器选择错误的索引 - 调整相关参数，优化器相关参数，内存参数等
总结
本篇文章，总结创建索引之前我们需要考虑哪些问题，以及创建完成之后我们还要去查看执行计划，是否使用我们预期的索引来查询数据。最后也给大家简单阐述了 索引不按照预期执行的情况，以及解决方案。
最近因为在开展活动，所以出了好几篇都是属于八股文类型的文章，活动之后，还是会回归到 实际开发中遇到的问题来写。
