thinkphp复合索引生效关键在于字段顺序与查询逻辑对齐：必须严格遵循最左前缀原则，where链式调用顺序需匹配索引字段顺序，范围查询后字段失效，建索引须显式命名并用explain验证。
ThinkPHP 里建复合索引，不是把 where 里的字段随便塞进 index() 就完事——顺序错、条件写反、范围一加，索引立刻失效。真正起效的关键，在于让索引结构和查询逻辑对齐。
复合索引字段顺序必须和 where 链式调用顺序一致
ThinkPHP 的 where() 是按调用顺序拼 SQL 的，而 MySQL 的 B+ 树索引只认“最左前缀”。比如你建了 INDEX idx_user_status (user_id, status)：
-
$model->where('user_id', 1)->where('status', 2)->select()→ ✅ 命中全部两列 -
$model->where('status', 2)->where('user_id', 1)->select()→ ❌ 只能走全表扫描（status不是最左列） -
$model->where('user_id', 'in', [1,2,3])->where('status', 2)->select()→ ⚠️user_id是IN，仍算等值匹配，可继续用status；但换成>或BETWEEN，后面字段就断了
别在迁移里写 index(['a', 'b', 'c']) 就交差
TP 的迁移语法 $table->index(['a', 'b', 'c']) 确实能建索引，但它不指定名称，MySQL 自动生成名（如 idx_a_b_c_123456），后续排查、useIndex()、EXPLAIN 都难定位。更麻烦的是：它不校验字段是否存在、类型是否匹配。
- 建索引前先确认字段真实存在且类型一致（比如
status是TINYINT，别误写成VARCHAR） - 显式命名：
CREATE INDEX idx_order_user_status ON `order` (user_id, status); - 如果要用
useIndex('idx_order_user_status')，名字必须一字不差，大小写敏感
WHERE 里有范围条件，后面字段基本作废
复合索引不是“只要字段在索引里就能用”。一旦某个字段用了范围操作（>、、<code>BETWEEN、LIKE 左模糊），MySQL 就停在那一列，后面的字段无法用于索引查找或排序。
-
$model->where('created_at', '>=', $start)->where('status', 1)->select()→status列不会走索引（即使它在索引定义里排第二） - 想让
status也生效？得把status放前面：INDEX idx_status_created (status, created_at)，前提是status查询频率高、区分度够 -
LIKE '%abc'或whereRaw('DATE(create_time) = ...')直接让整条索引失效，这类写法要重构成范围查询或前置索引
建完索引必须跑 EXPLAIN 验证，别信 TP 日志里的 SQL
TP 输出的 SQL 看着没问题，不代表 MySQL 真用了索引。只有 EXPLAIN 能告诉你实际执行路径：
- 看
key字段是否显示你的索引名 - 看
key_len是否符合预期（比如user_id是INT占 4 字节，status是TINYINT占 1 字节，全匹配时key_len应为 5） - 看
rows是否明显下降（从几万降到几十） -
useIndex()不是银弹：它只是 SQL 提示，MySQL 可能无视；SQLite/PostgreSQL 更会直接报错
最常被忽略的一点：索引不是建了就自动生效的。字段顺序、查询写法、范围条件、函数包装——任何一个环节没对齐，索引就形同虚设。验证必须落到 EXPLAIN 的输出上，而不是 PHP 层有没有报错或返回结果快慢。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
