站点访问变慢时，很多人第一反应是带宽不够、前端资源太大，或者服务器配置太低。实际排查下来，数据库往往是更常见的原因：一条没有走索引的查询，就足以把整页响应时间从几百毫秒拉到几秒。对运营者来说，不需要会写复杂 SQL，但需要知道从哪几个方向评估，才能和开发、运维有效沟通。
先分清是数据库慢，还是别的地方慢
打开一个页面，如果静态资源加载正常，HTML 却迟迟不返回，或者刷新几次速度差异很大，数据库值得优先怀疑。相反，如果首屏文字出现很快、图片和样式慢慢加载，多半是前端资源和网络的问题。
更直接的判断方式是看应用日志里的响应时间，或者临时开启慢查询记录，对比正常时段和高峰时段的差异。
慢查询日志：先找到最慢的那几条
大多数数据库都支持慢查询日志，记录执行时间超过阈值的语句。开启后不用急着优化全部，先按耗时和出现次数排序，通常少数几条就占了大部分时间。
- 设置一个合理的阈值，例如超过 200 毫秒先记录，避免日志量过大。
- 观察一段时间，覆盖日常访问、后台批量操作等不同场景。
- 把出现频率高、单次耗时长的语句单独列出来，作为优化候选。
如果日志里出现大量结构相似的语句，只是参数不同，通常说明代码在循环里逐条查询，这类问题比单条慢查询更值得处理。
索引：缺了不行，多了也麻烦
索引是慢查询最常见的突破口。列表页按时间排序、按分类筛选、按关键词搜索，如果没有对应索引，数据量一上来就会明显变慢。
几个容易漏掉索引的位置
- 文章表的发布时间、更新时间、状态字段，用于前台列表和后台筛选。
- 分类、标签与文章的关联表，查询某分类下内容时会频繁使用。
- 评论、订单等明细表的关联字段。
- 站内搜索使用的匹配字段，视具体实现决定是否需要全文索引或独立检索服务。
另一方面，索引过多会拖慢写入。每次发布、更新内容都要维护索引，所以应该结合真实查询来加，而不是给每个字段都建一个。
查询模式：一次请求打了几次数据库
有些页面本身没有明显慢查询，但一次访问会发出几十次小查询，累积起来同样很慢。常见场景是列表页循环读取作者、分类、缩略图信息。可以观察一次请求的查询次数，把能合并的合并，能缓存的缓存。
连接数与缓存：小站也容易踩的坑
数据库连接数是有限资源。程序没有正确释放连接、长连接堆积，或者某个脚本并发过高，都可能让连接数被占满，表现为整站变慢甚至无法访问。检查连接池配置、超时回收策略，并留意是否有异常脚本在后台运行。
缓存不是万能的，但对变动不频繁的首页、分类页、热门文章列表，用缓存或静态化减少数据库压力，通常比反复优化 SQL 更省事。关键是设置合理的过期和主动刷新机制，避免内容更新后访客还看到旧数据。
数据库优化不是一次性的工作。内容量、访问量、查询模式都会变化，建议在每次大版本更新或流量明显增长后，重新看一遍慢查询和连接情况。
运营侧可以做的几件事
- 保持数据库定期备份，并确认备份文件可以恢复，而不是只看文件是否存在。
- 给服务器和数据库留出足够磁盘空间，空间不足时写入和临时表都会受影响。
- 后台的批量操作、数据导出、重新生成缓存等功能，尽量避开访问高峰。
- 页面响应变慢时，先记录时间点和具体现象，再交给技术排查，比笼统地说“网站很慢”更有帮助。
数据库性能自查不需要一次做到完美。先把最慢的几条查询和最高的连接占用找出来，逐步解决，页面响应速度通常会有可感知的改善。