站点响應變慢、後台频繁轉圈、偶尔蹦出 502，很多人的第一反應是带宽不够或服務器配置太低。但實际排查下来，資料库往往是那個安静的瓶颈。一個頁面看起来只是列表加詳情，背後可能跑了三四十條查询，其中一條没走索引，整站的平均响應時間就被它拖長了。
這里说的自查，不是让你去改資料库内核，而是先能看懂現象、找到方向，再决定是自己處理還是找运维配合。
先弄清楚資料库在承受什么
连接數有没有逼近上限
很多面板和云資料库控制台都能看到目前连接數。如果空闲时段也長期占着上限的七八成，說明连接没有被及时释放，或者有慢查询把连接一直占着不放。這时候加机器是治标，先看是谁在占着连接才是關键。
慢查询日誌是否打開
慢查询日誌是性價比最高的排查入口。打開後設定一個合理的阈值，比如一秒，跑一段時間再看记錄。你會很快發現某些查询被反复执行了几百上千次，這類查询往往就是優化的第一顺位。
表体积和索引是否失控
文章、评论、訪問日誌、表單记錄，這些表通常只增不减。如果附件和日誌都塞在同一張表里，單表涨到几百兆甚至几個 G，随便一個查询都會變慢。看看每張表的行數和占用空間，心里先有個數。
几類常见的拖慢来源
- 缺少索引：按栏目、按時間、按狀態篩選的字段没有索引，查询只能全表掃描。
- 索引失效：字段上加了函數、做了隐式類型轉換，或者用了前置通配的模糊匹配，索引就用不上了。
- 查询次數過多：循环里逐條查資料，頁面上有五十條记錄就查五十次，改成一個批量查询往往立竿见影。
- 無用資料堆积：修订版本、垃圾评论、過期缓存、几年前的訪問日誌一直留着，白占空間也拖慢备份。
- 過度依赖插件：一些統計和缓存插件會自己建表、自己查询，装上之後没人再看，却一直在跑。
一份可执行的自查清單
- 確認目前连接數與峰值，记錄下高峰时段的大致數值。
- 打開慢查询日誌，把阈值设為 1 秒，观察一到三天。
- 把记錄里出現频率最高的几條查询挑出来，確認它們對應的是哪些頁面。
- 检查這些查询涉及的字段有没有索引，索引是否被正确使用。
- 統計各表行數與占用空間，找出增長最快的两三張表。
- 確認备份任務是否因為這些大表而超时，必要时做資料归档或清理。
- 清理已停用的插件留下的表和定时任務。
- 改動前後各记錄一次頁面响應時間，用資料判断有没有改善。
動手时的几点提醒
加索引、删資料、改表结构，都属于不可逆操作。任何改動都先在备份上做一遍，確認無誤再上生产；大表加索引尽量放在低峰时段，避免鎖表把訪客挡在外面。
資料库自查不需要一次做完所有事。先把慢查询日誌打開，让它替你说话，從出現频率最高的那條查询開始處理，通常几轮下来就能感受到變化。真正需要警惕的不是某一刻的慢，而是長期没人看、也没人知道它在慢。