站点响应变慢、后台频繁转圈、偶尔蹦出 502，很多人的第一反应是带宽不够或服务器配置太低。但实际排查下来，数据库往往是那个安静的瓶颈。一个页面看起来只是列表加详情，背后可能跑了三四十条查询，其中一条没走索引，整站的平均响应时间就被它拖长了。
这里说的自查，不是让你去改数据库内核，而是先能看懂现象、找到方向，再决定是自己处理还是找运维配合。
先弄清楚数据库在承受什么
连接数有没有逼近上限
很多面板和云数据库控制台都能看到当前连接数。如果空闲时段也长期占着上限的七八成，说明连接没有被及时释放，或者有慢查询把连接一直占着不放。这时候加机器是治标，先看是谁在占着连接才是关键。
慢查询日志是否打开
慢查询日志是性价比最高的排查入口。打开后设置一个合理的阈值，比如一秒，跑一段时间再看记录。你会很快发现某些查询被反复执行了几百上千次，这类查询往往就是优化的第一顺位。
表体积和索引是否失控
文章、评论、访问日志、表单记录，这些表通常只增不减。如果附件和日志都塞在同一张表里，单表涨到几百兆甚至几个 G，随便一个查询都会变慢。看看每张表的行数和占用空间，心里先有个数。
几类常见的拖慢来源
- 缺少索引：按栏目、按时间、按状态筛选的字段没有索引，查询只能全表扫描。
- 索引失效：字段上加了函数、做了隐式类型转换，或者用了前置通配的模糊匹配，索引就用不上了。
- 查询次数过多：循环里逐条查数据，页面上有五十条记录就查五十次，改成一个批量查询往往立竿见影。
- 无用数据堆积：修订版本、垃圾评论、过期缓存、几年前的访问日志一直留着，白占空间也拖慢备份。
- 过度依赖插件：一些统计和缓存插件会自己建表、自己查询，装上之后没人再看，却一直在跑。
一份可执行的自查清单
- 确认当前连接数与峰值，记录下高峰时段的大致数值。
- 打开慢查询日志，把阈值设为 1 秒，观察一到三天。
- 把记录里出现频率最高的几条查询挑出来，确认它们对应的是哪些页面。
- 检查这些查询涉及的字段有没有索引，索引是否被正确使用。
- 统计各表行数与占用空间，找出增长最快的两三张表。
- 确认备份任务是否因为这些大表而超时，必要时做数据归档或清理。
- 清理已停用的插件留下的表和定时任务。
- 改动前后各记录一次页面响应时间，用数据判断有没有改善。
动手时的几点提醒
加索引、删数据、改表结构，都属于不可逆操作。任何改动都先在备份上做一遍，确认无误再上生产；大表加索引尽量放在低峰时段，避免锁表把访客挡在外面。
数据库自查不需要一次做完所有事。先把慢查询日志打开，让它替你说话，从出现频率最高的那条查询开始处理，通常几轮下来就能感受到变化。真正需要警惕的不是某一刻的慢，而是长期没人看、也没人知道它在慢。