索引失效本质是SQL写法不满足优化器使用条件，而非phpEnv环境导致；最常见原因是WHERE中对索引列使用函数（如DATE、YEAR）、隐式类型转换或违反最左前缀原则。
索引在 phpEnv 环境下不会“自动失效”，真正失效的是你写的 SQL —— phpEnv 只是把 PHP 和 MySQL（或 MariaDB）打包在一起，底层执行逻辑和标准 MySQL 完全一致。所有索引是否生效，取决于查询语句是否满足数据库优化器的索引使用条件。
WHERE 中对索引列用函数（如 DATE()、YEAR()、UPPER()）
这是最常见也最容易被忽略的失效点。MySQL 无法在 B+ 树上直接计算函数结果，只能放弃索引走全表扫描。
- 失效写法：
WHERE DATE(created_at) = '2024-01-01'、WHERE YEAR(created_at) = 2024、WHERE UPPER(name) = 'ADMIN' - 正确写法：改用范围表达式或前缀匹配，例如
WHERE created_at >= '2024-01-01' AND created_at 、<code>WHERE name LIKE 'admin%' - phpEnv 中无特殊处理，但本地开发时容易忽略
EXPLAIN验证——务必在 phpMyAdmin 或命令行里执行EXPLAIN SELECT ...看type是否为ref/range，而非ALL
LIKE 查询以 % 开头（如 LIKE '%关键词'）
前导通配符破坏了 B+ 树的有序前缀匹配能力，数据库无法定位起始位置，只能扫全表。
- 失效场景：
WHERE title LIKE '%搜索'、WHERE name LIKE '%张三%' - 可走索引的写法：
WHERE title LIKE 'PHP%'、WHERE name LIKE '张%' - 若必须做全文模糊，不要硬扛：
FULLTEXT索引 +MATCH() AGAINST()更可靠；phpEnv 默认支持，但需手动建索引并确认存储引擎为 InnoDB（MyISAM 的 FULLTEXT 行为不同）
联合索引未满足最左前缀原则（如 (a,b,c) 却只查 b = ?）
phpEnv 自带的 MySQL 版本（通常是 5.7/8.0）严格遵循该规则。跳过左侧字段，右侧字段索引即失效。
立即学习“PHP免费学习笔记（深入）”；
- 失效示例：
WHERE b = 2 AND c = 3（a未出现）、WHERE a = 1 AND c = 3（b被跳过） - 有效使用：
WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b > 10 AND c = 5（注意：c在b为范围查询时不参与索引查找） - php 中拼接 WHERE 条件时，建议按索引定义顺序组织参数，避免动态 SQL 因缺失左侧字段导致隐性退化
隐式类型转换（如字符串字段传入数字、INT 字段传入字符串）
phpEnv 里 MySQL 的字符集和类型校验和线上环境完全一致。一旦发生隐式转换，等价于对索引列加函数，索引立即失效。
- 典型错误：
WHERE user_id = 123（user_id是VARCHAR）、WHERE phone = 13800138000（phone是VARCHAR） - 安全写法：统一用字符串传参，PDO 绑定时显式指定
PDO::PARAM_STR，或手写 SQL 时加引号：WHERE user_id = '123' - phpEnv 的 phpMyAdmin 有时会自动补引号，但 CLI 或 PHP 脚本中不会——别依赖界面行为，自己写严实
真正难排查的，往往是组合场景：比如联合索引 + 函数 + 隐式转换同时出现，EXPLAIN 显示 key 为空却以为“索引坏了”。phpEnv 不是黑盒，它只是本地 MySQL 的快照——把线上查 EXPLAIN 的习惯，原样带到本地开发里，才是防失效的第一道防线。
