ThinkPHP如何做数据库索引优化建议_ThinkPHP查询性能提升技巧【教程】-ThinkPHP-PHP中文网

buildsql() 不能直接看出索引是否生效，仅输出sql字符串；需用explain分析其执行计划，注意替换占位符并避开函数操作、左模糊等索引失效写法。

thinkphp如何做数据库索引优化建议_thinkphp查询性能提升技巧【教程】

ThinkPHP 的 `buildSql()` 能不能看出索引是否生效

不能直接看，但它是关键第一步。ThinkPHP 的 buildSql() 只输出最终 SQL 字符串，不包含执行计划。想确认索引有没有被用上，得把生成的 SQL 拿去数据库里手动加 EXPLAIN 看。

常见错误现象：buildSql() 显示 SQL 很简洁，就以为“没走全表扫描”，结果一 EXPLAIN 发现 type 是 ALL，key 是 NULL。

使用场景：调试慢查询时，先用 $query->buildSql() 拿到真实 SQL，再在 MySQL 客户端执行 EXPLAIN SELECT ...
注意 ThinkPHP 5.1+ 的 buildSql() 返回带问号占位符的 SQL，要替换成实际值（或改用 getLastSql()，它返回已替换参数的完整 SQL）
如果用了软删除（delete_time）、时间范围查询、LIKE '%xxx'，即使字段有索引，EXPLAIN 也大概率显示没用上

ThinkPHP 查询里哪些写法会直接让索引失效

不是框架的问题，是 SQL 本身触发了 MySQL 的索引规避规则。ThinkPHP 的链式调用看着干净，但一不留神就写出无法走索引的语句。

where('name', 'like', '%abc') —— 左模糊，B+ 树没法从头匹配，索引失效
whereRaw('DATE(create_time) = "2024-01-01"') —— 对字段做函数操作，索引失效
where('status', '', 1)->where('score', '>', 80) —— 复合索引中，status 是范围查询，后面字段（如 score）无法利用联合索引的有序性
where('user_id', $uid)->order('id desc')->limit(10) —— 如果 user_id 有索引但 id 没有，排序仍可能触发 filesort

给 ThinkPHP 数据表加索引，优先加哪些字段

别一上来就给所有 where 字段单独建索引。MySQL 的 B+ 树索引对等值查询友好，对范围、排序、分组依赖联合索引顺序。

高频等值查询字段必须进联合索引：比如经常查 where('category_id', 5)->where('status', 1)，就建 (category_id, status)，别建两个单列索引
order by 字段必须放在联合索引末尾：如 where('user_id', $uid)->order('created_at desc')，索引应为 (user_id, created_at)；反过来（created_at 在前）就没用
避免冗余索引：(a) 和 (a,b) 同时存在，删掉 (a)；ThinkPHP 自动生成的 id 主键不用管，但记得检查是否误删了主键
大文本字段（TEXT、JSON）不要参与索引，哪怕只 WHERE 一下，也容易导致索引膨胀甚至查询变慢

ThinkPHP 开启查询日志后，怎么快速定位没走索引的请求

靠肉眼看日志不现实。得结合日志 + 数据库慢查询日志 + 实际执行计划三者交叉验证。

开启 ThinkPHP 查询日志：配置 'show_sql' => true，但它只打 SQL，不打耗时也不打执行计划
真正有用的是 MySQL 的 slow_query_log：设 long_query_time = 0.1，配合 log_queries_not_using_indexes = ON，能直接抓出没走索引的语句
ThinkPHP 的 Db::listen() 回调里，可以对 $sql 做关键词过滤（比如含 LIKE '%'、DATE(、ORDER BY 且无对应索引字段），提前预警
注意：有些查询本身数据量小（EXPLAIN 里 rows 很小就说明这事

索引不是越多越好，联合索引的字段顺序、查询条件的写法、MySQL 版本对索引的选择策略——这三块一旦错位，加了索引也白加。最常被忽略的是：ThinkPHP 的 whereTime()、whereBetween() 这类封装，底层仍是函数包裹字段，得翻源码确认它生成的是裸字段比较还是带函数的 SQL。