索引未生效是phpEnv中MySQL查询变慢的主因，EXPLAIN显示type=ALL、key=NULL即为铁证；需重点检查字段类型匹配、WHERE中是否误用函数、联合索引顺序是否合理，而非归咎于环境配置。
phpEnv 里 MySQL 查询变慢，大概率不是配置问题，而是索引根本没被用上——EXPLAIN 显示 type=ALL、key=NULL 就是铁证。
怎么看索引到底有没有生效
在 phpEnv 的 MySQL 客户端或 PHP 中执行带 EXPLAIN 的查询，别只看“建了索引”，重点盯三个字段：
-
key是NULL？说明压根没选索引，直接跳过分析其他字段 -
type是ALL？确认全表扫描；range或ref才算有效利用 -
Extra出现Using filesort或Using temporary？说明排序/分组没复用索引，得调结构
示例：EXPLAIN SELECT * FROM users WHERE name = 'alice';，如果 name 有索引但 key 为 NULL，问题一定出在写法或类型上，不是 phpEnv 环境导致的。
WHERE 里对字段用函数或运算，索引立即失效
哪怕 create_time 上建了索引，WHERE YEAR(create_time) = 2024 也会强制全表扫——B+ 树存的是原始时间值，不是年份。
立即学习“PHP免费学习笔记（深入）”；
- ❌ 错误写法：
WHERE DATE(create_time) = '2024-01-01'、WHERE price * 1.1 > 100、WHERE UPPER(name) = 'ALICE' - ✅ 正确改法：用范围替代函数，如
WHERE create_time >= '2024-01-01' AND create_time ；把运算移到等号右边，如 <code>WHERE price > 90.9 - ⚠️ 注意：MySQL 8.0+ 支持函数索引，但 phpEnv 默认可能装的是 5.7 或 8.0 早期版，别默认它能用
INDEX((YEAR(create_time)))
字符串字段不加引号，隐式转换让索引沉默
这是 phpEnv 环境下最隐蔽的坑：PHP 拼 SQL 时变量没转义或类型不对，比如 $id = 123; $sql = "SELECT * FROM users WHERE sn = $id";，sn 是 VARCHAR，但传进去是数字，MySQL 就会逐行做 CAST(sn AS DOUBLE)，索引失效。
- ❌ 错误：
WHERE sn = 123（无引号）、WHERE mobile = 13812345678 - ✅ 正确：
WHERE sn = '123'、WHERE mobile = '13812345678'；PHP 中用 PDO 参数绑定，天然规避该问题 - ? 验证方法：执行后立刻
SHOW WARNINGS，看到Truncated incorrect DOUBLE value就是隐式转换在作怪
联合索引顺序错、范围查询断链，右边字段全废
比如建了 INDEX idx_status_city (status, city, create_time)，但查询是 WHERE status = 1 AND create_time > '2024-01-01'，city 字段完全用不上，create_time 也仅能用于过滤，无法支持排序。
- ❌ 无效组合：
WHERE city = 'Beijing'（跳过最左列）、WHERE status = 1 AND city > 'A' AND create_time = '2024-01-01'（范围后列失效） - ✅ 有效组合：
WHERE status = 1、WHERE status = 1 AND city = 'Beijing'、WHERE status = 1 AND city = 'Beijing' ORDER BY create_time - ? 实操建议：高频查询中要
ORDER BY的字段，尽量放在联合索引靠右位置；避免把低区分度字段（如status）放在最左，除非它总是和高区分度字段一起查
真正卡住人的，往往不是“要不要建索引”，而是 WHERE 条件怎么写、字段类型怎么对、联合索引字段顺序怎么排——这些细节在 phpEnv 的本地调试环境里最容易暴露，也最容易验证修正。
