高并发数据库服务器的核心指标，不是CPU使用率，也不是内存大小，而是吞吐量、延迟、连接数、锁等待与磁盘IOPS这五类关键项的协同健康度。只盯单一指标，就像只看体温不看心跳，无法判断数据库是否真的撑得住，下面按权重从高到低拆解，每个指标都告诉你“看什么、怎么看、阈值多少”。
吞吐量：判断数据库“干了多少活”
QPS与TPS是第一个分水岭
QPS（每秒查询数）代表读压力，TPS（每秒事务数）代表写压力，高并发场景下，你首先要区分是读多还是写多，业内专家指出，大部分互联网业务的读写比例在7:3到9:1之间,这意味着QPS往往先于TPS触顶。
- 只看总和会误判：QPS高但TPS很低，说明是缓存没命中，查询打到数据库了，TPS高但QPS低，说明业务偏写入，比如订单、日志系统。
- 峰值比均值重要：平均值10万QPS，但秒杀瞬间冲到50万，数据库可能在第3秒就崩了，用监控工具看1分钟粒度的峰值,比看5分钟均值靠谱得多。
- 实际操作：在MySQL里执行
SHOW GLOBAL STATUS LIKE 'Questions'，间隔10秒取两次差值再除以10，就是实际QPS，更省事的是用Prometheus配mysql_exporter,直接出曲线图。
吞吐量突降比突增更危险
数据库吞吐量突然掉了一半，不是业务没人用了，大概率是出现了慢查询锁表、连接池耗尽或磁盘IO卡死，这时候去看慢查询日志和InnoDB状态,通常能发现一条执行了十几秒的SQL把整个表锁住了。
延迟：衡量用户“等多久”
延迟的四个层次
高并发下，延迟不是单一数字，从用户点击到数据库返回，中间隔着网络、应用、连接池、数据库执行四层，数据库侧最该关注的是执行时间和响应时间。
- 响应时间：客户端从发出SQL到收到结果的完整耗时,包括排队等待时间。
- 执行时间：SQL真正在存储引擎里跑的时间，如果两者差值大,说明请求在连接池或锁上等太久了。
99分位比平均延迟更有价值
平均延迟100ms，看起来不错，但99分位的用户可能已经等了2秒，高并发场景下,长尾延迟才是用户流失的元凶。
- 等于或低于
100ms
：正常状态,用户无明显感知。 - 100ms到500ms：可以接受,但需要关注峰值时段。
- 大于500ms：说明数据库已经过载，要么有慢查询，要么锁竞争严重,要么磁盘IO扛不住了。
排查延迟的实操路径
- 开启慢查询日志：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; - 拿到慢SQL后，用
EXPLAIN看执行计划，重点看type列是不是ALL（全表扫描）、rows估算行数是否过大。 - 用
SHOW ENGINE INNODB STATUS\G查看当前事务和锁等待信息,定位是否在等锁。
连接数：数据库的“接待能力上限”
连接数不是越大越好
很多人以为连接数开到2000就能扛2000个并发，这是误区，每个连接都要占用线程、内存和文件描述符，连接太多反而会导致上下文切换频繁，CPU全部耗在调度上,真实请求反而处理得更慢。
推荐配置参考：
| 场景 | 连接数建议 | 说明 |
|---|---|---|
| 常规业务 | 200-500 | 配合应用层连接池使用 |
| 高并发读多写少 | 500-1000 | 需要配合读写分离 |
| 极高并发 | 1000以上 | 强烈建议加缓存层或分库分表 |
连接池的坑
应用层连接池（如HikariCP、Druid）的初始大小和最大大小设置不合理，会直接压垮数据库，常见错误是应用启动时把连接池最小空闲设成50，100个应用实例同时启动，瞬间产生5000个数据库连接,数据库直接OOM。
- 检查连接池配置：最大连接数不要超过数据库
max_connections的70%。 - 查看当前连接数：
SHOW STATUS LIKE 'Threads_connected'; - 查看连接创建次数：
SHOW STATUS LIKE 'Connections';和SHOW STATUS LIKE 'Aborted_connects';，后者高说明有客户端连接失败,可能是密码错误或连接数满了。
锁等待与死锁：高并发写入的最大隐形杀手
锁等待时间飙升意味着什么
当多个事务同时更新同一行或同一区间数据时，InnoDB会加行锁，高并发下，锁等待时间一旦飙高，吞吐量和延迟会同时恶化，最典型的场景是库存扣减：1000个并发请求同时更新同一件商品的库存，只有一个能成功,其他999个都在等锁。
关键监控指标：
- Innodb_row_lock_current_waits：当前正在等待行锁的事务数。
- Innodb_row_lock_time_avg：平均每次行锁等待的毫秒数，这个值长期超过200ms就不正常了。
- Innodb_deadlocks：死锁发生次数,正常情况下应该为0或极少。
处理锁问题的三板斧
- SQL优化优先：把UPDATE语句的WHERE条件尽量走索引,缩小锁定的行范围。
- 事务缩短：事务里不要做远程调用、消息推送等外部操作,这些操作会无限拉长锁的持有时间。
- 重试机制兜底：死锁无法100%避免，在应用层捕获死锁错误码（MySQL是1213），做3次重试,间隔100ms。
磁盘IOPS与延迟：数据库的“苦力输出”
慢磁盘是隐形的性能天花板
CPU再快，内存再大，数据最终要落到磁盘，高并发写入场景下，磁盘IOPS不够，数据库就会在fsync阶段卡住，表现为写入延迟飙升、事务提交变慢，行业共识认为，数据库服务器的磁盘选型优先级是：NVMe SSD > SATA SSD > 机械硬盘,机械盘在高并发写入场景下基本不可用。
如何判断磁盘是否成为瓶颈
- iostat -x 1：看
%util是否长时间大于80%，await是否高于20ms。 - MySQL的Innodb_data_fsyncs：每秒的fsync次数，如果这个值和磁盘IOPS上限接近,说明磁盘已经饱和。
- 日志刷盘参数：
innodb_flush_log_at_trx_commit = 1是最安全也最慢的配置，每次事务提交都要刷盘，如果业务对数据一致性要求略低，可以设为2,性能会有明显提升。
具体优化路径
- 先用
iostat确认瓶颈在磁盘,不要盲目加内存。 - 将数据库数据文件和日志文件分开放到不同磁盘,减少读写竞争。
- 调整
innodb_io_capacity和innodb_io_capacity_max参数，让InnoDB后台刷脏页的速度匹配磁盘能力，设置过高会造成磁盘抖动,设置过低会导致脏页堆积。
缓存命中率与慢查询：两个容易被忽略的“帮凶”
缓存命中率怎么算
InnoDB的缓冲池命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests，命中率低于95%,说明内存缓冲池不够大或数据访问模式有问题。
- 调大
innodb_buffer_pool_size，最直接，建议设置为可用内存的60%-70%。 - 检查是否全表扫描把整个缓冲池冲垮了，一条慢SQL扫几百万行,热数据全被挤出缓冲池。
慢查询的评判标准
不是所有慢查询都致命，但每条慢查询在高峰期都是潜在的数据库杀手,一个简单的判断基准：
- 单次执行超过1秒的查询,需要优化。
- 单次执行超过5秒的查询,必须立即处理。
- 慢查询日志里如果同一个SQL反复出现,说明业务侧SQL写法有系统性问题。
Q&A：高并发数据库常见疑问速答
高并发数据库服务器CPU使用率多少算正常？
没有固定答案，如果CPU长时间在80%以上且伴随QPS不再增长，说明CPU是瓶颈，如果是SQL排序、聚合操作导致CPU高，优化空间在SQL本身；如果是逻辑读（buffer pool命中后CPU解析行）过高,优化空间在内存和索引。
高并发数据库需要多少内存才够用？
取决于热数据量，你把整个数据库比作一个书架，内存是桌面，桌面越大，需要频繁去书架取书的次数越少，把innodb_buffer_pool_size设为热数据量的1.2到1.5倍，能获得不错的性价比，超出这个范围,加内存的收益会明显递减。
高并发场景下数据库连接数设置多少合适？
优先看应用侧的连接池总和，假设你有20个应用实例，每个连接池最大50，高峰期峰值并发是1000个请求，那数据库的max_connections设置1200左右即可，给数据库自身预留一点余量，连接数不是越高越好,能快速响应请求的连接数才是健康的连接数。
高并发数据库的指标监控，本质上是一套组合拳，吞吐量是结果，延迟是体验，连接数是容量，锁等待是隐患，磁盘IO是底座，当你把这五个指标放在同一张监控大盘里，观察它们之间的联动关系,比看任何单一指标都更能准确判断数据库的真实健康状况。