ThinkPHP数据库查询变慢主因是索引失效而非缺失；需通过EXPLAIN确认key、rows、Extra字段，排查函数运算、隐式转换、LIKE前导模糊、联合索引最左前缀违背、OR条件不均衡等场景，并注意框架特有坑如字符串where、whereIn过多、外键无索引及软删除字段未索引。
ThinkPHP数据库查询变慢，八成是索引没走对——不是没建索引，而是建了却失效了。排查关键不在代码多漂亮，而在SQL是否真用了索引，以及MySQL优化器有没有“看懂”你的查询意图。
一、先确认是不是真没走索引
别猜，要看真实执行计划：
- 开启 SQL 日志和 EXPLAIN：在
config/database.php中确保'sql_explain' => true，并设置APP_DEBUG=true；运行查询后，查runtime/log/sql/下最新日志，里面会附带EXPLAIN结果 - 盯住三列：key（为空=没走索引）、rows（远大于实际返回行数=索引低效）、Extra（出现
Using filesort或Using temporary就得重写逻辑） - 用
SHOW INDEX FROM table_name确认索引确实存在，且字段名、顺序、类型完全匹配
二、常见索引失效场景与修复方式
以下写法看着合理，实则让索引“形同虚设”：
-
对索引字段做函数或运算：如
where('DATE(create_time)', '2024-01-01')或where('age + 1', '=', 20)→ 改用whereBetween('create_time', [$start, $end])或直接比较原始字段 -
隐式类型转换：字段是
INT类型的user_id，却传字符串where('user_id', '10086')→ 统一用整型，或在模型中定义$type显式声明字段类型 -
LIKE 前导模糊：
where('name', 'like', '%张')→ 索引失效；改用where('name', 'like', '张%')，或引入全文索引/ES替代 -
联合索引违背最左前缀：有联合索引
(status, user_id, create_time)，但查询只写where('user_id', 10086)→ 不命中；必须带上status才能触发，或单独为user_id补单列索引 -
OR 条件中部分字段无索引：
where('name', '张三')->orWhere('phone', '138...')，若phone无索引 → 整个条件可能放弃索引 → 给phone加索引，或拆成两个独立查询用 UNION
三、ThinkPHP 特定写法引发的失效风险
框架封装带来便利，也藏了几个“坑”：
立即学习“PHP免费学习笔记（深入）”；
-
字符串形式的 where：写成
where('status = 1')（字符串）而非where('status', 1)→ 绕过参数绑定，可能触发全表扫描，且影响执行计划缓存 - whereIn 元素过多：传入上千 ID 的数组 → MySQL 可能拒绝或退化为全表扫描 → 改为分批查询（每 500 个一批），或用临时表 + JOIN 替代
-
关联外键没索引：用
with('profile')，但profiles.user_id没建索引 → 关联时对 profile 表全表扫描 → 检查所有外键字段，手动加索引，如ALTER TABLE profiles ADD INDEX idx_user_id (user_id) -
软删除字段未索引：ThinkPHP 默认用
delete_time IS NULL筛选，若该字段高频参与查询（如后台列表），需加索引：ALTER TABLE user ADD INDEX idx_not_deleted (delete_time)
四、验证与持续保障建议
优化不是一次动作，而是闭环习惯：
- 每次上线新查询逻辑前，用
EXPLAIN过一遍关键 SQL，尤其注意新增的whereHas、join、group场景 - 定期检查慢查询日志：MySQL 中执行
SET GLOBAL long_query_time = 0.5;，捕获半秒以上查询，结合 ThinkPHP 日志定位接口源头 - 给高频组合条件建联合索引时，按「等值字段在前、范围字段在后」排序，例如
WHERE status = 1 AND create_time BETWEEN ? AND ?→ 索引应为(status, create_time) - 避免“索引焦虑”，删掉长期不用或重复的索引：用
SELECT * FROM information_schema.STATISTICS WHERE table_schema = 'your_db'辅助识别冗余项
