场景引入
兄弟们，我昨天差点把服务器砸了。
凌晨两点，客户疯狂打电话说网站打不开，我登录宝塔面板一看——CPU直接飙到98%，内存红线报警。
第一反应：重启！结果重启完不到十分钟，又卡成PPT。
后来我冷静下来，点开宝塔的「慢日志」功能，好家伙，真凶当场现形——一个早就该优化的SQL查询卡了整整12秒，每秒被调用80多次。
今天我就把这套“排雷大法”掰开揉碎了教给你，看完你也能像我一样，三分钟揪出那个拖垮网站的“内鬼”。
画面切换：登录宝塔面板，左侧菜单往下滑
第一步，先别急着看CPU曲线。
左侧找到「监控」→「慢日志」，这地方很多人压根没点开过。
注意了，慢日志不是“错误日志”，它记录的是执行时间超过阈值的数据库查询、PHP脚本和Nginx请求。
默认阈值一般是1秒，但咱们做优化，建议把它调成5秒——设置按钮在右上角，别手滑点成“清空日志”,不然数据没了你哭都来不及。
分步操作：定位MySQL慢查询
宝塔面板慢日志别乱删！三分钟定位拖垮网站的真凶，这波操作太顶了
- 点开「MySQL慢查询」标签页。
- 看那个「查询时间」列，如果发现好几条都超过2秒，恭喜，你中奖了。
- 复制那条最慢的SQL语句，丢到phpMyAdmin里执行一下，用
EXPLAIN看执行计划。
我前几天遇到一个典型案例：一张十万行的表，查询时没用索引，结果全表扫描。
解决办法？给where后面的常用字段加上索引，一条ALTER TABLE命令搞定，查询时间直接从3.2秒降到0.04秒。
关键配置特写：宝塔的慢日志文件位置在/www/server/data/mysql-slow.log，如果你用SSH打开，记得用tail -f实时盯梢,省得反复刷新页面。
画面切换：切到PHP-FPM慢日志
接下来处理PHP慢脚本。
在「慢日志」页签里选「PHP-FPM慢日志」，这里记录的是哪个脚本文件执行超时。
我之前遇到过一个插件，每天凌晨定时任务跑起来就卡死，日志里清清楚楚写着/www/wwwroot/xxx/wp-cron.php耗时58秒。
解决办法分两步：
- 第一步，打开该文件，看哪一行函数调用最耗时，八成是外呼API或者curl请求超时。
- 第二步，在宝塔的「PHP配置」里把
max_execution_time从30调大到60，同时request_terminate_timeout改成59——注意，后者要小于前者，不然会互相冲突。
常见错误提醒：千万别手贱把所有慢日志文件权限改成777，我见过有人这么干，结果直接被扫描器种了木马，慢日志文件变成“提权入口”,那才叫雪上加霜。
场景走查：用慢日志反向优化
慢日志不只是用来“查病”，还能用来“治未病”。
比如你发现某条Nginx请求慢，点开「Nginx慢日志」，看到某个静态资源请求耗时1.8秒——八成是没开Gzip压缩，或者图片没做CDN。
这时候去「软件商店」装个「宝塔配置器」，一键开启Gzip和缓存，再把图片链接替换成CDN地址，刷新页面，速度直接飞起。
有个兄弟跟我杠：“我加了CDN怎么还慢？”我一看慢日志，好家伙，请求的是源站IP，CDN配置根本没生效。
关键配置特写：在「网站」→「反向代理」里，把缓存过期时间设成24小时，静态资源设7天，动态请求绕开缓存——这个度你得自己拿捏，否则用户更新了文章看不到新内容,又来找你麻烦。
画面切换：脚本监控与告警
最后教你一招进阶的。
宝塔的慢日志只能看历史，不能实时告警。
我自建了一个小脚本：每两分钟用grep扫一遍慢日志文件，如果发现新记录的查询时间超过5秒，就发邮件+钉钉通知。
具体操作：在「计划任务」里添加Shell脚本，内容大概这样：
awk '$2 > 5 {print}' /www/server/data/mysql-slow.log | tail -5 | mail -s "慢查询告警" you@email.com
脚本里用绝对路径，别用相对路径，否则cron跑起来容易找不到文件。
常见错误提醒：日志文件默认按天滚动，你如果设了“按月保留”，小心磁盘爆掉，宝塔里默认只保留7天，够用就行,别贪多。
结尾收束
今天这波操作，你学会了吗？
说白了，慢日志就像服务器的“行车记录仪”，出事时别急着甩锅给机房，先翻翻它，十有八九是自己代码挖的坑。
下次网站再卡成狗，记得先打开宝塔面板，点开慢日志，三分钟定位真凶——比我凌晨的狼狈样帅多了。
如果你也遇到过什么奇葩慢日志案例，欢迎评论区一起“晒尸”,咱们互相长长见识。
发表评论