buildSql() 不能直接看出索引是否生效，仅输出SQL字符串；需用EXPLAIN分析其执行计划，注意替换占位符并避开函数操作、左模糊等索引失效写法。
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+ 树索引对等值查询友好，对范围、排序、分组依赖联合索引顺序。
立即学习“PHP免费学习笔记（深入）”；
- 高频等值查询字段必须进联合索引：比如经常查
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。
