索引并非越多越好，需避免单列索引滥用、低区分度字段单独建索引、长文本字段无前缀索引、冗余索引等问题，应基于查询模式设计高选择性联合索引并持续优化。
数据库索引不是加得越多越好，也不是所有字段都适合建索引。设计不当反而拖慢写入、浪费空间、甚至让查询更慢。
盲目为每个 WHERE 字段单独建索引
常见错误是看到 SQL 里有 WHERE a = ? AND b = ?，就分别给 a 和 b 各建一个单列索引。MySQL 通常一次只用一个索引（除非启用 index merge，但效率低且不可控）。正确做法是建立联合索引 (a, b)，顺序很重要：等值查询字段放前，范围查询（如 >、BETWEEN）或排序字段（ORDER BY）放后。例如 WHERE status = 1 AND created_at > '2024-01-01' ORDER BY id，推荐索引为 (status, created_at, id)。
忽略索引列的区分度和数据分布
对低区分度字段（如 gender、is_deleted、state 等只有几个固定值的字段）单独建索引意义很小。MySQL 优化器很可能直接放弃使用该索引，改走全表扫描。可通过 SELECT COUNT(DISTINCT col)/COUNT(*) FROM table 估算区分度（接近 1 表示高区分度）。若必须过滤这类字段，应将其作为联合索引的**后缀列**，配合高区分度字段前置使用。
在 TEXT / BLOB 或过长字符串字段上直接建全文索引以外的索引
MySQL 不允许对未指定长度的 TEXT/BLOB 字段建普通索引；即使对 VARCHAR(1000) 直接建索引，也会因默认索引长度限制（InnoDB 默认 767 字节，utf8mb4 下约 191 字符）而报错或截断。解决方法包括：
• 显式指定前缀长度，如 INDEX idx_title (title(100))（需确认前 100 字符已足够区分）
• 改用生成列（Generated Column）+ 普通索引，例如添加 title_hash CHAR(32) AS (MD5(title)) STORED，再对其建索引
• 真实需要模糊搜索时，才考虑 FULLTEXT 索引，并配合 MATCH ... AGAINST 语法
忽视写操作代价与冗余索引
每新增一个索引，INSERT/UPDATE/DELETE 都要同步更新索引树，尤其在高并发写入场景下，索引越多，性能损耗越明显。同时，重复或覆盖的索引会白占空间、徒增维护成本。例如已有 (user_id, status, created_at)，再建 (user_id, status) 就是冗余的（前者可完全替代后者）。可用 SELECT * FROM sys.schema_redundant_indexes（MySQL 5.7+ Performance Schema）或 pt-duplicate-key-checker 工具识别。
立即学习“PHP免费学习笔记（深入）”；
索引设计本质是读写权衡和查询模式匹配，不是靠经验堆砌，而是结合慢查询日志、EXPLAIN 分析、实际数据分布持续验证和精简的过程。
