在 phpMyAdmin 中用 EXPLAIN 验证索引是否生效，需在 SQL 标签页执行与线上完全一致的 EXPLAIN SELECT 语句，重点观察 key、rows、type 三列；key 为 NULL 或 type=ALL 通常因查询写法触发索引失效（如对索引列用函数），而非索引未建。
直接在 phpMyAdmin 里执行 EXPLAIN 就能验证索引是否生效，不需要重启、不用导出导入、也不依赖额外工具——但必须注意执行上下文和语句写法，否则看到的 key 是 NULL 或 type=ALL 并不等于索引没建好，很可能是你查的方式“绕过了”索引。
在 phpMyAdmin 的 SQL 标签页里执行 EXPLAIN
别点“结构”页去翻索引列表，那只能确认索引存在，不能确认它被用了。真正有效的验证动作只有一条：EXPLAIN SELECT ... 语句，且必须和你线上真实查询**完全一致**（包括字段、WHERE 条件、JOIN 顺序、函数调用）。
- 打开目标数据库 → 点顶部“SQL”标签 → 在文本框中输入带
EXPLAIN的完整查询，例如：EXPLAIN SELECT * FROM t_user WHERE age > 25 AND province = '广东'; - 点击“执行”，结果表格里重点看三列：
key（实际使用的索引名）、rows（预估扫描行数）、type（访问类型，range或ref比ALL好） - 如果
key为空、type=ALL、rows接近全表总数，说明这条 SQL 没走索引——此时问题大概率出在查询本身，而不是索引没建
为什么加了索引，EXPLAIN 还显示 key=NULL
常见原因不是索引没生效，而是你的查询触发了 MySQL 的索引失效规则，优化器主动弃用了它。这些情况在 phpMyAdmin 里一试便知：
- 对索引列用了函数：比如
WHERE DATE(created_at) = '2026-09-10'→ 改成WHERE created_at >= '2026-09-10' AND created_at - 联合索引未满足最左前缀：有
idx_name_age(user_name, age)，但查询只写了WHERE age = 28→ 不会命中该索引 - 隐式类型转换：
phone是VARCHAR，却写成WHERE phone = 13800138000（数字无引号）→ MySQL 会把整列转为数字比对，索引失效 - 使用了
OR且部分条件无法走索引：如WHERE user_name = 'Alice' OR email LIKE '%@qq.com'→ 后半段无法用索引，整个条件可能退化为全表扫描
对比加索引前后的执行计划变化
phpMyAdmin 不提供自动对比功能，但你可以手动做两件事来确认效果：
立即学习“PHP免费学习笔记（深入）”；
- 先执行一次原始查询的
EXPLAIN，记下rows和type；再建完索引后，**用完全相同的语句再执行一遍EXPLAIN**，对比这两组输出 - 别只信
key字段，更要关注rows是否从几万降到几百——这才是索引真正起效的信号；key_len变大也说明用了更多索引列（比如从 4 升到 60，代表联合索引中两个字段都被用上了） - 如果
rows没变，但key出现了，可能是覆盖索引（Extra: Using index），这时虽然没回表，但扫描范围没缩小，性能提升有限
最容易被忽略的一点是：phpMyAdmin 执行 EXPLAIN 时不会走查询缓存，也不会受慢查询日志开关影响，但它默认使用当前连接的 SQL mode。如果你的生产环境开了 STRICT_TRANS_TABLES 而测试库没开，某些隐式转换行为可能不一致——验证前最好确认两边 mode 一致，用 SELECT @@sql_mode; 对一下。
