thinkphp 查询性能问题根源在于sql写法不当导致索引失效、去重逻辑错误及分页机制不合理；须结合explain分析执行计划，规范where条件、慎用distinct、优化paginate并区分db与模型差异。

ThinkPHP 查询慢、分页卡、去重错、索引不命中——这些问题基本都出在「写法掩盖了 SQL 本质」上。框架再优雅，最终执行的还是 SQL；优化必须从生成的语句结构和数据库执行计划出发，不能只调用 paginate 或 distinct 就以为万事大吉。

where 条件怎么写才让索引生效

ThinkPHP 的 where() 看似简单，但一写错就全表扫描。关键不是“有没有加条件”，而是生成的 WHERE 子句是否匹配索引定义。

• where('status', 1) → 生成 WHERE status = 1，若 status 有单列索引或联合索引最左前缀，大概率命中
• where('name', 'like', '%张%') → 生成 WHERE name LIKE '%张%'，B+Tree 索引失效，必 type: ALL
• whereRaw('DATE(create_time) = "2024-01-01"') → 对字段用函数，索引失效；应改写为 whereBetween('create_time', ['2024-01-01 00:00:00', '2024-01-01 23:59:59'])
• 联合索引 (category_id, status, create_time) 下：where(['category_id' => 1, 'status' => 1]) 可命中；但 where(['status' => 1]) 就无法利用（缺失最左字段）

distinct() 不是万能去重，别当它能去重整行

distinct(true) 只对 field() 明确指定的字段组合去重，不是 SQL 的 DISTINCT *。指望它“每 user_id 取一条最新记录”会出错。

btpanel phpsite 宝塔面板PHP网站

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

下载

• 错误写法：$model->distinct(true)->field('*')->select() → 多数 MySQL 版本直接报错
• 正确写法：$model->distinct(true)->field('user_id, status')->select() → 去重的是这两个字段值的组合
• 想按 user_id 取最新一条？必须用 group() 配合聚合或子查询：$model->field('user_id, max(id) as id')->group('user_id')
• TP6 比 TP5 更严格：没配 field() 直接调 distinct(true) 会抛异常，迁移时务必检查

paginate 性能瓶颈不在 PHP，在 count + offset

默认 paginate(10) 会发两条 SQL：一条 SELECT ... LIMIT 10，一条 SELECT COUNT(*)。大数据量下，count 和大 offset 是双杀。

• 禁用总数统计：->paginate(10, false) → 只查数据 + 判断是否有下一页，跳过 count
• 深度分页（如第 1000 页）避免 LIMIT 10000,10：改用游标分页，where('id', '>', $lastId)->limit(10)，始终走主键索引
• 缓存总条数比实时 count 更快：比如用 Redis 缓存 user_count，定时或事件驱动更新
• 不要在生产环境开启自动 EXPLAIN：虽然中间件能捕获 SQL 补 EXPLAIN，但每次多一次查询，本身就有开销

Db::table() 和模型查询的底层差异容易被忽略

Db 类和模型类看似接口一致，但生成 SQL 的严谨性和默认行为不同，尤其在字段处理和作用域上。

• Db::table('user')->where('id', 5)->find() → 字段列表由数据库元信息推导，无字段白名单限制
• UserModel::where('id', 5)->find() → 若模型启用了 fields_strict，且未在 $schema 中定义字段，可能丢数据或报错
• 全局查询范围（如 addGlobalScope('status', ...)）只作用于模型，Db::table() 完全不受影响
• Db::table() 不支持 scope 方法，想复用条件得封装成闭包或公共查询构建器

真正卡顿的查询，往往不是框架不够快，而是开发者没去看 EXPLAIN 输出里的 type 和 key；真正翻车的去重，常常是因为把 distinct() 当成了“智能 dedupe”。写法越高级，越要盯紧生成的 SQL 和它的执行计划。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！