ThinkPHP联合索引顺序怎么排_ThinkPHP索引选择性分析【详解】-ThinkPHP-PHP中文网

联合索引字段顺序必须按查询条件频率和类型排列：高频等值字段放最左，范围字段居中，order by 字段放最右，这是由b+树结构和最左前缀原则决定的；错误顺序会导致索引部分或全部失效。

thinkphp联合索引顺序怎么排_thinkphp索引选择性分析【详解】

联合索引字段顺序必须按查询条件出现频率和类型排

高频等值查询字段放最左，低频范围查询字段放中间，ORDER BY 字段放最右——这不是经验主义，是 B+ 树索引结构决定的。比如常写 where('user_id', 123)->where('status', 1)->order('created_at desc')，索引就该建为 (user_id, status, created_at)。反过来建 (created_at, user_id)，哪怕条件全中，EXPLAIN 里 key_len 也只用到第一个字段，后面全失效。

常见错误现象：where('status', 1)->where('user_id', 123) 看似和上面一样，但若索引是 (user_id, status)，MySQL 优化器仍可能走索引（因等值条件可交换），但一旦加了 where('status', 'in', [1,2]) 这种范围查询，status 后面的字段就彻底无法利用索引有序性。

别把 create_time 放最左——除非你从不带其他条件只查时间范围
软删除字段 delete_time 是高频等值筛选（is null），适合进联合索引，但别单独建
字段允许 NULL 时，MySQL 8.0+ 对联合索引中 NULL 值的处理会破坏最左匹配预期，建议统一设为 NOT NULL

ThinkPHP 的 buildSql() 和 getLastSql() 别混用，否则 EXPLAIN 结果不准

buildSql() 返回带问号占位符的 SQL，比如 SELECT * FROM users WHERE id = ?；getLastSql() 才返回真实参数替换后的语句，如 SELECT * FROM users WHERE id = 123。拿前者去 MySQL 执行 EXPLAIN，会因参数未绑定导致类型推断失败，type 可能显示 ALL 或 index，误导你认为没走索引。

实操建议：

调试时优先用 $query->getLastSql()，复制整条语句到 MySQL 客户端执行 EXPLAIN
如果用 buildSql()，必须手动替换所有 ?，注意字符串要加单引号、数字不加，否则 EXPLAIN 解析出错
遇到 WHERE YEAR(create_time) = 2024 这类写法，buildSql() 看着正常，但 EXPLAIN 一定显示 key 为空——函数操作直接绕过索引

复合索引里字段顺序错了，比没建索引还危险

索引 (a, b) 能加速 WHERE a = ? 和 WHERE a = ? AND b = ?，但对 WHERE b = ? 完全无效。很多人建了 (status, create_time)，却常查 WHERE create_time > ? AND status = 1，误以为“字段都在索引里就行”，结果 EXPLAIN 显示 type: ALL。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

性能影响很直接：50 万行的表，WHERE create_time > '2024-01-01' 全表扫描平均耗时 1.8s；加了正确顺序的联合索引后降到 32ms——前提是 create_time 在索引右侧且前面有等值字段约束。

用 SHOW INDEX FROM table_name 确认索引字段顺序，别只看名字
key_len 值能帮你验证用了几个字段：utf8mb4 下 varchar(50) 占 50×4+2=202 字节，若 EXPLAIN 中 key_len = 202，说明只用到了第一个字段
别建冗余索引，比如已有 (a, b)，再建 (a) 就是浪费，MySQL 无法复用

唯一性校验场景下，联合索引顺序影响并发安全性

ThinkPHP 的 unique 规则不支持多字段，必须靠数据库联合索引 + Rule::callback() 实现。但索引顺序不对，会导致唯一约束形同虚设。例如用户注册要校验 username 和 email 组合唯一，建索引 (email, username)，那并发插入两条 email 不同但 username 相同的数据，不会触发唯一键冲突——因为索引最左字段不同，MySQL 认为这是两条独立路径。

真正起作用的是 (username, email)：只要 username 相同，MySQL 就会在同一索引分支下检查 email 是否重复，才能保证 INSERT ... ON DUPLICATE KEY UPDATE 或事务中 SELECT ... FOR UPDATE 加锁有效。

建索引前先确认业务主查询模式：是更常按 username 查？还是按 email 查？选高频字段放左
字段含中文或特殊字符时，索引名用下划线分隔，避免迁移时解析失败
ALTER TABLE users ADD UNIQUE INDEX uniq_uname_email (username, email) 中的字段顺序不能颠倒，否则唯一性保障失效

实际加索引前，先跑一条典型查询的 EXPLAIN，再对比加索引后的 key_len 和 rows——差一个数量级才算有效。最易被忽略的是字段类型隐式转换：user_id 是 VARCHAR，但 PHP 传了整数，MySQL 自动转类型，索引直接失效。