ThinkPHP索引失效排查方法与EXPLAIN分析详解

排查ThinkPHP应用性能问题时，数据库索引往往是首要怀疑对象。但很多时候，明明在代码里建了索引，查询速度却依然慢如蜗牛。问题出在哪？很可能，你的索引在MySQL层面根本没生效。今天，我们就来聊聊几个让索引“隐形”的典型陷阱，以及如何用最可靠的方法验证它。

EXPLAIN 必须在开发环境手动执行，不能只看 getLastSql()

这里有个常见的误区：开发者习惯用 Db::getLastSql() 打印出SQL语句，看到条件都对，就以为万事大吉。但真相是，getLastSql() 只返回拼接好的SQL字符串，至于MySQL优化器最终是否选择走索引、走了哪个索引，它一概不知。

因此，最准确的方法永远是直接求助MySQL本身。把你从ThinkPHP日志里拿到的SQL，复制到MySQL客户端（或phpMyAdmin等工具），在前面加上 EXPLAIN 关键字再执行。这个命令返回的执行计划，才是索引使用情况的“体检报告”。

实战中，经常遇到这两种情况：

• 代码里写了 where(['status' => 1, 'type' => 2])，页面响应很慢，getLastSql() 输出的SQL看起来完美，但实际上数据库正在做全表扫描。
• 在数据库配置中开启了 'sql_explain' => true，但请注意，这个配置通常只对SELECT查询生效。如果你的性能瓶颈出现在UPDATE或INSERT语句上，这个配置就帮不上忙，容易让人误以为所有场景都已覆盖。

具体怎么看这份“体检报告”？给你几个关键指标：

• 把类似 Db::name('user')->where('mobile', $phone)->find() 生成的SQL拿出来，在MySQL中执行 EXPLAIN SELECT * FROM user WHERE mobile = '13800138000'。
• 重点盯住 type 列：如果值是 ALL，意味着全表扫描，索引肯定没起作用；看到 range（范围扫描）或 ref（等值匹配），才说明索引被用上了。
• 再看 key 列：如果这一列是 NULL，那很遗憾，优化器压根没选中任何索引，哪怕你建了十个也是白搭。

联合索引失效的典型顺序陷阱

给多个字段建了联合索引，比如 (status, type, created_at)，是不是觉得随便查哪个字段都能加速？这是一个经典的误解。MySQL的联合索引遵循“最左前缀匹配”原则，ThinkPHP中where条件的书写顺序，直接决定了索引能否被激活。

来看几个具体场景，一目了然：

• ✅ where(['status' => 1, 'type' => 2]) → 条件从最左的 status 开始，且连续匹配了前两列，索引生效。
• ❌ where(['type' => 2]) → 条件跳过了最左的 status 列，直接查询 type。这时，整个联合索引就像一本没按首字母查的字典，无法快速定位，索引失效。
• ⚠️ where(['status' => ['>', 1], 'type' => 2]) → status 使用了范围查询（>、<、BETWEEN等）。在这种情况下，status 列本身还能用索引快速定位一个范围，但排在它后面的 type 列就无法再用于进一步的索引查找了，索引效果大打折扣。

这个原则同样影响着排序和分页。例如，如果你试图用 ->order('type desc') 来优化排序，但在上面的索引中，type 前面缺少等值查询条件，MySQL就无法利用索引来避免额外的排序操作。

函数操作和模糊查询让索引彻底失效

想象一下，图书馆给所有书编了索引（书名），但你却要求管理员“把书名去掉第一个字后再查”。这索引当然就废了。数据库索引也是同理，一旦在WHERE条件里对索引字段进行函数计算、类型转换或使用特定模式的模糊匹配，B+树索引的快速定位能力就瞬间归零。

下面这些写法，都是索引的“杀手”：

• whereRaw('DATE(created_at) = “2024-01-01”') → 用 DATE() 函数包裹了日期字段，索引失效。
• where('name', 'like', '%abc') → 使用左模糊（以通配符%开头），索引无法确定从哪个“前缀”开始匹配，只能全表扫描。
• where('mobile', 'like', '138%') → 使用右模糊（以具体字符开头），理论上可以走索引。但要注意，如果字段很长或索引只取了前缀，效果也可能不理想，务必用 EXPLAIN 确认 key_len 是否合理。

正确的优化思路应该是：

• 用 whereBetween('created_at', [$start, $end]) 来替代对日期字段使用 DATE() 函数。
• 对于频繁的左模糊或全文搜索需求（如搜索文章内容），考虑使用MySQL的全文索引（FULLTEXT）或引入Elasticsearch这类专业搜索引擎，不要在B-Tree索引上硬扛。
• 如果必须使用 LIKE，尽量保证模式是 'abc%' 这样的右模糊，并为该字段建立索引。

NULL 值和联合唯一索引的隐性坑

MySQL对 NULL 值的处理有点特殊，尤其是在联合唯一索引的场景下。在唯一索引中，多个 NULL 值被视为互不相等。这意味着，如果有一个联合唯一索引 (user_id, sku_id)，数据库会允许插入多条 (1, NULL) 的记录，因为每一行的 NULL 都被认为是不同的。这很容易导致业务逻辑上认为的“重复数据”被成功插入。

实际开发中，容易在以下几个地方踩坑：

• 数据导入时，Excel中的空单元格被PHP处理成 NULL 写入数据库，导致联合唯一约束失效，重复数据源源不断。
• 查询时，使用 where(['user_id' => 1, 'sku_id' => null]) 可能查不到数据，因为 NULL 不能用等号（=）判断，必须使用 IS NULL。
• 在代码中做唯一性校验时，使用 where(['a' => $a, 'b' => $b])->count()，如果 $b 是 null，这条查询会返回0，让你误以为数据不重复，从而允许插入另一条 (a=1, b=NULL)。

如何规避这些坑？可以从设计和编码两方面入手：

• 在设计表结构时，就明确字段是否允许为 NULL。对于需要参与唯一性约束的字段，强烈建议设置为 NOT NULL 并赋予一个默认值（如空字符串 DEFAULT ''）。
• 在业务逻辑层，对可能为 NULL 的字段进行单独处理。例如，校验唯一性时可以使用更复杂的条件：whereRaw('(a = ? AND (b = ? OR (b IS NULL AND ? IS NULL)))', [$a, $b, $b])。
• 在数据清洗阶段，将外部导入的空值统一转换为非NULL的默认值，避免 NULL 混入联合键。

说到底，真正拖垮性能的，往往不是忘记建索引，而是索引建了却因为顺序、NULL值、函数操作或模糊查询方式不对而完全失效。养成一个好习惯：每次为关键查询添加或调整索引后，别只相信框架层的日志或自己的直觉，一定要用 EXPLAIN 命令，亲自看一眼 key 和 type 列的结果。这才是确保索引真正发挥效力的不二法门。