合理设计索引可提升MySQL查询性能，应为WHERE、JOIN、ORDER BY等常用字段建立索引，优先选择高选择性字段；善用复合索引并遵循最左前缀原则，避免在索引字段上使用函数、隐式转换或前导通配符导致失效；通过覆盖索引减少回表，利用EXPLAIN分析执行计划，定期清理未使用或冗余索引，以降低写入开销和存储占用。
在 MySQL 中，索引是提升查询性能的核心手段。合理使用索引可以大幅减少数据扫描量，加快检索速度。但索引不是越多越好，设计不当反而会影响写入性能和存储效率。下面从实际应用角度介绍 MySQL 索引的优化方法和使用技巧。
选择合适的字段创建索引
并不是所有字段都适合加索引。通常应为以下类型的字段建立索引：
- 频繁出现在 WHERE 条件中的字段：比如 user_id、status、created_at 等常用于过滤的列。
- 用于 JOIN 关联的字段：如外键字段，连接查询时能显著提升效率。
- 需要排序或分组的字段（ORDER BY / GROUP BY）：如果某个字段经常用于排序，为其建立索引可避免额外的文件排序操作。
相反，低基数字段（如性别、是否删除等只有几个值的字段）通常不适合单独建索引，因为选择性太差，优化器可能直接忽略索引。
善用复合索引，避免冗余单列索引
复合索引（联合索引）是指对多个字段一起建立的索引。它的使用遵循最左前缀原则：查询条件必须包含索引的最左边连续列才能生效。
例如，建立了索引 (user_id, status, created_at)，以下查询可以命中索引：
- WHERE user_id = 1
- WHERE user_id = 1 AND status = 'active'
- WHERE user_id = 1 AND status = 'active' ORDER BY created_at
但如果只查 status 或 created_at，这个复合索引就无法使用。
建议：将最常用作筛选条件的字段放在索引左侧，选择性高的字段优先。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
避免索引失效的常见写法
即使有索引，错误的 SQL 写法也会导致索引无法使用：
- 在索引字段上使用函数或表达式：WHERE YEAR(created_at) = 2024 会让索引失效，应改为 WHERE created_at >= '2024-01-01' AND created_at 。
- 隐式类型转换：比如字符串字段被数字比较，WHERE name = 123 可能触发类型转换，导致索引失效。
- 使用 LIKE 以通配符开头：LIKE '%keyword' 无法利用索引，而 LIKE 'keyword%' 可以。
- OR 条件中部分字段无索引：可能导致全表扫描，可用 UNION 优化。
利用覆盖索引减少回表
覆盖索引是指查询的所有字段都在索引中，无需回到主表获取数据（即“回表”）。这能显著提升性能。
例如，索引 (user_id, status)，执行：
SELECT user_id, status FROM users WHERE user_id = 1;可以直接从索引中获取结果，不需要访问数据行。
建议：对于高频查询，考虑创建包含查询字段的复合索引，实现覆盖索引。
定期分析和优化索引
随着业务变化，部分索引可能不再被使用，甚至成为负担。可以通过以下方式维护：
- 使用 EXPLAIN 分析 SQL 执行计划，查看是否走索引、是否有临时表或文件排序。
- 通过 performance_schema 或 sys.schema_unused_indexes 查看未使用的索引。
- 定期清理冗余或无效索引，减少写入开销和存储占用。
基本上就这些。掌握索引的设计原则和常见陷阱，能让 MySQL 查询更高效。关键在于理解查询模式，结合执行计划不断调整，而不是盲目添加索引。
