索引并非越多越好，关键在于确保每一条查询都能有效利用。许多 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 检查执行计划，确保索引策略持续有效。
