加索引不等于快，常见原因包括函数操作、隐式转换、排序方向不匹配、LIKE前导通配符；联合索引需等值字段在前、范围字段靠后；SELECT * 易引发回表，应建覆盖索引；冗余、低效、未使用索引应及时删除。
为什么 WHERE 条件用了索引却还是慢？
常见错觉是“加了索引就一定快”，实际往往因为索引没被真正用上。MySQL 的 EXPLAIN 显示 type=ALL 或 key=NULL 就说明走了全表扫描。典型原因包括：
– WHERE 中对索引字段做了函数操作，比如 WHERE YEAR(created_at) = 2024（created_at 有索引也无效）
– 隐式类型转换，比如字段是 VARCHAR，但查询写成 WHERE user_id = 123（数字没加引号）
– 使用了不匹配的排序方向，如联合索引 (a,b)，查询 ORDER BY a DESC, b ASC 可能无法复用索引排序能力
– LIKE 开头带通配符，WHERE name LIKE '%abc' 无法使用索引前缀
PHP 高并发下联合索引怎么选字段顺序？
联合索引不是字段堆砌，顺序直接影响是否命中和覆盖能力。核心原则是：等值查询字段在前，范围查询字段靠后，排序/分组字段尽量包含在内。例如用户中心高频查询：SELECT * FROM orders WHERE uid = ? AND status IN (1,2) ORDER BY created_at DESC LIMIT 20，最优索引是 INDEX(uid, status, created_at)，而不是反过来。
– uid 是高频等值过滤，放最左
– status 是 IN（MySQL 5.7+ 视为等值集合），可继续利用索引
– created_at 放最后，既支持排序，又避免范围中断索引使用
注意：如果查询中缺失 uid，这个索引大概率不会被选中；不要为了“看起来全面”而建 (uid, created_at, status) 这类顺序，它对 WHERE uid=? AND status=? 有效，但对 ORDER BY created_at 失效
SELECT * 和覆盖索引之间有什么代价差？
高并发场景下，SELECT * 是性能隐形杀手。即使 WHERE 走了索引，如果索引不包含所有 SELECT 字段，MySQL 还要回表（type=ref 但 Extra=Using where; Using index condition），在 QPS 上千时 IO 压力陡增。解决方案是设计覆盖索引：
– 明确业务只需要哪些字段，比如订单列表只读 id, uid, amount, status, created_at
– 建索引时把它们全包进去：INDEX(uid, status, created_at, id, amount)（注意：id 是主键，自动包含，但显式写出更可控）
– 避免在索引里塞大字段（TEXT、长 VARCHAR），会显著增大 B+ 树体积，降低缓存命中率
– PHP 中用 PDO 或 MySQLi 时，务必写明确字段名，别依赖 fetch(PDO::FETCH_ASSOC) + *，否则后续加字段或改结构容易引发意外回表
什么时候该删索引而不是加索引？
线上表索引越多，并发写入越慢——每个 INSERT/UPDATE/DELETE 都要同步更新所有相关索引。观察 information_schema.STATISTICS 或用 sys.schema_unused_indexes（MySQL 8.0+）可发现长期未被使用的索引。重点删：
– 单字段索引与联合索引前缀重复，如已有 INDEX(a,b,c)，再建 INDEX(a) 没意义
– WHERE 条件几乎不出现的字段索引，比如 is_deleted（只有 0/1）且查询极少带该条件
– 低选择性字段上的索引，比如 gender，优化器大概率直接放弃
– PHP 批量导入逻辑中临时建的索引，任务结束后没清理
立即学习“PHP免费学习笔记（深入）”；
索引优化不是一锤子买卖，它高度依赖真实查询模式和数据分布。上线前用慢查日志 + EXPLAIN 验证每条核心 SQL，比凭经验建十个索引更管用。最容易被忽略的是：索引统计信息过期（ANALYZE TABLE 不自动触发），会导致优化器选错执行计划，尤其在大批量导入后。
