学完这篇，你能用一套可落地的办法，把慢查询、连接数、QPS、主从延迟这四个最关键的数据库指标采集起来，并为它们设置阈值告警。你不必购买商业监控，也不用改系统代码。
第一步：开启慢查询日志，让慢查询有据可查
慢查询是所有数据库问题的源头。先在 MySQL 配置文件（my.cnf / my.ini）的 [mysqld] 段加上：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
改完后重启 MySQL 服务。进入 Clara BBS 后台，在容量监控插件里可以看到 MySQL 慢查询 TOP 榜，它直接读取慢日志并按耗时排序，哪个 SQL 慢一目了然。
注意：long_query_time 不要设成 0.1 秒以下，否则日志会迅速占满磁盘，采集出的 TOP 榜也全是无效记录。慢日志需要 MySQL 的 FILE 权限，宝塔面板默认路径一般在 /www/server/data/ 下，别填错。
第二步：采集连接数和 QPS
这两个指标不需要开启慢日志，用 SHOW GLOBAL STATUS 获取即可：
SHOW GLOBAL STATUS WHERE Variable_name IN (
'Threads_connected','Threads_running','Max_used_connections',
'Questions','Uptime','Aborted_connects'
);
- 连接数看
Threads_connected，再对照 max_connections 算占用率。
- QPS 用两次采样计算：
(Questions2 - Questions1) / (Uptime2 - Uptime1)。
注意：Threads_connected 高不一定是压力大，Threads_running 才是真正在执行的线程数。如果连接数升高而 Threads_running 很低，多半是连接没有释放或连接池配置有问题；如果两个都高，基本就是慢查询堆积，先回到第一步。
第三步：主从延迟，读写分离场景必须监控
如果你的站已经配置了读写分离，从库延迟会直接造成“刚发的帖刷不出来”。检查命令：
SHOW SLAVE STATUS\G
重点看 Slave_IO_Running、Slave_SQL_Running 是否为 Yes，以及 Seconds_Behind_Master 是否持续增长。
Clara BBS 的读写分离规则是：SELECT / SHOW / DESCRIBE / EXPLAIN 自动走从库，写操作走主库；事务内查询、行锁查询、读取自增 ID 这三种场景会强制走主库，以保证一致性。从库连接失败时，系统会静默回退到主库，并记录日志，业务不会察觉。
注意：Seconds_Behind_Master = 0 并不等于没有延迟；如果遇到大事务或从库时钟不准，它可能显示为 0，但实际已经落后。更稳妥的做法是定期在主库写入一个时间戳，再在从库读出来做差。另外，从库一旦出问题，系统会回退到主库；主库压力会瞬间上升，所以从库故障必须立刻告警，不能等到第二天才看日志。
第四步：把采集挂到计划任务上
不要靠手动执行命令。Clara BBS 有计划任务体系，用 Cron::register 统一注册，两种触发方式：
- 前台懒触发：安装完成后就会有，不需要配置，但前提是网站有访问量；
- 外部入口
/cron 精准触发：流量大的站，建议在系统层面配置 crontab，每分钟调用一次。
* * * * * curl -s https://你的域名/cron > /dev/null 2>&1
任务带文件锁，可以防止并发重复执行，运行结果会写入数据库，可查。
注意：如果你的站访问量少，又只依赖懒触发，采集会出现“空档”，指标曲线会被拉平，导致误判；这种情况必须配置 crontab。采集频率也不要设成 5 秒一次，一分钟一次对中小社区完全够用，频率太高会给自己增加负载。
第五步：确认阈值，并利用现有数据判断扩容时机
建议的初始阈值：
| 指标 | 告警线 |
|---|
| 连接数占用率 | 超过 max_connections 的 70% |
| 慢查询 | 每分钟超过 5 条 |
| QPS | 相对历史同时段突增 2 倍 |
| 主从延迟 | 超过 30 秒，或 SQL 线程停止 |
容量监控仪表盘的每日快照、增长曲线和阈值进度，会按当前增速推算“多久之后需要升级架构”，这比凭感觉判断更可靠。数据库大了，加从库还是换更大的服务器，看这条曲线就能决定。
注意：告警要分级。连接数达到 70% 时可以推送提醒，达到 90% 时才触发强告警。如果所有指标都往同一个通道发通知，几天后你就不会再关注它了。
小结
- 慢查询：先开启慢日志，再看慢查询 TOP 榜，
long_query_time 不要设得过小。
- 连接数：关注
Threads_running，不要只看 Threads_connected。
- QPS：用
Questions 和 Uptime 两次采样的差值来计算，不要在单次查询里自己猜测。
- 主从延迟：
Seconds_Behind_Master = 0 不等于没有延迟；从库回退到主库会压垮主库，必须实时告警。
- 采集必须挂到计划任务上，流量少的站务必配置 crontab，不要只靠懒触发。
- 阈值分级、容量外推，用数据决定什么时候加从库、什么时候换服务器。
见习用户
正式会员
认证极客
钻石卡会员
