索引优化的核心在于合理使用索引来提升mysql查询性能。1. 索引不是越多越好，应根据查询模式选择合适字段创建索引；2. b-tree适合范围查询和排序，hash适合等值查询；3. 避免索引失效的常见原因如or条件、like以%开头、在索引列上进行计算、类型不匹配、未遵循最左前缀原则；4. 联合索引顺序应优先放置选择性高的列；5. 使用explain分析执行计划，关注type、key、rows、extra等关键信息；6. 定期使用optimize table或重建索引维护索引效率。通过这些方法可有效提升查询速度并减少资源消耗。
索引优化，说白了就是让mysql更快地找到你想要的数据。创建索引不是越多越好，用对地方才是关键。
索引优化，简单来说，就是让查询更快。最佳实践包括合理创建索引、避免索引失效，以及利用MySQL的查询优化器。
索引类型选择：B-Tree还是Hash？
这个问题其实没有绝对的答案，取决于你的具体场景。B-Tree索引（InnoDB默认）适合范围查询和排序，而Hash索引（Memory引擎默认）适合等值查询。如果你经常需要>、
选择索引类型时，要考虑你的查询模式。另外，也要注意存储引擎的支持情况。InnoDB只显式支持B-Tree索引，而Memory引擎支持Hash和B-Tree。
如何避免索引失效？
索引失效是性能杀手。常见的原因包括：
- 使用OR条件，但OR两边的列没有都建立索引。 这种情况下，MySQL可能会放弃使用索引，全表扫描。
- LIKE查询以%开头。 比如LIKE ‘%abc’就无法使用索引。
- 在索引列上进行计算或函数操作。 比如WHERE YEAR(date_column) = 2023。
- 类型不匹配。 比如索引列是字符串类型，但查询条件是数字类型。
- 联合索引，但查询条件没有使用索引的最左前缀。 比如你创建了INDEX(a, b, c)，但查询条件只有WHERE b = xxx AND c = xxx，就无法使用索引。
- MySQL认为全表扫描比使用索引更快。 这种情况比较少见，但确实存在。比如表很小，或者索引选择性很差。
解决这些问题的方法也很简单：避免使用OR，尽量避免LIKE ‘%abc’，不要在索引列上进行计算或函数操作，保持类型匹配，遵循最左前缀原则。如果MySQL认为全表扫描更快，可以尝试FORCE INDEX强制使用索引，或者优化查询语句。
联合索引的顺序如何确定？
联合索引的顺序非常重要。一般来说，应该把选择性最高的列放在最前面。选择性是指，不重复的索引值与表记录总数的比值。选择性越高，索引的效果越好。
你可以通过select count(DISTINCT column_name) / COUNT(*) FROM table_name来计算列的选择性。
另外，也要考虑查询模式。如果你的查询经常只使用索引的前几列，那么这些列就应该放在联合索引的最前面。
举个例子，如果你有一个用户表，包含country、province、city三个字段，并且经常需要根据这些字段进行查询，那么你可以创建一个联合索引INDEX(country, province, city)。如果country的选择性最高，city的选择性最低，那么这个顺序就是合理的。
如何利用EXPLaiN分析查询语句？
EXPLAIN是MySQL提供的非常有用的工具，可以用来分析查询语句的执行计划。通过EXPLAIN，你可以看到MySQL是否使用了索引，使用了哪个索引，以及查询的性能瓶颈在哪里。
EXPLAIN会返回很多列，其中比较重要的包括：
- type： 表示查询使用了哪种访问类型。常见的类型包括system、const、eq_ref、ref、range、index、ALL。一般来说，type越好，查询性能越高。ALL表示全表扫描，是最差的类型。
- possible_keys： 表示MySQL可以使用哪些索引。
- key： 表示MySQL实际使用了哪个索引。
- key_len： 表示MySQL使用的索引的长度。
- ref： 表示哪些列或常量被用于查找索引列上的值。
- rows： 表示MySQL需要扫描多少行才能找到结果。
- Extra： 包含一些额外的信息，比如是否使用了临时表，是否使用了文件排序等。
通过分析EXPLAIN的结果，你可以找出查询语句的性能瓶颈，并进行优化。比如，如果type是ALL，表示全表扫描，那么你需要考虑添加索引。如果Extra包含using temporary或Using filesort，表示使用了临时表或文件排序，那么你需要优化查询语句或索引，避免这种情况发生。
索引维护：定期优化和重建索引
索引不是一劳永逸的。随着数据的增删改，索引可能会变得碎片化，影响查询性能。因此，需要定期对索引进行维护。
MySQL提供了OPTIMIZE TABLE语句，可以用来优化表。OPTIMIZE TABLE会重新组织表的物理存储，重建索引，消除碎片。但是，OPTIMIZE TABLE会锁表，因此应该在业务低峰期执行。
另外，如果你的表经常进行大量的删除操作，或者索引的碎片化非常严重，那么可以考虑重建索引。重建索引可以使用ALTER TABLE table_name DROP INDEX index_name, ADD INDEX index_name (column_list)语句。重建索引也会锁表，因此也应该在业务低峰期执行。
索引优化是一个持续的过程，需要不断地学习和实践。希望这些建议能帮助你更好地优化mysql索引，提升查询性能。
