MySQL索引需精准设计：优先为高频查询字段建单列或联合索引，遵循等值在前、范围在后的顺序；避免冗余索引；写多读少表应克制建索引；注意数据类型、选择性与前缀索引；善用覆盖索引减少回表。
MySQL 索引不是越多越好，关键在“用得准”——要覆盖高频查询条件、避免冗余、兼顾写入成本。设计索引前，先看 WHERE、ORDER BY、GROUP BY 和 JOIN 字段，再结合数据分布和查询模式做取舍。
优先为高频过滤字段建单列或联合索引
WHERE 子句中经常单独出现的字段（如 status、category_id）适合建单列索引；若多个字段总是一起出现（如 WHERE tenant_id = ? AND created_at > ?），应建联合索引，且按“等值条件在前、范围条件在后”的顺序排列。例如：
ALTER TABLE orders ADD INDEX idx_tenant_created (tenant_id, created_at);
这样既能加速等值查询 tenant_id，也能支持 tenant_id + created_at 的范围扫描。
避免冗余索引和过度索引
已有联合索引 (a, b, c)，就无需再建 (a) 或 (a, b) —— 它们已被覆盖。可通过 SELECT * FROM information_schema.statistics 检查重复索引，或用 pt-duplicate-key-checker 工具辅助识别。另外，写多读少的表（如日志表）要克制建索引，否则 INSERT/UPDATE 性能会明显下降。
注意索引列的数据类型与选择性
- 尽量用整型代替字符串做关联字段（如 user_id 用 BIGINT 而非 UUID 字符串），减少索引体积、提升比较效率
- 低选择性字段（如 gender、is_deleted）单独建索引意义不大；但若配合高选择性字段组成联合索引（如 is_deleted, updated_at），仍可能有效
- 对长文本字段需要索引时，使用前缀索引（如 INDEX idx_title (title(100))），但需验证前缀长度是否足以区分大多数值
合理利用覆盖索引减少回表
当 SELECT 的所有字段都包含在索引中（如 INDEX idx_user_status (user_id, status, created_at)，而查询是 SELECT user_id, status FROM t WHERE user_id = ? AND status = ?），MySQL 可直接从索引获取数据，不访问主键 B+ 树，显著提升性能。EXPLAIN 中 Extra = Using index 即表示命中覆盖索引。
