先用 EXPLAIN 查执行计划确认是否走索引，再检查字段类型匹配、复合索引顺序；高频查询用 APCu 缓存关键字段；开启 PHP-FPM 慢日志定位脚本瓶颈；HTTP 请求必须设置超时。
SlowLog 里看到大量 SELECT 却没走索引？先查执行计划
宝塔面板的 MySQL SlowLog 显示响应慢，但光看 SQL 语句看不出问题——SELECT * FROM user WHERE phone = '138...' 看着很短，实际可能全表扫描。必须用 EXPLAIN 看真实执行路径。
- 在 phpMyAdmin 或命令行执行
EXPLAIN SELECT * FROM user WHERE phone = '138...';，重点看type字段：如果是ALL或index，基本就是没走有效索引 - 检查字段类型是否匹配：比如
phone是VARCHAR，但查询时传了数字138...（无引号），MySQL 会隐式转换，导致索引失效 - 复合索引顺序很重要：
INDEX(status, created_at)能加速WHERE status=1 ORDER BY created_at，但对WHERE created_at > '2024-01-01'完全无效
PHP 代码里反复查同一条数据？加一层简单缓存就行
SlowLog 里单条 SELECT 耗时不高（比如 80ms），但每秒出现上百次，说明是高频低效查询。常见于用户登录态、配置读取、权限判断等场景。
- 别急着上 Redis：先用 PHP 的
apcu_fetch()+apcu_store()缓存结果，5 行代码就能压掉 90% 重复查询 - 注意过期时间别设太长——比如用户角色变更后，缓存要主动失效，而不是等自然过期；用
apcu_delete('user_role_123')比设 1 小时 TTL 更可控 - 避免缓存“大对象”：不要缓存整个用户信息数组（含头像 URL、订单列表等），只缓存关键字段如
role_id、status
宝塔里开慢日志却看不到 PHP 脚本耗时？得配 slowlog 而不是只开 MySQL
很多人只在宝塔 → MySQL 设置里开了慢日志，结果发现网站卡顿，SlowLog 却空空如也——因为 PHP 层的阻塞（比如 curl 等待、文件锁、死循环）根本不会记到 MySQL 日志里。
- PHP-FPM 的慢日志才是真正定位脚本瓶颈的地方：在宝塔 → PHP 设置 → 配置修改 → 底部找到
request_slowlog_timeout = 1s，并确认slowlog = /www/wwwlogs/php_slow.log已启用 - 重启 PHP-FPM 后，再复现卡顿，立刻去查
/www/wwwlogs/php_slow.log，你会看到类似这样的记录：[24-May-2024 10:23:41] [pool www] pid 12345 script_filename = /www/wwwroot/site/index.php [0x00007f8b1c0a1234] file_get_contents() /www/wwwroot/site/lib/utils.php:45 - 注意：
request_slowlog_timeout值别设太小（如 100ms），否则日志爆炸；也别设太大（如 5s），会漏掉真实瓶颈
用了 file_get_contents 或 cURL 却没设超时？这是隐形拖垮响应的元凶
SlowLog 里查不到慢 SQL，PHP 慢日志也没记录，但页面就是卡 3 秒以上——十有八九是外部请求没设超时，卡在 DNS 解析、连接建立或远端不响应上。
-
file_get_contents('http://api.example.com')默认无限等待，必须显式加 context：$ctx = stream_context_create(['http' => ['timeout' => 3]]); file_get_contents($url, false, $ctx); - cURL 更要设全：
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 1000); curl_setopt($ch, CURLOPT_TIMEOUT_MS, 3000); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);，缺一不可 - 别信“本地测试很快”——生产环境跨机房、跨云厂商时，DNS 查询可能卡住 2 秒以上，不设
CONNECTTIMEOUT_MS就等于裸奔
真正卡住网站的，往往不是复杂算法，而是没设超时的 HTTP 请求、类型不匹配导致的索引失效、或者连缓存都懒得加的重复查询。这些点藏得浅，但没人盯就永远在那儿拖后腿。
