key_len为null或远小于预期说明索引失效，主因是字段类型不匹配、函数包裹字段、联合索引顺序错误；join性能差多因on字段无索引；wheretime会触发date()函数致索引失效；count(*)在复杂join下生成嵌套查询导致性能骤降。
Explain 看不出 key_len？说明索引没用上
ThinkPHP 生成的 SQL 如果 EXPLAIN 显示 key_len 为 NULL 或远小于预期，基本等于宣告索引失效。常见原因是查询条件字段类型不一致（比如数据库是 VARCHAR(32)，PHP 传入的是整数），或用了函数包装字段（WHERE UPPER(name) = ?），又或者联合索引顺序和查询条件不匹配。
实操建议：
- 用
Db::name('user')->where('status', 1)->where('created_at', '>', '2023-01-01')->select()生成 SQL 后，手动贴到 MySQL 客户端执行EXPLAIN，别信 TP 日志里“已走索引”的描述 - 联合索引
(a, b, c)只能支持a、a,b、a,b,c的等值查询，b = ?单独出现一定走不了索引 - TP 的
whereRaw很容易写出WHERE JSON_CONTAINS(meta, '"admin")这类无法走索引的语句，优先改用预定义字段存标签
Query Builder 写 JOIN 却变全表扫描？检查 ON 条件字段是否都有索引
ThinkPHP 的 join 方法本身不决定性能，真正致命的是 ON 子句里两边字段缺失索引。哪怕只是两个小表关联，只要 ON user.id = order.user_id 中 order.user_id 没索引，MySQL 就会为每次 user 行去全扫 order 表。
实操建议：
-
Db::table('user')->alias('u')->join('order o', 'u.id = o.user_id')->select()之前，先确认order.user_id有单列索引或作为联合索引最左前缀 - 避免在
ON里写表达式，例如o.status + 0 = u.level会让索引失效；改用WHERE提前过滤 - TP6 的
withJoin虽方便，但底层仍是 LEFT JOIN，如果关联模型数据量大且无索引，比手写join更难排查
whereTime 和 whereBetween 在日期范围查询中为什么慢？
whereTime('create_time', 'between', ['2023-01-01', '2023-12-31']) 看似简洁，但 ThinkPHP 默认会把字段转成 DATE(create_time)，导致无法使用 create_time 上的 B+ 树索引。真实执行的 SQL 往往是 WHERE DATE(create_time) BETWEEN ...，全表函数计算。
实操建议：
- 直接用
whereBetween配合字符串时间戳：whereBetween('create_time', ['2023-01-01 00:00:00', '2023-12-31 23:59:59']) - 确保数据库字段是
DATETIME或TIMESTAMP类型，且已建索引；不要用INT存时间戳再用FROM_UNIXTIME转换 - 如果业务允许，把查询下推到分表或分区逻辑里，比如按月分表后，
where('create_time', '>=', '2023-06-01')能自动命中对应物理表
count() 性能崩了？别在复杂 JOIN 后直接 count(*)
ThinkPHP 的 count() 在带多表 JOIN 或子查询时，默认生成 SELECT COUNT(*) FROM (SELECT ...) AS tp_count，外层嵌套让 MySQL 无法优化，尤其当内层结果集大时，count 可能比查数据还慢。
实操建议：
- 能用
Db::table('user')->count()就别写Db::table('user')->join(...)->count()；前者走SHOW TABLE STATUS快速估算，后者真扫描 - 需要精确总数且必须 JOIN，显式指定主表计数：
Db::table('user u')->join('order o', 'u.id = o.user_id')->count('u.id')，避免默认COUNT(*)计算笛卡尔积行数 - 高频分页场景，考虑用游标分页（
WHERE id > ? ORDER BY id LIMIT 20）替代limit 10000,20，彻底绕过 count
索引不是加了就生效，Explain 不是看了就懂——关键得看 type 是不是 ref 或 range，rows 是不是接近实际返回行数。很多慢查最后发现，是 PHP 层拼了 IN 数百个 ID，但数据库只对前几项用了索引，后面全回表。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
