mysql中修改索引的正确方法是删除旧索引并创建新索引，因为mysql不支持直接修改索引结构；1. 创建索引可通过create index或alter table add index实现，用于加速数据检索；2. 删除索引使用drop index或alter table drop index，操作前需评估对查询性能的影响；3. 修改索引需先删除再重建，例如将单列索引改为复合索引；4. mysql支持多种索引类型，包括b-tree（适合范围查询和最左前缀匹配）、哈希（适用于等值查询）、全文索引（用于文本搜索）和空间索引（用于地理数据）；5. 创建索引应避免常见误区，如“索引越多越好”、忽略列选择性、违反最左前缀原则、在where子句中对列使用函数等；6. 实战技巧包括分析高频查询、使用explain优化sql、构建覆盖索引、使用短索引、定期维护索引和权衡读写性能；7. 诊断索引性能问题可通过慢查询日志、explain深度解读、show index、analyze table等工具进行；8. 日常维护应定期审查索引、避免过度索引、监控磁盘空间、关注mysql版本更新并合理设计主键。
MySQL中修改索引，实际上更多的是一种“重建”或“调整”过程，而非像修改普通字段那样直接。通常我们会通过删除现有索引，然后根据新的需求重新创建，或者直接利用ALTER TABLE语句来添加、删除或改变索引的属性。创建索引则相对直接，可以通过CREATE INDEX或ALTER TABLE ADD INDEX命令来完成，而所谓的“更新”操作，也正是围绕着这些增删改查索引结构的过程进行的。
解决方案
在MySQL中，对索引的操作主要围绕着创建、删除以及间接的“修改”展开。理解这些操作，是优化数据库性能的关键一步。
创建索引： 这是最常见的操作，为表的特定列或多列组合创建索引，以加快数据检索速度。
-
使用CREATE INDEX语句： 这种方式可以为已存在的表创建索引。
CREATE INDEX idx_user_name ON users (username);
这里，idx_user_name是索引的名称，users是表名，username是需要创建索引的列。
-
使用ALTER TABLE ADD INDEX语句： 这是更推荐的方式，因为它在修改表结构的同时添加索引，更符合数据库管理的操作习惯。
ALTER TABLE products ADD INDEX idx_product_category (category_id);
你也可以创建唯一索引来确保列值的唯一性，这在业务层面非常有用，比如用户ID、商品SKU等。
ALTER TABLE users ADD UNIQUE INDEX uniq_user_email (email);
复合索引（多列索引）同样重要，它能覆盖更复杂的查询条件。
ALTER TABLE orders ADD INDEX idx_order_status_time (order_status, order_time);
这种情况下，索引会先按照order_status排序，再在相同order_status下按照order_time排序。
删除索引： 当索引不再需要、或者需要调整其结构时，就需要删除它。
-
使用DROP INDEX语句：
DROP INDEX idx_user_name ON users;
-
使用ALTER TABLE DROP INDEX语句： 同样，这是更常用的方式。
ALTER TABLE products DROP INDEX idx_product_category;
删除索引后，依赖该索引的查询可能会变慢，所以操作前务必评估影响。
修改索引（重建）： MySQL没有一个直接的MODIFY INDEX命令来改变索引的列或类型。如果需要修改一个索引（例如，从单列索引变成复合索引，或者改变索引的类型），标准的做法是：
- 删除旧索引。
- 创建新索引。
例如，如果你想把idx_product_category从单列索引变成category_id和brand_id的复合索引：
ALTER TABLE products DROP INDEX idx_product_category; ALTER TABLE products ADD INDEX idx_product_category_brand (category_id, brand_id);
这个过程在生产环境中需要特别小心，因为删除和创建索引都可能导致表锁定，影响线上服务。对于大表，这可能是一个耗时的操作。MySQL 8.0及更高版本支持ALGORITHM=INSTANT或INPLACE等选项，可以在某些情况下减少锁定时间，但并非所有操作都支持。
mysql索引的分类与选择：B-Tree、哈希、全文索引，何时派上用场？
当我们谈论MySQL索引时，最核心的莫过于理解其背后的数据结构和适用场景。这不仅仅是技术细节，更是我们如何根据业务查询模式来选择“对的工具”的关键。
B-Tree索引： 这是MySQL中最常见、也是默认的索引类型，几乎所有的存储引擎（InnoDB, MyISAM等）都支持。它的特点是数据有序存储，非常适合范围查询（如WHERE price BETWEEN 100 AND 200）、排序（ORDER BY）、以及最左前缀匹配。比如，你有一个复合索引(col1, col2, col3)，那么查询条件中只用到col1，或者col1, col2，甚至col1, col2, col3，都能有效利用这个索引。但如果只查询col2或col3，索引就失效了。这就像一本按姓氏、名字、中间名排序的电话簿，你可以很快找到“张三”，但如果只知道“三”，就得翻遍了。
哈希索引（Hash Index）： 主要用于Memory存储引擎，以及在某些情况下，InnoDB内部会使用自适应哈希索引。它的特点是查找速度极快，因为它直接通过哈希算法计算出数据行的物理地址。然而，哈希索引只支持精确匹配（=或IN），不支持范围查询、排序，也无法利用最左前缀匹配。想象一下，你有一堆文件，每个文件都贴了一个唯一的哈希标签，你可以瞬间找到标签为“XYZ”的文件，但你无法快速找到标签在“A”到“M”之间的所有文件。因此，如果你需要频繁进行精确查找，且对范围查询和排序没有要求，哈希索引可能是一个不错的选择。
全文索引（FULLTEXT Index）： 这是专门为文本搜索设计的，比如你希望在文章内容中搜索某个关键词。它允许你进行模糊匹配、词语组合搜索等，而不仅仅是简单的LIKE ‘%keyword%’。LIKE查询通常会导致全表扫描，性能极差。全文索引则通过构建倒排索引来实现高效的文本搜索。如果你正在构建一个博客系统、知识库或任何需要大量文本搜索功能的应用，全文索引是不可或缺的。
空间索引（SPATIAL Index）： 如果你处理的是地理空间数据，比如存储地图上的点、线、多边形等，那么空间索引就派上用场了。它允许你进行基于地理位置的查询，例如查找某个区域内的所有咖啡馆。这在LBS（location Based Services）应用中非常常见。
选择策略：
- 大部分OLTP（在线事务处理）系统： 优先考虑B-Tree索引。它通用性强，能满足大部分查询需求。
- 精确查找多、范围查询少： 如果你的表主要进行等值查询，且数据量大，可以考虑哈希索引（如果存储引擎支持）。
- 文本内容搜索： 毫无疑问，使用全文索引。
- 地理位置数据： 必须使用空间索引。
我的经验是，不要盲目添加索引。每一个索引都会占用存储空间，并且在数据写入（INSERT, UPdate, delete）时带来额外的开销。所以，核心原则是“按需创建，适度优化”。
构建高效MySQL索引：避免常见误区，提升查询性能的实战技巧
索引的创建并非越多越好，也不是随便一加就能提升性能。很多时候，不恰当的索引反而会成为性能瓶颈。这里我总结了一些常见的误区和实战技巧，希望能帮助大家更有效地利用索引。
常见误区：
- “索引越多越好”的误区： 这是最常见的误区。索引虽然能加速查询，但它会增加写操作（INSERT, UPDATE, DELETE）的开销，因为每次数据变动，索引也需要同步更新。同时，过多的索引会占用大量磁盘空间，并可能导致优化器选择错误的执行计划。
- 不考虑列的“选择性”（Cardinality）： 选择性是指列中不重复值的比例。如果一个列的重复值非常多（比如性别字段，只有男/女），那么为其创建索引的意义就不大，因为即使通过索引定位，也可能要扫描大量数据行。高选择性的列（如用户ID、邮箱）才更适合创建索引。
- 复合索引的“最左前缀原则”理解偏差： 很多开发者知道最左前缀原则，但在实际使用中却容易忽略。如果一个复合索引是(a, b, c)，那么只有查询条件从a开始（a、a, b、a, b, c）才能有效利用索引。查询b, c或只查询c是无法利用这个索引的。
- 对LIKE ‘%keyword%’的误解： 很多人以为LIKE查询能走索引，但只有LIKE ‘keyword%’（以固定字符串开头）才能利用B-Tree索引。如果%在前面或者两边都有，索引就失效了，会进行全表扫描。
- 在WHERE子句中对列进行函数操作： 如果你在WHERE条件中对索引列使用了函数（如WHERE DATE(create_time) = CURDATE()），那么即使create_time列有索引，也会导致索引失效，因为索引存储的是原始值，函数操作后值已经改变。
- 不使用EXPLAIN分析查询： 很多时候，我们凭感觉加索引，但实际效果如何，只有EXPLAIN能告诉你。它是诊断SQL查询性能的利器，能显示MySQL如何执行查询，是否使用了索引，使用了哪个索引，扫描了多少行等关键信息。
实战技巧：
- 分析查询模式： 在创建索引之前，先收集和分析你的应用程序中最频繁、最耗时的查询语句。索引应该服务于这些高频查询。
- 利用EXPLAIN进行性能调优： 这是一个核心技巧。每次怀疑SQL慢，或者加了索引想看效果，都应该EXPLAIN一下。通过观察type（访问类型）、rows（扫描行数）、Extra等字段，可以判断索引是否生效以及查询效率如何。
EXPLAIN select * FROM users WHERE username = 'zhangsan';
- 覆盖索引（Covering Index）： 如果一个索引包含了查询所需的所有列，那么MySQL可以直接从索引中获取数据，而无需回表（即无需再访问数据行），这能极大提升查询性能。例如，SELECT username, email FROM users WHERE id = 123，如果有一个id, username, email的复合索引，那么这个查询就可以完全由索引覆盖。
- 短索引（Prefix Index）： 对于很长的字符串列（如URL、描述），可以只对列的前缀创建索引，以节省空间并提高效率。
ALTER TABLE articles ADD INDEX idx_article_title_prefix (title(20)); -- 只对title前20个字符创建索引
但要注意，前缀长度要足够保证选择性。
- 定期维护索引： 随着数据的增删改，索引可能会变得碎片化，影响性能。定期使用ANALYZE TABLE更新统计信息，以及OPTIMIZE TABLE（对MyISAM表有效，InnoDB表通常不需要，或者可以通过ALTER TABLE tbl_name ENGINE=InnoDB;来重建表）来整理碎片。
- 考虑业务场景的平衡： 索引是读写性能的权衡。对于读多写少的表，可以适当多加索引；对于写多读少的表，则要严格控制索引数量。
- 区分聚簇索引和非聚簇索引（InnoDB）： InnoDB表的数据是按照主键（聚簇索引）的顺序存储的。所有二级索引都会存储主键值，并通过主键来查找实际数据行。这意味着主键的选择对性能至关重要，一个设计良好的主键能减少二级索引的回表操作。
如何诊断MySQL索引性能问题并进行日常维护？
索引的性能并非一劳永逸，随着数据量的增长和查询模式的变化，原本高效的索引也可能变得低效。因此，定期诊断和维护是数据库管理的重要组成部分。
诊断索引性能问题：
-
慢查询日志（Slow Query Log）： 这是诊断性能问题的首要工具。MySQL的慢查询日志会记录执行时间超过long_query_time阈值的sql语句。通过分析这些日志，你可以找出哪些查询没有充分利用索引，或者索引选择不当。
- 开启慢查询日志：在my.cnf中配置slow_query_log = 1和long_query_time = 1（或更低）。
- 分析工具：可以使用mysqldumpslow或Percona Toolkit的pt-query-digest等工具来分析慢查询日志，它们能帮你汇总、排序，找出最慢的查询。
-
EXPLAIN语句的深度解读： 之前提到过EXPLAIN，但这里要强调的是深度解读。
-
SHOW INDEX FROM table_name： 这个命令可以显示一个表的所有索引信息，包括索引名称、列名、是否唯一、基数（Cardinality）等。通过检查基数，可以初步判断索引的选择性。如果一个索引的基数远低于表的总行数，那么它的效率可能不高。
-
ANALYZE TABLE table_name： 这个命令会分析表的键分布，并存储统计信息。MySQL查询优化器会利用这些统计信息来决定如何执行查询。当表的数据发生大量变动（增删改）后，索引的统计信息可能会变得不准确，导致优化器做出错误的判断，这时就需要重新分析。
日常维护：
- 定期审查索引： 随着业务发展，查询模式会改变。每年或每半年，对核心业务表进行一次索引审查，移除不再使用的索引，优化现有索引，或添加新的索引以适应新的查询需求。
- 避免过度索引： 记住，每个索引都是有成本的。在添加新索引前，务必评估其必要性。一个好的经验法则是，一个表上的索引数量通常不应超过5-7个（这只是一个经验值，具体取决于表的大小和查询模式）。
- 监控磁盘空间： 索引会占用磁盘空间。定期检查数据库的磁盘使用情况，尤其是在创建了大量索引后。
- 关注MySQL版本更新： MySQL的每个新版本都可能带来索引优化或新的索引特性。例如，MySQL 8.0引入了降序索引（Descending Indexes）和表达式索引（Functional Indexes），这些都能帮助解决特定的性能问题。
- 主键设计的重要性： 对于InnoDB表，主键就是聚簇索引。一个设计良好的主键（如自增ID、UUID等）能极大地影响二级索引的性能。避免使用随机性太高或过长的字符串作为主键。
总之，索引管理是一个持续的过程，它需要我们对业务有深入的理解，并结合实际的数据库性能数据来做出决策。没有一劳永逸的解决方案，只有不断地观察、分析和调整。
