数据库热点行优化，先证明谁在等谁，再缩短临界区或改变写入模型

不同热点写入，需要不同的正确性边界

适用边界：热点行与慢查询、连接不足不是同一个问题

热点行是许多并发事务需要修改或锁定同一个逻辑资源，后来的事务即使 SQL 很短，也只能等待先前持有者提交或回滚。它常见于全局计数、单租户额度、同一账户余额、任务游标和唯一状态行；普通查询扫描慢、磁盘饱和或连接池排队，需要先按各自证据处理。

同一接口变慢不代表一定存在行锁。先把应用排队、连接获取、SQL 执行、锁等待、提交和响应拆开，查看等待是否随特定业务键集中。PostgreSQL 官方文档说明，行级锁不会阻止普通读取，但会阻塞对同一行冲突的写入或加锁操作，并在事务结束时释放；MySQL InnoDB 的具体记录锁、间隙锁和锁定读行为还取决于索引、搜索条件与隔离级别。

若写入均匀分散却仍出现吞吐上限，应继续检查索引维护、日志刷盘、复制确认、缓冲争用或存储能力。若热点来自一个真实且不可分割的业务事实，例如严格账户余额，就不能仅凭技术目标拆成多个互不约束的数值；优化目标应是减少不必要持锁时间、控制等待和重试，并在明确一致性边界内提高完成量。

• 记录数据库产品、版本、隔离级别、事务框架和自动重试配置。
• 按业务键比较请求量、锁等待、事务时长、失败与提交量。
• 写清热点字段代表的业务事实，以及哪些不变量绝不能拆开。

先还原阻塞链：找出持锁者、等待者与临界区

诊断要回答“谁持有什么锁、从何时开始、谁被阻塞、事务里还做了什么”，而不是只保存一条慢 SQL。将数据库会话、锁视图、应用追踪和业务单据按同一时间线关联，区分头部阻塞者与其后排队请求。

PostgreSQL 可结合 pg_locks、pg_stat_activity 及阻塞关系函数查看未授予锁、事务开始时间、等待事件和阻塞会话；官方文档明确 pg_locks 可用于定位未授予锁较多的关系并评估争用随流量的变化。MySQL 可通过 Performance Schema 的事务与数据锁等待信息、死锁记录和语句上下文定位双方。采集需要受权限、频率和敏感字段控制，避免为了诊断持续运行高成本全量查询。

重点寻找事务取得热点锁后进行的网络请求、文件操作、模板渲染、循环处理、人工等待或大范围查询。应用显示请求已超时，不代表数据库事务已经取消；若后台仍继续并最终提交，上游自动重试会把一份业务意图变成更多等待者。阻塞树中大量等待 SQL 可能只是受害者，真正要修改的是最前方持锁事务及其上游调用路径。

• 为样本保存 traceId、业务键、连接会话、事务起止与最终提交结果。
• 分别统计锁获取等待和获得锁后的持有时间。
• 确认应用超时、数据库取消和事务回滚能够对应，不留下后台孤儿工作。

能原子完成的规则，优先改成受约束的单条更新

对“仅当状态为待处理才完成”“仅当余量足够才扣减”等单行规则，可将前置读取和写入合并为带条件的更新，由数据库在同一操作中判断，并以受影响行数或返回值区分成功、条件不满足和系统失败。

先读取值、在应用计算、再无条件写回，会扩大事务往返和丢失更新风险。单条条件更新仍会争用同一行，但减少了一次读取和应用停顿，也让失败语义更清楚。版本列的乐观并发适合冲突较少且重试成本可控的状态修改；在真正热点上，大量版本冲突与立即重试可能比短暂排队更昂贵，因此必须按净完成量选择，而不是默认“无锁”就更快。

多行或多表不变量不能被随意压成几条互不关联的更新。必须更新多个资源时，所有入口采用稳定顺序，事务只包含必要读写，并对死锁或序列化失败执行有上限、带抖动且保持业务幂等的整笔事务重试。PostgreSQL 与 MySQL 都可能在行级操作中发生死锁；数据库回滚一个参与者是恢复机制，不代表业务已经完成。

• 将允许前态、边界条件和唯一业务标识固化为更新条件或数据库约束。
• 把条件不满足、锁超时、死锁、序列化失败和结果未知映射为不同处理路径。
• 重试整笔事务并复用原业务意图，不只重放最后一条 SQL。

缩短临界区：锁住之前准备，提交之后调用外部系统

热点资源一旦被锁定，事务里的每个额外步骤都会转化为其他请求的等待。先完成不依赖锁的校验、数据准备和纯计算，再开启短事务读取必要状态、写入结果与待发布意图并提交；短信、支付、对象存储和 AI 工具调用放到提交后的可恢复流程。

移出事务不等于忽略失败。跨系统动作使用稳定 operationId 或事件 ID，保存待执行、已发送、结果未知、成功和终止失败状态，由幂等执行器查询与补偿。用户端展示“已受理”还是“已完成”必须对应真实提交点。对小程序、APP 弱网补发和 AI 智能体重复工具请求，服务端按同一业务意图复用结果，不能让每次重试都再次争抢热点行。

锁等待和语句超时应短于调用方总截止时间，并为数据库取消、连接归还和上游响应预留预算。超时不是吞吐优化：设置过短只会制造更多回滚和补发。若允许排队，应明确最大等待、队列长度、过载拒绝与稍后查询；若不允许等待，应快速返回可解释的冲突结果，而不是让连接长期占用。

• 事务内不执行不可控网络调用、长循环或与热点事实无关的查询。
• 提交后动作具有持久状态、稳定幂等标识和结果查询入口。
• 端到端超时预算覆盖排队、锁等待、执行、提交与响应，不产生无界重试。

确需拆热点时，用业务语义选择分桶、流水或按键排队

当单个提交点已经成为经证实的容量上限，且业务允许改变读写模型，可在受控范围内拆分写入。可交换、可合并的统计量可按租户、时间窗或固定桶写入，再异步聚合；需要审计的余额变化可追加不可变流水并维护受约束余额；同一资源必须串行的后台动作可按业务键路由到有限分区。

分桶数量不能只追求写入均匀。读取必须说明是强一致总数、允许延迟的展示值还是近似指标；扩桶与缩桶需要版本、路由和历史数据方案。严格全局上限若仍要在每次写入时检查一个总计数器，热点并未消失；若把额度预分配给多个桶，则要定义分配、耗尽、回收、故障占用和总额对账，避免局部都合法但全局超限。

领取型工作队列可在数据库支持且语义匹配时使用跳过已锁记录的能力，让多个执行器处理不同任务；这类读取提供的是队列式并行，不适合要求一致视图的一般业务查询。领取记录还需租约或状态版本、执行幂等、过期接管和陈旧执行者拒绝。无论采用缓存、消息队列还是数据库分片，都不能仅把同一热点键复制到另一个组件后宣称问题解决。

• 为新模型定义权威事实、读一致性、聚合延迟、路由版本和对账公式。
• 以单一热点键验证写入是否真正分散，而不是只看全库平均值。
• 准备停写、排空、校准和回退方案，避免双写期间两个权威来源。

灰度与验收：同时证明等待下降和业务结果不变

先在可复现环境构造与生产接近的热点比例、事务组合和数据规模，保存优化前阻塞链与业务对账；再依次上线事务缩短、条件更新、等待控制和必要的数据模型变更。每一步只扩大一个低风险业务范围，并保留旧路径拒绝新写、暂停异步执行和校准数据的开关。

性能验收同时记录到达量、有效提交量、P95/P99 端到端延迟、锁等待分布、热点行持有时间、死锁或序列化失败、回滚、应用重试、连接占用和队列年龄。使用均匀随机键会隐藏同一行串行上限；只看数据库 QPS 可能把失败与重复也算作能力。压力结束后还要观察积压清空和资源归还，确认恢复阶段没有重试风暴。

正确性验收覆盖同一业务意图并发提交、持锁者进程退出、提交回执丢失、数据库切换、死锁回滚、异步执行器重复和聚合延迟。按业务键对账请求、事务结果、流水、聚合值和外部副作用；任何结果未知都进入可查询与人工处置状态。若吞吐提升依赖放宽一致性，必须由业务明确接受可见延迟和纠正方式，不能把错误窗口隐藏在性能报告里。

• 压测包含单热点、少数热点与真实长尾分布，并固定资源和成功口径。
• 锁等待下降时，有效业务提交量同步提高且重试放大受控。
• 余额、额度、计数、状态与外部副作用均能按稳定业务键完成对账。

需求讨论中的问题

关联服务与实施资料

下面的页面可继续核对相关技术边界、业务接入方式与项目交付条件。

• 慢 SQL 与索引优化指南：先检查执行计划、扫描范围和索引成本，避免误把慢执行当成锁争用。
• 秒杀库存一致性指南：继续处理严格库存扣减、预约释放、热点预扣和最终对账。
• 连接池与超时预算指南：把数据库锁等待与连接排队、线程占用和端到端截止时间放在一起治理。
• 旧系统长事务拆分指南：当热点事务还包含外部调用或跨资源步骤时，继续设计提交边界与补偿。
• AI Agent 智能体开发：为工具请求建立稳定意图、持久状态、取消与结果复用，减少重复争抢。
• 小程序与 APP 一体化开发：统一弱网重试、重复提交、处理中状态与服务端幂等结果。
• 软件项目启动资料包：整理热点业务键、数据不变量、负载样本、故障场景和验收责任。