1. 一个后台列表接口，为什么能慢到 3 秒
订单列表接口，PHP 8.1 + Laravel 10 + MySQL 8，订单表 200 万行，关联用户表和商品表。功能上就是分页查订单、带出用户昵称和商品标题、再算两个统计数字。听起来没什么难度，但上线后平均响应 3 秒起步，QPS 不到 10，数据库 CPU 时不时飙到 80% 以上。
这种接口的慢，通常不是 PHP 本身慢，而是「一次请求里干了太多重复的活」。我先用 Laravel Debugbar 挂上去看，一眼就看到 SQL 执行时间 2.5 秒、SQL 条数 41 条、内存峰值 120MB。41 条 SQL 里，1 条查订单，20 条查用户，20 条查商品——典型的 N+1。
所以这篇的路线是：先定位，再动手；先数据库，再 PHP；先干掉 N+1，再补索引和缓存；最后用 OPcache 和响应裁剪收尾。整个过程我会把可复制的配置、命令、代码都贴出来，你照着改自己的项目就行。中途排查 SQL 和读慢日志时，我也会用 TaoToken 统一走 AI 辅助分析，省得在多个平台之间来回切 Key。
2. 前置准备：TaoToken 统一 Key 与 API 通道
优化过程中经常要做几件事：让 AI 帮忙读 EXPLAIN 结果、解释慢查询日志、生成索引建议、review 一段 Laravel 查询代码。如果每个工具都单独配 Key，管理起来很烦。我的做法是用 TaoToken 做统一入口，一个 Key 走所有模型调用。
TaoToken 的定位是统一的模型 API 通道，兼容 OpenAI 风格的接口格式，所以 Laravel 里用 Guzzle 或 Http 门面直接发请求就行，不需要额外装 SDK。官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api 。
你需要先拿到 Key：进控制台创建 API Key，地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 。创建完复制出来，放到 Laravel 的.env里，别硬编码进代码。
# .env TAOTOKEN_API_KEY=sk-你的key TAOTOKEN_BASE_URL=https://taotoken.net/api如果你只是想先验证模型通不通，可以直接用模型对话页面试一条 prompt，地址是 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。把 EXPLAIN 的输出粘进去，让它判断 type 和 rows，比人肉看快很多。
注意：Key 只放服务端环境变量，不要提交到 Git，也不要在前端代码里出现。生产环境和本地环境建议用不同的 Key，方便单独限额和排查。
3. 可复制配置：OPcache、慢日志与 Laravel 查询改造
3.1 开启 OPcache，先把 PHP 自身的开销压下去
生产环境不开 OPcache，等于每次请求都重新编译一遍 PHP 文件。改php.ini：
; php.ini 生产环境配置 opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.validate_timestamps=0 opcache.revalidate_freq=0 opcache.save_comments=1validate_timestamps=0意味着 PHP 不再每次检查文件是否被修改，性能最好，但代价是改代码后必须 reload PHP-FPM。部署流程里加一步systemctl reload php-fpm就行。实测这一项能让 PHP 执行时间下降 30% 左右。
改完用php -i | grep opcache确认生效，或者写个opcache_get_status()的临时脚本看一眼命中率。
3.2 打开 MySQL 慢查询日志，别靠猜
在 MySQL 配置文件里加：
[mysqld] slow_query_log=1 slow_query_log_file=/var/log/mysql/slow.log long_query_time=0.5 log_queries_not_using_indexes=1重启 MySQL 后，用mysqldumpslow聚合分析：
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log-s t按总耗时排序，-t 10取前 10 条。你会很快看到哪条 SQL 是大头。我这边排第一的就是订单列表那条带status和created_at条件的查询。
3.3 干掉 N+1：Eager Loading
问题代码长这样：
$orders = Order::paginate(20); foreach ($orders as $order) { echo $order->user->name; echo $order->product->title; }改成：
$orders = Order::with(['user:id,name', 'product:id,title']) ->select(['id', 'order_no', 'user_id', 'product_id', 'status', 'created_at']) ->paginate(20);with里用user:id,name这种写法，只查需要的列，减少数据传输。SQL 从 41 条降到 3 条，时间从 2.5 秒掉到 600ms 左右。
3.4 索引重建：复合索引 + EXPLAIN 验证
原查询：
select * from orders where status = 1 and created_at >= '2024-01-01' order by created_at desc limit 20 offset 0;EXPLAIN显示type: ALL、rows: 2000000、Using filesort。加复合索引：
ALTER TABLE orders ADD INDEX idx_status_created_at (status, created_at);再EXPLAIN，变成type: range、rows: 20、filesort 消失。SQL 时间从 600ms 降到 150ms。索引顺序很重要：等值条件status放前面，范围条件created_at放后面，这样 MySQL 才能用上索引的有序性。
3.5 深度分页换成游标分页
limit 20 offset 100000这种写法，MySQL 还是要扫前 10 万行。后台列表 99% 的场景不需要跳页，直接换游标分页：
$orders = Order::with(['user:id,name', 'product:id,title']) ->where('status', 1) ->cursorPaginate(20);游标分页用where id > last_id代替 offset，深度分页从 1 秒以上稳定到 100ms 内。注意游标分页不支持随机跳页，前端要改成「上一页/下一页」。
3.6 缓存分层：只缓存变化少的数据
商品信息和统计数据适合缓存，分页结果不要缓存，容易脏。用 Laravel 的Cache::remember：
$product = Cache::remember( "product:{$order->product_id}", 600, fn () => Product::select('id', 'title')->find($order->product_id) );缓存 Key 要带业务前缀，更新商品时主动Cache::forget("product:{$id}")。这一层加上后，接口从 150ms 降到 80ms 左右。
3.7 用 TaoToken 辅助读 EXPLAIN 和慢日志
排查阶段我会把EXPLAIN的 JSON 输出和慢日志片段发给模型，让它帮我判断索引是否命中、有没有隐式类型转换。用 Laravel 的 Http 门面调 TaoToken：
use Illuminate\Support\Facades\Http; $response = Http::withToken(config('services.taotoken.key')) ->post(config('services.taotoken.base_url') . '/v1/chat/completions', [ 'model' => 'claude-sonnet-4-20250514', 'messages' => [ ['role' => 'user', 'content' => "分析这条 EXPLAIN 结果，指出索引问题：\n" . $explainJson], ], ]); $advice = $response->json('choices.0.message.content');config/services.php里加：
'taotoken' => [ 'key' => env('TAOTOKEN_API_KEY'), 'base_url' => env('TAOTOKEN_BASE_URL', 'https://taotoken.net/api'), ],这样排查时不用来回切平台，一个 Key 就能把 EXPLAIN、慢日志、代码片段都丢进去分析。如果你长期做这类编码和 Agent 任务，可以看下 Coding Plan，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，按额度走比单次调用更省心。
4. 验证请求：压测前后对比与成功结果
改完之后不能靠感觉，要用数据说话。我用ab和wrk各压一轮，接口是GET /api/orders?status=1&page=1。
# 优化前 ab -n 200 -c 20 http://your-app.test/api/orders?status=1 # 优化后 ab -n 200 -c 20 http://your-app.test/api/orders?status=1优化前的结果：平均响应 3000ms 以上，QPS 不到 10，失败请求若干。优化后：平均响应 300ms 左右，QPS 80+，无失败。
再用 Laravel Debugbar 确认 SQL 条数和内存：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 平均响应 | 3000ms | 300ms |
| SQL 条数 | 41 | 3 |
| 内存峰值 | 120MB | 35MB |
| QPS | <10 | 80+ |
响应体积也从 200KB 降到 30KB，因为select只取了需要的列，API Resource 里也精简了字段。网络传输时间在弱网环境下差别很明显。
验证 TaoToken 通道是否通，可以单独发一条请求：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-4-20250514","messages":[{"role":"user","content":"ping"}]}'返回里有choices字段就说明通道正常。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，参数细节可以对着看。
5. 本篇常见错排查
OPcache 没生效：先确认php -i | grep opcache.enable是 On，再看 PHP-FPM 是否 reload 过。validate_timestamps=0时改代码不 reload 是不会生效的，这是最容易踩的坑。
索引加了但没走：用EXPLAIN看key字段是不是你新建的索引。如果status是字符串类型而查询传了整数，会触发隐式转换导致索引失效。字段类型和查询参数类型要一致。
游标分页报错：cursorPaginate要求排序字段唯一，默认用主键。如果你的查询里有自定义orderBy，要确保排序字段组合唯一，否则分页会丢数据或重复。
缓存脏数据：更新商品后忘了Cache::forget，列表里还是旧标题。建议把缓存的写入和清除封装到模型事件里，别散落在业务代码各处。
TaoToken 返回 401：检查.env里的 Key 有没有多余空格，config:cache之后要重新php artisan config:clear。Base URL 结尾不要带/v1，代码里已经拼了。
慢日志没记录：long_query_time=0.5表示超过 0.5 秒才记，如果你的慢查询是 0.3 秒就不会出现。排查阶段可以临时调到 0.1，定位完再调回去。
6. 把 AI 排查接进你的优化流程
这套优化下来，真正花时间的不是改代码，而是定位问题。N+1 靠 Debugbar 一眼能看出来，但 EXPLAIN 的type、rows、filtered这些字段，以及慢日志里一堆相似 SQL 的聚合判断，有 AI 辅助会快很多。
我的做法是：本地用 Debugbar 和 EXPLAIN 拿到原始数据，把结果通过 TaoToken 发给模型，让它给出索引建议和改写方案，再自己验证。Key 在控制台创建 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，接入方式看文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。如果你用 Claude Code 做编码辅助，Anthropic 兼容通道的说明在 https://taotoken.net/claude-code?utm_source=taotoken_aicg_blog_end&utm_content=claude-code&utm_campaign=rewrite 。
最后留一个我自己的检查顺序：先看 SQL 条数，再看 EXPLAIN 的 type，再看有没有 filesort，最后才看 PHP 层。顺序反了容易在 OPcache 上折腾半天，结果发现大头是数据库。
