数据库存：产品技术团队实施建议：围绕性能优化稳步提升提高并发能力

数据库并发能力上不去时，最容易出现的错误不是“没有做优化”，而是团队优化得太快：接口一慢就加连接池，CPU 一高就加机器，报表一重就上缓存，最后甚至还没有确认瓶颈位置，就开始讨论分库分表。我的判断是，数据库性能治理首先是一项定位和取舍工作，其次才是 SQL、索引、缓存和架构技术。只有把请求延迟、连接池等待、锁竞争、磁盘 I/O、数据访问模式放在同一条证据链上，产品技术团队才能在不牺牲稳定性的前提下，稳步提升并发能力。

这篇文章不把“高并发”理解成一个孤立的 QPS 数字，而是从产品、研发、测试、运维共同实施的角度，拆解数据库并发优化的判断顺序、具体步骤、典型误区、验证方法和不同阶段的技术取舍。文中的案例数据会明确区分公开资料、工程经验和情景模拟，避免把未经验证的提升比例包装成真实项目结果。

一、先讲核心结论：并发提升不是把数据库参数调大

1. 数据库并发能力由四个约束共同决定

在实际系统中，我不会只用“数据库每秒能处理多少请求”来描述并发能力。更有意义的定义是：在目标业务流量下，系统能否持续满足延迟、错误率、一致性和资源安全边界。

因此，数据库并发能力至少同时受到四类约束影响。第一类是单次请求的资源消耗，包括扫描行数、排序数据量、锁持有时间和网络传输量。第二类是请求之间的竞争，包括连接、CPU、磁盘、锁和缓存空间的竞争。第三类是访问模式，例如读多写少、热点写入、批处理和在线事务混在一起。第四类是业务容忍度，例如是否允许读写短暂不一致、是否可以异步处理、是否允许降级。

如果只看连接数，可能会把“更多请求排队”误认为“更强并发”；如果只看平均响应时间，可能会忽略高峰时 P99 已经严重恶化；如果只看数据库 CPU，则可能漏掉应用线程卡在连接池获取、锁等待或网络调用上的情况。

对产品技术团队来说，最重要的结论是：优化目标不应写成“把并发提升十倍”，而应写成“在某个峰值流量下，将核心接口 P99 控制在目标范围，错误率不超过阈值，同时数据库资源保持可持续”。

2. 优化顺序应遵循“低风险、可回滚、能验证”

我通常把数据库并发治理分为五个层次。第一层是确认瓶颈，第二层是 SQL、索引和数据访问治理，第三层是连接、事务和锁控制，第四层是缓存、读写分离和异步化，第五层才是分库分表、数据拆分和整体架构调整。

这个顺序并不是因为架构改造不先进，而是因为前面的基础问题往往成本更低、收益更容易验证。一个存在全表扫描、重复查询或长事务的系统，即使增加只读节点，也可能只是把低效访问复制到更多机器上。

1. 先确认是数据库慢，还是应用、网络、连接池或下游服务慢。
2. 建立高峰期性能基线，记录 QPS、P95、P99、错误率和资源指标。
3. 优先处理执行次数高、耗时长、扫描量大的核心 SQL。
4. 再治理连接池、事务边界、锁等待和热点写入。
5. 当基础优化仍无法满足容量目标时，再评估缓存、读写分离和异步化。
6. 只有出现明确的单库资源、数据规模或访问隔离瓶颈，才进入分库分表评估。

每一个阶段都应有退出条件。例如，SQL 优化阶段不能只写“完成索引调整”，而应要求高频慢查询数量下降、扫描行数减少、核心接口 P99 改善，并且写入性能没有明显恶化。

二、先从真实场景出发：为什么系统一加流量就变慢

1. 一个常见的业务场景：在线查询和分析任务争抢同一数据库

以数据分析、经营看板和业务查询系统为例，用户打开看板时通常会触发多个指标查询：销售额、订单数、客户数、区域排名、同比环比和明细列表。单个查询看起来并不复杂，但当多个图表同时加载、多个用户同时刷新，再叠加定时同步和批量计算时，数据库面对的不是一条 SQL，而是一组相互竞争的访问任务。

这类场景在九数云这类数据分析平台的业务使用方式中尤其值得关注。这里需要说明：下面是基于数据分析平台常见访问模式设计的情景案例，用于说明排查方法，不代表九数云官方披露的具体客户性能数据，也不构成对某个部署环境的性能承诺。

假设一家零售企业有 300 名内部用户，工作日上午九点集中打开经营看板。每次看板加载触发 12 个查询，其中 8 个查询读取聚合数据，4 个查询读取明细数据；同时，系统每 15 分钟执行一次销售数据同步。平峰时每秒约 25 次查询，高峰时短时间内升至 160 次。数据库并不一定马上 CPU 打满，但连接池等待、临时表、排序和磁盘读取可能同时上升。

如果团队只看“数据库 CPU 只有 55%”，很容易得出数据库还有余量的结论。但从用户角度看，页面可能已经从 2 秒打开变成 12 秒。原因可能是磁盘 I/O 等待、连接获取超时、多个查询同时争抢临时空间，或者某几个低频但极重的明细查询拖慢了整体任务。

这个案例最值得注意的地方是：高峰期问题不一定表现为数据库整体不可用，而可能先表现为少数关键请求的长尾延迟恶化。因此，产品团队需要关注“用户在高峰时最慢多久”，而不仅仅是“系统平均处理了多少请求”。

2. 先区分四种瓶颈，再决定优化方向

我在排查数据库慢问题时，会先把等待时间拆成四段：应用等待连接的时间、数据库排队或执行的时间、锁等待时间、结果返回和序列化时间。只要这四段没有拆开，团队就容易把所有问题都归到 SQL 上。

• 连接池等待：应用线程拿不到连接，但数据库可能仍有资源。常见原因是连接池过小、事务没有及时释放或单次请求占用连接时间过长。
• 执行计划问题：SQL 扫描了大量无关数据，或者排序、分组、关联操作产生了大量中间结果。
• 锁和事务问题：请求本身不慢，但被其他事务阻塞，最终呈现为间歇性超时。
• 存储和资源问题：磁盘 I/O、内存不足、缓存命中下降或临时空间不足，导致执行时间随并发快速增长。
• 应用访问问题：重复查询、循环查询、一次请求加载过多维度，导致数据库收到不必要的请求。

这四类问题的处理方式完全不同。连接池等待需要看应用实例数和连接占用时间；锁等待需要找长事务和热点行；执行计划问题需要看索引和数据分布；存储问题则要评估内存、磁盘和数据冷热分布。没有瓶颈分类，就没有可靠的优化方案。

三、常见误区：很多“优化动作”为什么反而让系统更不稳定

1. 误区一：把连接池调大，系统就能承受更多并发

连接池调大是最常见、也最容易被滥用的操作。应用实例数为 20，每个实例连接池上限为 50，理论上就可能向数据库发起 1000 个连接请求。可是数据库的 CPU、内存、锁和磁盘吞吐并不会因为连接数增加而同步增加。

当活跃连接超过数据库有效处理能力时，更多连接通常意味着更多排队、上下文切换和锁竞争。对于事务型业务而言，连接池过大还可能让大量请求同时进入关键区，导致响应时间从稳定状态突然恶化。

正确做法不是盲目调大连接池，而是建立一个整体关系：

数据库可承载连接数
≥ 应用实例数 × 单实例连接池上限

＋ 管理连接

＋ 运维和迁移连接

＋ 故障切换预留

这个关系只是容量规划的上限约束，不代表连接池应该直接设置成数据库最大连接数。实际配置还要结合单次 SQL 耗时、事务占用时间、实例数量、请求峰值和数据库并行处理能力。连接池大小应该通过压测逐步寻找拐点，而不是凭经验填写一个更大的数字。

2. 误区二：看到慢查询就加索引

索引不是免费的加速器。它会占用存储空间、增加写入成本、增加更新和删除成本，还可能让优化器选择并不适合当前数据分布的执行计划。

我判断一个索引是否值得增加，至少会看四件事：查询的执行频率、过滤条件的选择性、扫描行数与返回行数的比例、对写入链路的影响。一个每天只执行几次、但偶尔耗时较长的后台报表查询，不一定值得牺牲在线交易写入性能去建立复杂索引。

相反，一个每秒执行数百次、每次扫描几万行只返回几十行的查询，即使平均耗时只有几十毫秒，也可能是更值得优先处理的对象。索引优先级应该由“累计资源消耗”决定，而不是只看单次耗时。

3. 误区三：缓存可以解决所有数据库并发问题

缓存最适合解决的是重复读取和热点读取，不适合直接掩盖所有数据库问题。如果接口每次查询条件都不同，缓存命中率天然很低；如果数据更新频繁，缓存失效和一致性处理的成本可能超过查询本身；如果热点 Key 在同一时间集中失效，还可能产生缓存击穿，瞬间把压力回源到数据库。

在数据分析平台或经营看板中，缓存通常适合放在“已确认的热点聚合结果”上，例如当天销售汇总、固定维度的区域指标和相对稳定的字典数据。对于实时库存、订单状态或强一致的资金数据，是否缓存必须先由产品明确一致性边界，而不是由研发单方面决定。

4. 误区四：读写分离和分库分表是高并发系统的标配

读写分离会带来复制延迟、路由、故障切换和读写一致性问题；分库分表会带来分片键、跨分片查询、数据迁移和运维复杂度。它们解决的是特定规模和特定访问模式下的扩展问题，不是数据库性能优化的起点。

如果一个系统的主要问题是深分页、重复查询、批处理和在线事务争抢，那么分库分表很可能只是把问题分散到更多节点，并没有减少无效计算。只有当单库已经完成基础治理，且资源、数据量或访问隔离出现明确瓶颈时，才值得进入架构扩展阶段。

5. 误区五：平均响应时间下降，就代表优化成功

平均值非常容易掩盖长尾。假设 99% 的请求耗时 100 毫秒，1% 的请求耗时 20 秒，平均值可能仍然不高，但这 1% 可能恰好是核心客户、关键报表或高峰期请求。

我更关注 P95 和 P99 的变化，同时观察错误率、超时率、锁等待和连接池排队。一次优化如果平均响应时间下降 20%，但 P99 从 1 秒升到 8 秒，通常不能被视为成功。

四、专业判断逻辑：先建立证据链，再选择技术手段

1. 第一步：把用户看到的慢拆成可观测阶段

一次接口请求通常会经历网关排队、应用线程处理、获取数据库连接、执行 SQL、读取结果、序列化和网络返回。产品技术团队需要通过链路追踪或埋点，判断总耗时究竟集中在哪一段。

如果数据库执行耗时只有 100 毫秒，但连接池等待达到 800 毫秒，优化 SQL 可能不会改善用户体验；如果数据库执行 2 秒，其中 1.8 秒用于锁等待，那么单纯增加索引同样不一定有效。

2. 第二步：建立 SQL 的“频率 × 成本”排序

我不建议团队只从慢查询日志中挑最长的一条 SQL。更有效的方式是把 SQL 按“调用次数、平均耗时、总耗时、扫描行数、返回行数、错误次数”进行排序。

例如，SQL A 单次耗时 1.5 秒，每分钟执行 2 次；SQL B 单次耗时 80 毫秒，每秒执行 200 次。SQL A 的单次体验更差，但 SQL B 每分钟消耗的数据库执行时间约为 960 秒，可能才是整体资源消耗的主要来源。

累计执行时间
= 单次平均耗时 × 执行次数

优先级参考

= 累计执行时间 × 业务重要性 × 高峰影响系数

这个公式不是数据库产品的标准算法，而是我在团队排期时使用的简化排序方法。它的价值不在于计算出绝对正确的分数，而在于让研发、产品和运维围绕同一组事实讨论优先级。

3. 第三步：用执行计划验证索引，而不是凭字段名称猜测

“查询条件里有索引字段”并不等于索引一定生效。数据选择性、联合索引顺序、隐式类型转换、函数计算、模糊匹配方式和统计信息，都可能改变优化器的选择。

检查执行计划时，我会重点关注访问类型、估算行数、实际扫描行数、过滤比例、排序方式和关联顺序。尤其要比较估算行数和实际行数，如果两者差距很大，可能需要更新统计信息、检查数据倾斜或重新评估索引设计。

对于分页查询，前几页很快而后几页越来越慢，是非常典型的深分页问题。数据库可能需要先扫描并丢弃大量前置记录，再返回目标页。此时可以考虑基于有序唯一键的游标式分页，但前提是产品能够接受“上一页/下一页”而不是任意跳页。

-- 偏移分页：数据量大时可能扫描并丢弃大量记录
SELECT id, title, created_at

FROM orders

WHERE customer_id = 1001

ORDER BY id DESC

LIMIT 100000, 50;

-- 游标式分页：以上一页最后一条记录作为边界

SELECT id, title, created_at

FROM orders

WHERE customer_id = 1001

AND id < 987654

ORDER BY id DESC

LIMIT 50;

示例只用于解释访问模式，具体语法和执行效果需要根据数据库类型、索引结构和业务排序规则验证。游标式分页并非所有页面都适用，后台管理系统如果要求跳转到任意页，就需要在产品交互和查询成本之间做取舍。

4. 第四步：把业务重要性纳入数据库优化优先级

数据库优化不能只由数据库指标决定。一个每秒访问量不高但关系到支付、库存或核心经营决策的接口，优先级可能高于一个访问量更大的非核心查询。

我建议产品团队为接口增加三个标签：业务重要性、可接受延迟、可接受一致性。研发据此决定是否可以缓存、异步化、降级或延迟计算；测试据此设计压力模型；运维据此配置告警和发布观察窗口。

五、具体实施：先处理 SQL、索引、数据量和事务

1. SQL 优化先从减少无效工作开始

很多系统的第一批收益并不来自复杂的数据库调优，而是来自减少不必要的工作。常见问题包括重复查询同一条数据、查询后在应用层过滤大量记录、使用不必要的全字段查询、一次接口加载过多明细，以及在循环中逐条访问数据库。

如果一个看板页面有 12 个图表，每个图表都独立查询同一张事实表，数据库可能重复扫描相同数据。此时，团队应先判断哪些指标可以合并计算，哪些数据可以按时间、组织或商品维度预聚合，哪些图表可以延迟加载。

在数据分析场景中，“页面打开速度”不一定要依赖一次性完成所有查询。产品可以将核心指标优先展示，明细表和非关键图表异步加载。这样既降低瞬时数据库并发，也让用户更早获得有价值的信息。

2. 索引设计要同时考虑查询和写入

索引设计至少要回答三个问题：它服务于哪一类查询？能过滤掉多少数据？新增索引会给写入和存储带来什么代价？如果这三个问题答不上来，索引变更就不应直接在线执行。

联合索引的顺序也不能简单套用“等值条件在前、范围条件在后”的口诀。实际还要结合查询组合、字段选择性、排序要求和覆盖需求。一个适合列表查询的联合索引，可能并不适合聚合查询；一个对读取有利的覆盖索引，也可能显著增加写入成本。

我建议建立索引变更记录，至少保留以下信息：

• 关联的接口和 SQL 模板。
• 上线前后的执行计划。
• 平均扫描行数和返回行数。
• 索引大小和写入影响。
• 灰度期间的 P95、P99 和错误率。
• 出现异常时的回滚方式。

3. 大表治理通常比“再加一台数据库”更值得优先做

数据表持续膨胀后，索引维护、备份恢复、范围扫描和数据清理都会变得更昂贵。特别是订单、日志、操作记录和同步明细表，在线业务只需要最近一段时间的数据，却让历史数据长期留在同一张热表中。

大表治理可以从数据保留策略开始。产品需要明确哪些数据必须在线查询，哪些数据可以归档，哪些数据只需要按月或按季度查询。研发再根据访问模式选择分区、归档表、冷热分离或独立分析存储。

这里的关键不是“表越小越好”，而是让在线请求不要为历史数据承担不必要的扫描和索引维护成本。归档前必须完成查询改造、数据校验和恢复演练，否则看似降低了在线压力，却可能让历史查询和故障恢复变得不可控。

4. 事务边界决定了并发时的锁竞争

事务不是越大越安全。事务范围过大，会让连接被长时间占用、锁持有时间变长、回滚成本增加，并且更容易与其他请求形成环路等待。

一个典型错误是：事务开启后先查询数据库，再调用外部服务，等待外部服务返回后继续更新数据库。外部服务一旦延迟，数据库连接和锁就会被同步占用。更稳妥的方式是尽可能把远程调用移出事务，或者使用明确的状态机、消息队列和补偿机制表达业务过程。

对于批量更新，也不要默认“一次事务处理全部数据”。可以根据锁竞争、日志量、回滚成本和业务一致性要求拆成合理批次，并在批处理期间监控在线请求的 P99 和锁等待时间。

六、连接池、锁竞争与热点写入：并发问题的中间层治理

1. 连接池要按实例总量计算

很多团队只在单个应用实例上看连接池配置，却忽略了实例扩容会把连接数成倍放大。假设当前有 10 个实例，每个实例最大连接数为 30，总上限是 300；发布后扩容到 30 个实例，如果配置不变，总上限就变成 900。

因此，连接池配置应与发布策略、自动扩缩容策略和数据库容量共同管理。每次应用实例数变化，都应重新检查数据库最大连接数、活跃连接数、空闲连接数和管理连接预留。

连接池监控至少应包括：

• 活跃连接数和空闲连接数。
• 获取连接等待次数。
• 获取连接平均等待时间和最大等待时间。
• 连接持有时间分布。
• 连接泄漏或超时回收数量。
• 应用实例数量和单实例连接池上限。

2. 锁等待需要定位“谁持锁”和“谁在等”

锁等待的排查不能只看等待线程。真正需要找到的是持锁事务、事务开始时间、最后一次 SQL、锁定对象和业务请求来源。

如果一个凌晨批处理事务持有锁数分钟，白天在线请求可能会随机出现超时。此时增加数据库 CPU 或扩大连接池都无法解决问题，甚至会让更多请求排队。解决方案可能是缩小批处理范围、拆分事务、调整执行窗口或将批处理迁移到隔离节点。

死锁也不应简单理解为“数据库不稳定”。在并发写入场景下，死锁可能是多个事务以不同顺序更新资源造成的。研发需要统一资源访问顺序，并在业务允许的情况下对特定错误进行有限次数重试。重试必须有退避、幂等和上限，不能无条件重复提交。

3. 热点写入不能只靠提高数据库并发

库存扣减、余额更新、计数器递增和热门内容统计，都可能形成热点行。多个请求同时更新同一行时，数据库即使拥有足够 CPU，也会因为串行化锁竞争而无法线性扩展。

热点写入的处理方式取决于业务语义。库存扣减通常需要严格校验和幂等控制；计数器可以考虑分片计数后异步汇总；日志和行为记录可以先进入消息队列；高峰活动则可以通过限流、排队和预扣减减少瞬时写入压力。

七、缓存、读写分离和异步化：什么时候值得引入

1. 缓存应该先解决重复读取，而不是覆盖数据模型问题

缓存的第一原则是确认数据是否具有稳定的访问热点。如果同一份数据在短时间内被大量重复读取，缓存可以显著减少数据库重复执行；如果请求参数高度离散，缓存命中率低，维护缓存反而增加系统复杂度。

以经营看板为例，可以将“当前月份按区域汇总的销售额”作为缓存对象，但不一定适合缓存每个用户、每个筛选条件下的全部明细结果。后者的 Key 数量可能迅速膨胀，缓存空间、失效策略和回源压力都需要重新评估。

缓存方案应在设计阶段明确以下边界：

• 数据最长允许延迟多久。
• 更新数据库后何时刷新或删除缓存。
• 缓存失效时是否允许回源。
• 热点 Key 是否需要互斥加载或请求合并。
• 缓存不可用时系统是否可以降级。
• 缓存数据是否包含敏感信息，是否需要权限隔离。

2. 读写分离首先是数据一致性设计

读写分离的技术动作通常不难，困难在于业务能否接受复制延迟。用户刚刚提交订单，随后刷新页面却暂时看不到订单；用户刚修改权限，下一次查询仍然读取旧数据。这些问题不是数据库连接配置能够自动解决的。

可采用的策略包括：写入后短时间强制读主、关键请求携带读主标记、根据复制位点判断副本是否追上、对非关键页面接受最终一致性。具体选择取决于业务重要性，而不是简单地把所有读请求都发送到副本。

如果只读副本数量增加，却没有按照查询类型、租户、业务模块或负载情况进行路由，最终可能出现主库压力下降但某一个副本过载的情况。读写分离还必须配套复制延迟监控、节点健康检查和故障切换演练。

3. 异步化的价值是削峰和解耦，不是让慢任务消失

数据同步、报表计算、通知发送、日志落库和统计汇总等任务，如果不要求在用户请求内立即完成，可以通过消息队列或任务调度异步化。这样可以把突发流量转换为可控制的处理队列，避免在线请求与批量任务直接竞争数据库。

异步化也会引入新的工程问题：消息积压怎么办，重复消费如何处理，任务失败如何重试，数据最终一致性如何向用户解释，消费速度是否会把数据库重新压垮。比较稳妥的做法是为消费者设置并发上限、批量大小和退避机制，并把队列深度纳入容量监控。

4. 查询隔离往往比扩容更快改善用户体验

在线交易查询、经营看板、历史报表和同步任务使用同一数据库时，任何一个重型任务都可能影响其他业务。此时可以先做逻辑隔离：限制报表查询范围、设置独立连接池、控制并发、错峰执行，必要时再采用只读副本或独立分析存储。

对于九数云这类数据分析平台的使用场景，产品团队可以重点评估“实时查询”和“分析计算”的边界。并不是所有指标都必须实时从明细数据计算，很多经营指标可以按小时、天或业务事件进行预聚合。只要产品在页面上明确数据更新时间，系统就能用更低的数据库成本换取更稳定的访问体验。

八、什么时候考虑分库分表：复杂方案必须有明确门槛

1. 分库分表前先证明单库确实已经到达瓶颈

分库分表适合解决单库数据规模过大、单表持续膨胀、写入压力集中或单节点资源无法继续扩展的问题。它不适合用来解决一个还没有完成 SQL、事务和任务隔离治理的系统。

进入评估前，我会要求团队提供至少四类证据：第一，核心 SQL 已经完成执行计划和索引治理；第二，连接池和事务问题已经排除；第三，缓存、读写分离或异步化无法满足目标容量，或者存在明确的强一致限制；第四，单库资源在峰值和容量预测下确实接近上限。

如果团队无法说明“当前瓶颈是什么、拆分后哪个资源会下降、跨库查询怎么处理、如何迁移和回滚”，就不应因为行业流行而启动分库分表项目。

2. 分片键决定了未来大部分查询成本

分片键通常应尽量稳定、分布均匀，并且出现在核心查询条件中。按照租户、组织、用户或业务区域拆分，可能降低单分片数据量；但如果核心查询经常跨租户、跨区域或按时间汇总，就会产生大量跨分片请求。

分片键选择不能只看当前查询，还要看未来产品功能。今天所有查询都带租户条件，明天产品增加全平台排行，原有分片方案就可能需要跨所有分片聚合。架构评审时，产品经理必须参与，因为跨分片查询的代价最终会表现为功能限制、报表延迟或额外的数据汇总链路。

3. 分库分表的主要代价是排障和运营复杂度

单库时代，研发通常可以直接执行 SQL、查看事务和恢复数据。拆分之后，同一个业务请求可能访问多个节点，问题定位需要关联路由、分片、节点状态和跨库调用。数据迁移、扩容再平衡、备份恢复和故障切换也会变得更复杂。

4. 渐进式迁移比一次性切换更稳妥

如果确实需要分库分表，建议从非核心、可重建或可回放的数据开始演练。先验证路由规则、数据校验、双写一致性、历史数据补偿、读流量切换和回滚流程，再逐步迁移核心链路。

迁移项目必须预先定义停止条件。例如，校验差异超过阈值、复制延迟持续超过业务容忍度、核心接口 P99 恶化、错误率升高或回滚时间超过窗口，都应触发暂停，而不是继续推进。

技术负责人需要特别警惕“迁移完成”这个模糊词。数据写入新库、查询切换、旧库下线、备份确认和故障演练是不同阶段，不能因为数据已经复制完成，就认为项目已经具备生产安全性。

九、产品技术团队如何把优化纳入交付流程

1. 产品阶段：先定义流量、时效和一致性

产品需求文档中如果只有“支持高并发”，研发几乎无法据此设计数据库容量。更有用的需求描述应包括日常请求量、峰值请求量、峰值持续时间、突发倍率、核心接口、可接受延迟和错误处理方式。

对于看板和报表，还要说明数据更新时间。是要求秒级实时、分钟级刷新、小时级更新，还是允许每天汇总一次？这个选择会直接决定系统能否使用预聚合、异步计算和独立分析存储。

对于交易类功能，产品还要明确重复提交、超时重试和最终一致性的处理方式。如果这些边界没有定义，研发往往只能把所有逻辑放进同步事务，最终造成数据库连接和锁竞争。

2. 研发阶段：把数据库访问当成接口契约

研发团队应将 SQL、索引、事务和数据量纳入接口设计，而不是等到上线前再进行性能补救。每个核心接口都应该能回答：一次请求访问几次数据库、每次返回多少行、是否包含事务、是否可能触发批量操作、是否允许缓存。

建议为核心接口建立访问预算，例如单次请求最多访问几次数据库、最大返回数据量、目标 P95 和 P99、允许的连接持有时间。预算不是绝对限制，但能让代码评审从“功能能不能跑”升级到“访问成本是否可控”。

3. 测试阶段：压测模型要接近真实流量比例

只用单一接口压测，通常无法代表真实系统。线上流量往往同时包含读、写、列表、详情、批处理、登录、权限校验和后台任务。压测脚本如果只重复一个轻量查询，得到的吞吐量会明显高估。

压测至少应覆盖四种负载：

1. 正常工作日负载，观察系统稳定运行时的资源水平。
2. 业务高峰负载，观察 P95、P99 和连接池等待。
3. 短时突发负载，观察限流、排队和恢复速度。
4. 混合任务负载，观察在线请求与批处理、同步任务的相互影响。

压测前还需要准备可重复的数据集。数据量太小会让索引和缓存效果失真，数据分布过于平均也无法暴露热点问题。测试数据应尽量模拟真实的时间分布、组织分布、热门对象和长尾对象。

4. 发布阶段：灰度观察比一次性看结果更重要

数据库优化通常会改变执行计划、缓存命中、锁竞争或数据路由，开发环境的成功不等于生产环境的成功。灰度期间应同时观察业务指标和数据库指标，并预先设定回滚阈值。

例如，某索引上线后核心接口 P95 降低，但写入延迟增加 40%，这可能对交易系统不可接受；某缓存上线后数据库 CPU 降低，但数据更新时间异常，这可能对经营决策产生误导。优化必须同时满足技术和业务验收。

5. 运维阶段：监控要能回答“为什么慢”

只有“数据库 CPU 高”“接口超时”这类告警，无法直接指导处理。更有用的监控应该把业务请求、应用连接池和数据库执行关联起来。

• 业务层：接口 QPS、成功率、超时率、P50、P95、P99。
• 应用层：线程池、连接池等待、连接持有时长、请求重试。
• 数据库层：活跃连接、慢查询、锁等待、死锁、事务时长。
• 资源层：CPU、内存、磁盘 I/O、缓存命中、临时空间。
• 集群层：复制延迟、节点负载、故障切换状态、备份任务。

告警还要绑定责任人和处理手册。否则告警数量增加，只会让团队产生告警疲劳。对于核心指标，应记录最近一次变更、当前版本、相关 SQL 和回滚方法，减少故障发生后的临时排查时间。

十、不同情况下的行动建议：不要用同一套方案解决所有问题

1. 如果数据库 CPU 长时间较高

先确认 CPU 消耗来自 SQL 执行、排序聚合、锁竞争还是连接调度。找出累计执行时间最高的 SQL，查看扫描量和执行计划，再判断是重写、索引、预聚合、缓存还是任务隔离。

如果 CPU 高但 P99 和错误率仍稳定，可以先做容量趋势预测；如果 CPU 高并伴随长尾恶化，应立即限制非核心任务、降低重型查询并发，避免在资源耗尽后被动故障。

2. 如果数据库 CPU 不高但接口很慢

优先检查连接池等待、锁等待、磁盘 I/O、网络延迟和应用线程池。CPU 不高并不代表系统有充足处理能力，数据库可能正在等待磁盘、锁或外部资源。

如果锁等待占比高，应定位持锁事务；如果连接池等待高，应检查连接泄漏、事务范围和实例总连接数；如果磁盘 I/O 高，应减少扫描和临时数据，评估内存、存储性能和数据归档。

3. 如果读请求多、数据变化不频繁

可以优先评估缓存、只读副本和预聚合。缓存适合明确热点的固定结果，读写分离适合读请求比例高且能够接受复制延迟的系统，预聚合适合计算规则稳定、重复查询明显的分析场景。

不要三种方案同时上线。一次只改变一个主要变量，才能判断性能收益来自哪里，也便于出现一致性或故障问题时回滚。

4. 如果写入请求多、热点对象明显

重点放在事务范围、批次大小、热点行、幂等、队列削峰和限流上。读写分离对主库写入压力帮助有限，缓存也不能直接解决高并发写冲突。

对于计数、日志和统计类写入，可以采用异步汇总；对于库存、余额和状态变更，必须优先保证业务正确性，再讨论吞吐量。任何“先写缓存、后异步落库”的方案，都需要明确丢失、重复和补偿处理。

5. 如果报表和在线交易相互影响

优先做查询隔离和数据链路隔离。可以限制报表查询时间范围，使用独立连接池和只读副本，将重型计算迁移到分析存储，或者将指标改为定时预计算。

如果产品要求所有报表都实时、所有明细都可跨维度自由查询，那么数据库承受的压力会显著增加。此时需要产品参与取舍：是牺牲实时性换稳定性，还是投入独立分析架构换查询自由度。

6. 如果数据量增长快但当前流量不高

不要因为未来可能增长就立即分库分表。先建立容量趋势，包括数据增长速度、索引增长、备份窗口、恢复时间和单表访问变化。提前做好归档、分区和访问规范，通常比过早引入复杂分片更稳妥。

但如果迁移窗口、备份恢复和单表维护已经开始超过业务容忍度，就应提前进行分片设计和迁移演练。架构改造的最佳时机通常不是系统已经故障之后，而是容量趋势已经清楚、但仍有足够回滚空间的时候。

十一、如何做优化前后对比：用可验收指标证明结果

1. 性能基线至少要保留五类数据

第一类是业务流量，包括 QPS、TPS、读写比例和峰值持续时间。第二类是延迟，包括平均值、P50、P95 和 P99。第三类是稳定性，包括错误率、超时率、重试次数和熔断次数。

第四类是数据库资源，包括 CPU、内存、磁盘 I/O、活跃连接和临时空间。第五类是数据库内部行为，包括慢查询、锁等待、死锁、长事务、缓存命中和复制延迟。

只记录“优化前 QPS”和“优化后 QPS”是不够的。因为优化后可能通过增加机器、降低一致性或减少返回数据量获得吞吐量增长，团队必须同时知道为此付出了什么成本。

2. 使用统一压测模型，而不是各测各的

优化前后的对比必须保持数据量、请求比例、并发模型、缓存状态和压测时长一致。一次使用热缓存、一次使用冷缓存，或者一次只测轻量接口、一次混合重型接口，都会导致结论失真。

建议至少进行三轮测试：冷启动测试、稳定负载测试和突发流量测试。冷启动用于观察缓存和连接建立成本，稳定负载用于确认持续容量，突发测试用于观察队列、限流和系统恢复能力。

3. 设置“收益指标”和“代价指标”

每项优化都应同时设定收益指标和代价指标。例如，增加索引的收益指标是查询 P99 和扫描行数下降，代价指标是写入延迟、存储空间和索引维护时间；引入缓存的收益指标是数据库读取量下降，代价指标是一致性延迟、缓存空间和回源峰值。

4. 用预算而不是口号管理性能

“系统要快”无法执行，“核心接口在 500 请求/秒下 P99 不超过 800 毫秒，错误率低于 0.1%，数据库 CPU 不连续超过 75%”就可以被测试和运维验证。

性能预算还可以分解到接口、SQL 和数据访问层。例如一个接口总预算为 800 毫秒，网关和应用处理占 150 毫秒，数据库可用预算就只有 650 毫秒。如果接口内部串行执行 8 次查询，那么每次查询的平均预算并不是简单的 81 毫秒，还要考虑并行、连接获取和结果处理的额外成本。

十二、不同方案的取舍：性能、稳定性、成本和一致性不能同时最大化

1. 低成本方案与高扩展方案的区别

SQL、索引、分页、事务治理和数据归档，通常属于低成本、低风险方案，适合大多数团队优先实施。缓存、读写分离和异步化，属于中等复杂度方案，能够扩大容量，但会引入一致性、运维和故障处理问题。

分库分表和独立分析架构，属于高成本、高扩展方案。它们适合数据规模和业务复杂度已经达到一定阶段的团队，但需要持续投入监控、迁移、容量规划和故障演练。

2. 实时性与稳定性的取舍

所有数据都实时计算，能够提供最新结果，但数据库成本和高峰风险更高；采用预聚合或异步计算，可以显著降低在线压力，但页面需要显示数据更新时间，并且产品要接受短暂延迟。

对于经营看板，用户往往更关心趋势、排名和异常，而不是每一秒的数据变化。产品可以根据指标类型划分刷新频率：核心经营指标按分钟更新，历史趋势按小时更新，明细数据按需查询。这样的设计通常比强行追求全量实时更符合成本和体验的平衡。

3. 一致性与可用性的取舍

强一致事务可以降低业务歧义，但会增加锁、连接和等待成本；最终一致性可以提升吞吐和可用性，但需要状态展示、补偿和对账机制。

这不是数据库团队单独能够决定的技术问题。产品需要明确用户是否能接受“处理中”“数据将在几分钟后更新”等状态，财务、库存和权限等关键场景则需要更加严格的一致性约束。

4. 性能与运维复杂度的取舍

缓存、消息队列、只读副本和分片节点越多，系统的可扩展性可能越强，但故障链路也越长。团队必须评估是否拥有相应的监控、排障、备份、恢复和演练能力。

如果一个团队只有少量研发和运维人员，且业务规模尚未达到明显瓶颈，那么先把 SQL、索引、事务、归档、慢查询和容量监控做好，通常比引入多个中间件更实际。技术方案的先进程度，不能脱离团队长期维护能力。

十三、给产品技术团队的一套可执行实施路线图

1. 第一周：只做测量，不急着改架构

第一周的目标不是让系统马上变快，而是建立可重复的性能基线。团队应选出 5 至 10 个核心接口，记录高峰流量、P95、P99、错误率、数据库资源、连接池等待和主要 SQL。

同时梳理任务清单，标记哪些是在线请求、哪些是批处理、哪些是报表、哪些是同步任务。很多数据库问题不是某条 SQL 单独造成的，而是多个任务在同一时间段叠加。

• 确认数据库类型、版本、节点规格和存储配置。
• 确认应用实例数和单实例连接池上限。
• 收集慢查询、锁等待、死锁和长事务数据。
• 记录数据库表规模、索引规模和近几个月增长趋势。
• 建立优化前的压测脚本和数据快照。

2. 第二至第三周：先处理最高性价比问题

这一阶段优先处理累计执行时间最高的 SQL、重复查询、深分页、无效字段、长事务和连接释放问题。每一次修改都要保留执行计划和指标对比，不要同时修改太多变量。

如果一个接口同时存在 SQL 慢和连接池等待，先确认两者的因果关系。单条 SQL 变快后，连接持有时间下降，连接池等待可能自然改善；如果连接泄漏存在，则必须先修复连接生命周期，否则继续优化 SQL 只是在降低症状。

3. 第四至第六周：引入访问隔离和异步处理

基础问题处理后，再根据观察结果决定是否引入缓存、预聚合、只读副本或异步队列。每项方案都应明确适用接口、数据更新策略、故障降级方式和回滚路径。

对于分析场景，可以先从一个高频看板或一个固定指标集开始试点，而不是一次性缓存所有查询。对于批处理，可以先限制并发和拆分事务，观察在线请求是否恢复，再决定是否迁移到独立分析链路。

4. 容量达到门槛后：启动架构扩展项目

当单库 CPU、存储、连接、备份恢复或数据规模出现持续性瓶颈，并且基础治理无法满足业务目标时，再启动分库分表、独立分析存储或更大规模的数据架构改造。

架构项目必须包含容量模型、迁移方案、数据校验、灰度计划、回滚策略、监控改造和人员排班。没有这些配套内容的分库分表，只是一次高风险的数据迁移。

5. 每次版本发布都保留性能回归环节

数据库性能不是一次性项目。新增字段、索引、筛选条件、报表维度和批处理任务，都可能改变执行计划和资源消耗。核心接口应在版本发布前进行最小化性能回归，至少验证高频 SQL、关键写入和高峰并发。

回归测试不必每次都做大型全链路压测，但要保证关键指标有历史对照。如果某个版本让扫描行数、连接持有时间或 P99 明显上升，团队应在上线前找到原因，而不是等用户反馈页面变慢。

十四、最终检查清单：下一步不要从分库分表开始

1. 产品负责人需要确认

• 哪些接口属于核心业务链路。
• 峰值流量、突发流量和高峰持续时间是多少。
• 看板、报表和查询数据允许延迟多久。
• 哪些功能可以降级、延迟或异步处理。
• 哪些数据必须强一致，哪些数据可以最终一致。
• 性能问题对用户、收入、运营和决策的具体影响是什么。

2. 研发负责人需要确认

• 核心接口是否有完整链路耗时。
• 高频 SQL 是否有执行计划和累计执行时间统计。
• 连接池是否存在等待、泄漏或配置失衡。
• 事务中是否包含远程调用或不必要的复杂计算。
• 批处理是否与在线请求争抢同一资源。
• 缓存、消息和读写分离是否有一致性与回滚方案。

3. 测试和运维负责人需要确认

• 压测数据量和流量比例是否接近生产。
• 是否同时观察 P95、P99、错误率和资源指标。
• 是否覆盖正常、高峰、突发和混合任务负载。
• 慢查询、锁等待、长事务和复制延迟是否有告警。
• 数据库变更是否经过灰度和回滚演练。
• 备份恢复时间是否满足业务要求。

4. 本周就可以执行的三个动作

第一，选出最重要的五个接口，补齐 QPS、P95、P99、错误率和数据库耗时。没有这组数据，团队无法判断问题是否真实改善。

第二，按“执行次数 × 平均耗时”排序 SQL，而不是只挑最慢的一条。累计资源消耗通常比单次耗时更能决定数据库整体压力。

第三，检查应用实例总数、连接池上限和数据库最大连接数。很多所谓的数据库并发问题，根源是扩容后连接数被成倍放大，或者事务长期占用连接。

我的最终判断是：数据库并发优化的核心，不是寻找一个万能组件，也不是把所有参数调到最大，而是持续减少每个请求的无效工作、缩短资源占用时间、隔离不同类型的访问，并用可复现的指标验证每一次变化。

对于产品技术团队，最稳妥的路径通常是：先测量，再治理 SQL 和索引；再处理连接、事务、锁和热点；随后根据访问模式引入缓存、预聚合、读写分离或异步化；最后在单库出现明确容量瓶颈时，评估分库分表和独立分析架构。

下一步不妨把今天的数据库监控、接口链路和慢查询记录放在同一张表里，挑出一个高频核心接口做小范围优化。只改一个变量，保留优化前后数据，经过压测、灰度和高峰观察后再扩大范围。稳步提升并发能力的关键，不是一次完成大改造，而是让每次改动都能被解释、被验证、被回滚。

免费注册

咨询方案

扫码咨询方案