站点訪問變慢时，很多人第一反應是带宽不够、前端资源太大，或者服務器配置太低。實际排查下来，資料库往往是更常见的原因：一條没有走索引的查询，就足以把整頁响應時間從几百毫秒拉到几秒。對运营者来说，不需要會寫复杂 SQL，但需要知道從哪几個方向评估，才能和開發、运维有效沟通。
先分清是資料库慢，還是別的地方慢
打開一個頁面，如果静態资源加载正常，HTML 却迟迟不返回，或者刷新几次速度差异很大，資料库值得優先怀疑。相反，如果首屏文字出現很快、图片和样式慢慢加载，多半是前端资源和網絡的問题。
更直接的判断方式是看應用日誌里的响應時間，或者临时開啟慢查询记錄，對比正常时段和高峰时段的差异。
慢查询日誌：先找到最慢的那几條
大多數資料库都支持慢查询日誌，记錄执行時間超過阈值的语句。開啟後不用急着優化全部，先按耗时和出現次數排序，通常少數几條就占了大部分時間。
- 設定一個合理的阈值，例如超過 200 毫秒先记錄，避免日誌量過大。
- 观察一段時間，覆盖日常訪問、後台批量操作等不同场景。
- 把出現频率高、單次耗时長的语句單獨列出来，作為優化候選。
如果日誌里出現大量结构相似的语句，只是參數不同，通常說明代碼在循环里逐條查询，這類問题比單條慢查询更值得處理。
索引：缺了不行，多了也麻烦
索引是慢查询最常见的突破口。列表頁按時間排序、按分類篩選、按關鍵詞搜尋，如果没有對應索引，資料量一上来就會明顯變慢。
几個容易漏掉索引的位置
- 文章表的發布時間、更新時間、狀態字段，用于前台列表和後台篩選。
- 分類、标簽與文章的關联表，查询某分類下内容时會频繁使用。
- 评论、訂單等明细表的關联字段。
- 站内搜尋使用的匹配字段，视具体實現决定是否需要全文索引或獨立检索服務。
另一方面，索引過多會拖慢寫入。每次發布、更新内容都要维護索引，所以應该结合真實查询来加，而不是给每個字段都建一個。
查询模式：一次請求打了几次資料库
有些頁面本身没有明顯慢查询，但一次訪問會發出几十次小查询，累积起来同样很慢。常见场景是列表頁循环讀取作者、分類、缩略图信息。可以观察一次請求的查询次數，把能合並的合並，能缓存的缓存。
连接數與缓存：小站也容易踩的坑
資料库连接數是有限资源。程序没有正确释放连接、長连接堆积，或者某個脚本並發過高，都可能让连接數被占满，表現為整站變慢甚至無法訪問。检查连接池配置、超时回收策略，並留意是否有異常脚本在後台執行。
缓存不是萬能的，但對變動不频繁的首頁、分類頁、热门文章列表，用缓存或静態化减少資料库压力，通常比反复優化 SQL 更省事。關键是設定合理的過期和主動刷新机制，避免内容更新後訪客還看到舊資料。
資料库優化不是一次性的工作。内容量、訪問量、查询模式都會變化，建议在每次大版本更新或流量明顯增長後，重新看一遍慢查询和连接情况。
运营侧可以做的几件事
- 保持資料库定期备份，並確認备份文件可以恢复，而不是只看文件是否存在。
- 给服務器和資料库留出足够磁盘空間，空間不足时寫入和临时表都會受影响。
- 後台的批量操作、資料導出、重新生成缓存等功能，尽量避開訪問高峰。
- 頁面响應變慢时，先记錄時間点和具体現象，再交给技術排查，比笼统地说“網站很慢”更有帮助。
資料库性能自查不需要一次做到完美。先把最慢的几條查询和最高的连接占用找出来，逐步解决，頁面响應速度通常會有可感知的改善。