ThinkPHP数据库索引优化方法与实战技巧详解

索引并非越多越好，关键在于确保每一条查询都能有效利用。许多 ThinkPHP 项目查询缓慢，根源往往不在于没有建立索引，而在于 SQL 的写法导致 MySQL 无法使用现有索引——你必须先让查询“能够走索引”，再进一步优化“索引效率”。

ThinkPHP 中 where() 的哪些写法会导致索引失效

框架的链式调用虽然代码整洁，但一旦写法不当，EXPLAIN 结果就会显示 type: ALL 和 key: NULL，这意味着索引完全未被使用。

• where('name', 'like', '%abc') —— 左模糊查询会使 B+ 树索引无法进行前缀匹配，应改为 where('name', 'like', 'abc%') 或考虑使用全文索引。
• whereRaw('DATE(create_time) = "2024-01-01"') —— 对索引字段使用函数操作会导致索引失效；应改用 whereBetween('create_time', [$start, $end]) 进行范围查询。
• where('status', 1)->where('score', '>', 80) —— 如果建立的是 (status, score) 联合索引，由于 status 是等值查询，score 是范围查询，索引可以生效；但如果索引顺序是 (score, status)，范围查询在前，后面的 status 条件将无法利用索引。
• where('user_id', $uid)->order('id desc') —— 如果表上只有 user_id 的单列索引，对 id 字段排序会触发 Using filesort 文件排序；要优化此类查询，需要建立 (user_id, id) 的联合索引。

如何正确排列联合索引的字段顺序

MySQL 严格遵循最左前缀匹配原则，字段顺序错误会使索引效果大打折扣。排列顺序不应凭感觉，而应基于实际的查询模式。

• 高频等值+范围查询组合：例如常见查询为 where('category_id', 5)->where('status', 1)->where('create_time', '>=', $t)，最优索引顺序应为 (category_id, status, create_time)；将范围查询字段 create_time 放在最后，才能保证前两个等值条件能充分利用索引。
• 包含排序的查询：如 where('user_id', $uid)->order('created_at desc')，索引必须是 (user_id, created_at)；如果顺序是 (created_at, user_id)，则无法利用索引的有序性来优化 user_id 的等值查询和排序。
• 避免冗余索引：如果已经存在 (a, b) 联合索引，通常无需再单独建立 (a) 的单列索引；在 MySQL 5.7 及以上版本中，查询优化器通常能有效利用联合索引的前缀。

如何验证 ThinkPHP 查询是否真正使用了索引

buildSql() 方法仅生成 SQL 模板，无法得知执行计划；关键在于使用 getLastSql() 方法获取参数绑定后的真实 SQL 语句，然后直接执行 EXPLAIN 进行分析。

• 开启 SQL 分析日志：在 config/database.php 配置文件中添加 'sql_explain' => true，ThinkPHP 会自动为每个 SELECT 查询打印 EXPLAIN 的执行计划。
• 手动验证执行计划：通过 $query->getLastSql() 获取完整 SQL，复制到 MySQL 客户端执行 EXPLAIN SELECT ...。
• 重点关注三列：type（ref/range 为佳，ALL 表示全表扫描）、key（是否实际命中了你创建的索引名称）、rows（预估扫描行数，越接近实际结果集数量越好）。
• 注意软删除字段的影响：对于 delete_time IS NULL 这类条件，如果表中 delete_time 字段存在大量 NULL 值，MySQL 可能认为该条件的选择性不高，从而放弃使用索引。

哪些字段类型值得优先建立索引

不要盲目地为所有出现在 where 子句中的字段创建单列索引。索引本身有维护成本，应优先保障高频、高筛选性的查询场景。

• 主键与外键字段：ThinkPHP 默认的主键 id 自带聚簇索引；像 user_id、category_id 这类常用于 JOIN 关联或 WHERE 条件的外键字段，通常都需要建立索引。
• 高频唯一查询字段：例如用户登录用的 mobile、订单详情页查询的 order_sn、会话校验的 token 等，建立单列索引往往能带来显著的性能提升。
• 状态与时间的组合字段：例如订单表中经常同时查询 status 和 create_time，为它们建立联合索引通常比建立两个独立的单列索引更节省空间，查询效率也更高。
• 避免对大字段建立索引：不要为 TEXT、JSON 等大字段类型建立索引，即使它们出现在 WHERE 条件中，也可能导致索引体积过大，反而降低查询速度。

最容易被忽视的一点是：数据库索引优化并非一劳永逸。当业务逻辑发生变化时，原本高效的查询可能迅速退化。因此，每次新增或修改查询条件、排序字段或表连接时，都应重新通过 EXPLAIN 检查执行计划，确保索引策略持续有效。