数据库索引应服务于高频、高选择性查询，优先在唯一或近似唯一的字段上建立联合索引，按等值→范围→排序顺序排列，控制索引长度，定期清理无效索引。
数据库索引不是加得越多越好，而是要让每一条索引真正服务于高频、高选择性的查询。核心在于理解查询模式、数据分布和索引结构三者的匹配关系。
索引应覆盖高频且过滤性强的 WHERE 条件
只有被 WHERE 子句频繁使用的字段才值得建索引。但更重要的是该字段的选择性——即不同值的数量占总行数的比例。例如用户表中 status 字段若 95% 都是 “active”，即使加了索引，MySQL 也大概率会放弃使用（因为全表扫描更快）；而 email 或 order_no 这类唯一或近似唯一的字段，就是理想索引起点。
- 用 SELECT COUNT(DISTINCT column) / COUNT(*) FROM table 估算选择性，>0.1 可优先考虑
- 复合索引中，把选择性最高的字段放在最左侧（遵循最左前缀原则）
- 避免对低选择性字段（如性别、开关状态）单独建索引
善用联合索引，减少单列索引堆叠
多个单列索引无法协同加速多条件查询，而一个设计合理的联合索引可以同时支撑多个查询场景。比如常见查询：WHERE user_id = ? AND status = ? ORDER BY created_at DESC，最优解是建立 (user_id, status, created_at) 联合索引。
- 顺序按“等值查询 → 最左前缀范围查询 → 排序字段”排列
- WHERE 中出现 user_id = ? AND created_at > ?，则 (user_id, created_at) 有效，但 (created_at, user_id) 无效（因 created_at 是范围，后续字段无法利用）
- 已有 (A,B) 索引时，无需再为 A 单独建索引（除非 A 查询频率极高且 B 值很长，影响索引体积）
注意索引长度与数据类型对性能的影响
过长的索引不仅占用更多磁盘和内存，还会降低写入速度与缓存效率。尤其在 VARCHAR 字段上，盲目建全文索引或不设前缀长度，极易拖慢整体性能。
立即学习“PHP免费学习笔记（深入）”；
- 对 VARCHAR(255) 的 name 字段，通常 INDEX(name(191)) 已足够区分绝大多数值（UTF8mb4 下 191 字节 ≈ 64 个汉字）
- 避免对 TEXT/BLOB 类型直接建普通索引，改用前缀索引或生成哈希字段（如 MD5(email) AS email_hash）辅助查询
- 整数类型优先用 INT/TINYINT 而非 VARCHAR 存储数字，既节省空间又提升索引比较效率
定期审查并清理无效索引
上线后业务变化快，旧索引可能早已无人访问，却持续消耗写入资源。PHP 应用中可通过慢日志 + EXPLAIN 分析，再结合 performance_schema 或 pt-index-usage 工具识别“零命中”索引。
- 执行 SELECT * FROM sys.schema_unused_indexes（MySQL 5.7+）快速定位长期未使用的索引
- ALTER TABLE ... DROP INDEX 之前，先用 SELECT COUNT(*) FROM information_schema.statistics WHERE table_name = 'xxx' AND index_name = 'yyy' 确认索引存在
- 删除索引后观察一周内慢查询数量与 QPS 变化，验证是否真有正向收益
