服务器频繁被数据库请求拖垮，核心原因是数据库响应变慢或连接积压，排查顺序建议从慢查询、连接数、索引失效、缓存命中率这四个维度入手，逐一排除后针对性优化。
数据库CPU飙高怎么办？先看这几项指标
服务器报警时，登录后台第一件事不是重启，而是抓现场，数据库被"请"到资源耗尽，多数情况不是攻击，而是某个查询把CPU吃满了，通过系统命令快速定位,比盲目重启有效得多。
用top命令确认资源消耗源头
执行top -c，观察CPU占用排在前列的进程，如果看到mysqld或postgres进程占用超过200%（多核环境下），说明数据库内部确实有重负载操作，同时看load average，1/5/15分钟三个值如果持续走高，不是瞬时抖动,需要深挖。
查看数据库当前连接状态
连接数爆炸是数据库被"请"的常见导火索，登录数据库执行show processlist;（MySQL）或select from pg_stat_activity;（PostgreSQL），重点看State列和Info列，大量连接卡在Sending data或Copying to tmp table,基本可以断定是慢查询拖住了线程。
区分两类常见场景：查询慢还是写入慢
- 查询慢：多数涉及大表全表扫描，或关联查询缺索引,或排序字段无索引。
- 写入慢：多与锁等待相关，行锁、表锁、间隙锁堆积,后续会话全部排队。
业内专家指出，生产环境中超过7成的数据库性能问题源于未命中的索引和低效的SQL写法,而非硬件资源不足。
服务器被数据库拖垮该如何排查？从三个环节入手
排查要沿着"请求入口→SQL执行→存储引擎"这条链路走,每一步都有对应的验证方法。
第一步：看慢查询日志是否存在堆积
确认慢查询日志是否开启，以及阈值设置是否合理，运行SHOW VARIABLES LIKE 'slow_query_log%';，如果日志没开，先开启并设置long_query_time=2（单位秒），让超过2秒的查询落盘，接着分析慢日志，按执行次数和耗时排序，找出Top N的SQL。
常见写法问题包括：
SELECT取回了大量无用列,产生不必要的网络IO和内存消耗。- 在WHERE条件列上使用函数运算，比如
WHERE DATE(create_time)='2026-01-01',导致索引失效。 - 深分页场景使用
LIMIT 100000, 20,数据库仍要扫描前十万行再丢弃。 - 关联查询时驱动表选错,小表驱动大表的规则没有遵循。
第二步：检查数据库连接数是否到达峰值
SHOW VARIABLES LIKE 'max_connections'; 查看最大连接数配置，同时对比当前连接数，如果经常顶满，说明连接池设置或应用侧连接管理有问题，部分框架如Spring Boot默认连接池参数不够合理,高并发下会快速打满数据库连接。
调整建议：
- 减少应用层连接池的initialSize和maxActive,避免空闲连接占坑。
- 增加数据库端的wait_timeout和interactive_timeout,让僵死连接尽快释放。
- 考虑引入ProxySQL或MyCat等中间件做连接复用,减少后端直连压力。
第三步：用EXPLAIN分析执行计划
MySQL连接数过多如何排查，执行计划是SQL优化最直观的依据，在慢SQL前加EXPLAIN，输出中重点关注type字段从const到eq_ref到ref到range到index到ALL，性能依次递减，如果看到ALL（全表扫描）,务必检查WHERE列是否有合适索引。
rows字段估算扫描行数，如果实际返回100行却扫描了100万行，说明索引区分度差或根本没走索引，这时建立联合索引，注意字段顺序区分度高的放前面。
数据库性能优化哪个方案好？从缓存到读写分离
排查完问题，接下来看怎么治本，方案排序从低成本到高成本,逐层升级。
优化SQL和索引结构
单条SQL性能从1秒降到10毫秒，最直接的回报，用覆盖索引减少回表，用前缀索引节省空间，用冗余字段避免JOIN，列表页查询只取主键和展示字段,详情页再回表查全量。
注意细节：
- 联合索引遵循最左前缀原则,查询条件不含最左列时索引失效。
IN和BETWEEN的范围查询，MySQL 8.0之后有优化,但超过一定数量还是建议拆分。- LIKE以开头无法使用索引,考虑全文索引或Elasticsearch替代。
引入Redis做缓存层
读多写少的场景，缓存是性价比最高的方案，把热点数据（如用户信息、商品详情、配置项）缓存到Redis，设置合理过期时间（比如30分钟加随机偏移，防止缓存雪崩）,缓存击穿和穿透问题也要提前预防：
- 穿透：查询不存在的数据，缓存和数据库都查不到,用布隆过滤器拦截。
- 击穿：热点key过期瞬间大量请求打到数据库,用互斥锁或逻辑过期重建缓存。
- 雪崩：大量key同时失效,配合随机过期时间或集群分片解决。
读写分离和分库分表
当单库写压力也很大时，考虑主从复制加读写分离，主库负责写事务，从库分担读流量，从库可以挂多个,配合负载均衡策略分发流量。
但读写分离有数据延迟问题，刚写入的数据立刻查询可能读不到，解决方式是对实时性要求高的操作强制走主库,比如用户下单后立刻查订单状态。
分库分表的代价更高，需要拆键（如按用户ID取模）、处理跨库JOIN和分布式事务，一般到单表数据量超过千万级再考虑，行业共识认为，多数业务在亿级数据量之内,通过索引优化和缓存就能扛住日常流量。
服务器配置和数据库版本要不要升级
优化做到位了，硬件还是不够,那才轮到升级配置。
怎么看当前资源够不够用
用vmstat和iostat观察CPU空闲率、IO等待时间，如果wa（IO等待）常年在30%以上，磁盘读写是瓶颈，升级SSD或增加内存（用于扩大buffer pool）更有效，如果CPU用户态占用高但IO不忙，是计算密集,升级CPU核心数有帮助。
云数据库和自建数据库哪个划算
这个选择取决于团队运维能力和业务规模，自建数据库自由度大，可以深度定制参数，但需要自行处理备份、高可用、扩容，云数据库（如RDS）开箱即用，自动备份和主备切换都有，但实例费用较高,且部分高级参数需要提工单调整。
预算敏感且有一定运维积累的团队，自建+走PXC或MGR方案能省下一笔钱，追求稳定和快速交付,选云数据库。
数据库连接数过高如何预防
治标之后要治本,把预防措施做成常态化。
建立慢查询监控和告警
用Prometheus加Grafana监控数据库指标，连接数、QPS、慢查询次数、临时表数量这些关键项配置告警，当慢查询次数超过阈值时，第一时间通知到人,而不是等用户反馈页面打不开。
定期用工具做SQL审查
把慢查询日志导入工具，用pt-query-digest做分析，或者用简米云的CloudDBA这类云端工具，每周安排一次例行审查,排查新上线的功能是否带了低效SQL。
给数据库设置资源上限
用MySQL的MAX_USER_CONNECTIONS限制单用户连接数，防止某个业务账号异常占用全部连接，SQL层面可以用max_execution_time设置超时，超过就杀掉,避免单个查询把CPU吃满。
云数据库和自建数据库哪个安全，其实取决于备份策略是否可靠，无论哪种方案，确保有自动备份、定期做恢复演练,才能在事故发生时快速救场。
常见问题速答
服务器CPU突然100%，如何快速定位是否数据库导致的？
先执行top -c看进程列表，确认mysqld或postgres的CPU占用率，如果数据库进程占用较高，接着show processlist;看当前执行的SQL，重点找长时间运行的查询，再结合慢查询日志和监控面板，确认是偶发还是持续性问题,大概率能从SQL层找到根因。
数据库CPU飙高怎么办，直接杀进程好吗？
不建议直接kill所有数据库进程，会造成数据丢失或不一致，正确做法是先抓住耗资源的SQL，用kill query终止单个慢查询，如果连接数被占满无法登录数据库，可以先把应用服务停掉，腾出资源再排查，事后要分析慢查询日志,找到源头SQL改写优化。
为什么加了很多索引，查询还是慢？
索引不是越多越好，如果查询条件左侧列使用了函数或隐式类型转换，索引会失效，另一个常见问题是索引基数低（比如性别列），优化器判断走索引还不如全表扫描快，会自动放弃索引，还有SQL写法中OR连接多个条件、JOIN时字符集不一致等情况，都会导致索引无法生效，建议用EXPLAIN确认实际执行计划,而不是看建了多少索引。