阅读指南
本文适合正在规划商城、零售中台、会员系统、订货平台或营销活动系统的产品经理、项目负责人和业务架构师。文中涉及的访问量、订单量、响应时间和成本均为用于方法演示的示例假设，不代表 E数通或任何客户的真实运营数据。阅读时可以把示例数字替换成自己的埋点、压测和生产监控结果。
01 / 先讲结论
我在电商项目管理中最看重的，不是数据库选了哪一种产品，而是团队能否回答四个问题：第一，活动开始后的前十分钟，哪些业务动作最容易形成并发尖峰；第二，哪些数据必须实时正确，哪些数据允许几秒或几分钟延迟；第三，系统变慢时，用户还能完成哪一条最小交易链路；第四，系统恢复后，如何证明没有多扣库存、重复发券和订单状态错乱。
如果产品需求只写“支持十万用户同时访问”，研发无法据此设计，因为浏览、搜索、提交订单、支付回调和运营报表的请求成本完全不同。更可执行的表达应该是：“活动峰值预计每秒产生示例性的 800 次商品详情读取、120 次库存查询、40 次订单提交；商品详情 P95 小于 300 毫秒，订单提交 P95 小于 800 毫秒，库存扣减不允许超卖，支付回调允许进入可重试队列。”这类语言才可以变成索引、事务、缓存、队列和监控指标。
02 / 背景和真实场景
电商系统的压力很少平均出现。普通工作日可能是连续而平缓的流量，活动日却会在短信、直播、站内弹窗和社群通知的共同作用下，形成明显的时间聚集。用户打开商品详情、刷新优惠券、查询库存、提交订单，常常集中在同一到两个时间窗口。产品经理如果只看月订单数，就会低估峰值。
另一个原因是请求之间存在放大关系。一个商品详情页可能同时读取商品主表、规格表、图片、价格、促销规则、会员权益和库存摘要；一个订单提交动作可能写入订单、订单明细、支付单、优惠使用记录、库存流水，并发送多个异步消息。用户看到的是一个按钮，数据库承担的是一组有顺序和一致性要求的操作。
还有一种常见情况：系统在功能验收时看起来没问题，但报表、导出、运营筛选和临时 SQL 与交易请求共用数据库。活动时运营人员为了查看实时销售额频繁刷新大查询，最终把读写链路一起拖慢。产品经理因此需要把“业务查询”和“交易写入”当作两类不同的产品能力来设计。
压力来源地图
| 压力来源 | 典型表现 | 产品经理要追问 |
|---|---|---|
| 突发读流量 | 商品页、搜索页大量刷新 | 哪些结果可缓存？缓存失效是否会同时回源？ |
| 集中写入 | 订单、库存、优惠同时写表 | 写入顺序是什么？重复提交如何处理？ |
| 长事务 | 锁等待、连接池耗尽 | 事务是否包含外部接口或复杂查询？ |
| 后台任务 | 报表、对账、导出抢资源 | 是否隔离资源？是否支持限速和暂停？ |
用户浏览商品，缓存命中，价格和库存摘要在约定时效内返回；提交订单后，库存锁定成功，订单进入待支付。
推荐服务超时，页面仍展示商品核心信息；优惠计算稍慢时，保留订单草稿或明确提示，不让用户重复点击。
库存服务不可用时停止接收高风险下单；支付回调重复到达时以幂等键识别，进入可追踪的补偿流程。
03 / 常见误区
日均 10 万单并不等于每秒 1.16 单。订单可能集中在几次活动，或者集中在某个整点。更重要的是，一单不只对应一次数据库写入。产品经理应把订单拆成创建、锁库存、优惠核算、支付确认、发货、售后等事件，并估算每一类读写次数。
用户端订单列表通常需要较新的状态，但运营看板的趋势统计不一定要求毫秒级实时。若所有页面都直接扫交易表，系统会把“可延迟的观察需求”转化成“实时的交易压力”。我会为报表定义刷新周期、数据范围和最大返回行数，并优先使用汇总表或离线结果。
索引能减少某些查询扫描，但会增加写入成本、占用存储，并可能在低选择性字段上收益有限。订单状态、租户编号、创建时间等字段应结合真实查询条件设计联合索引，不能因为“经常查”就给每一列都建索引。
缓存可以减轻读压力，却会带来失效、更新、穿透、击穿和数据新鲜度问题。商品描述和图片适合较长缓存；可售库存、优惠资格和支付状态则必须明确一致性策略。最危险的不是缓存旧商品名称，而是缓存了错误的可售数量并继续允许下单。
拆分会增加路由、事务、跨分片查询、数据迁移和运维复杂度。若单库通过正确索引、归档、读写隔离和连接池治理已经满足目标，过早拆分可能让团队把精力花在基础设施上，而不是解决真实瓶颈。
首页打开并不代表下单链路可用。压测应覆盖搜索、详情、优惠、库存、订单提交、支付回调和后台任务，并且记录 P50、P95、P99、错误率、数据库锁等待、慢查询、连接池使用率及消息积压。
04 / 专业判断逻辑
不要从“页面”开始，而要从动作开始：读取商品、计算优惠、冻结库存、创建订单、确认支付、取消订单。
区分读流量、写流量、定时任务、异步消息和人工查询，并记录峰值时间、持续时间与增长假设。
把数据分成强一致、最终一致和可接受延迟三类，分别确定事务、缓存和补偿方式。
说明数据何时创建、更新、归档、删除和审计，避免历史订单无限增长影响在线查询。
为超时、重复请求、部分成功、消息重试、回滚失败和人工介入预留状态与操作入口。
明确目标用户体验、P95、错误率、库存准确率、消息积压上限和恢复时间，避免“感觉还行”。
可执行指标
| 等级 | 示例 | 适合的设计 |
|---|---|---|
| 强一致 | 库存扣减、支付状态、退款金额 | 事务、幂等、唯一约束、明确锁策略 |
| 最终一致 | 会员积分展示、订单列表摘要、物流轨迹 | 事件消息、重试、对账和状态机 |
| 可延迟 | 趋势报表、推荐排序、热销榜单 | 缓存、汇总表、异步计算、定时刷新 |
产品文档中最好写成“允许延迟不超过 10 秒”或“支付成功后 30 秒内更新”，而不是只写“实时”。
我会特别警惕把调用支付平台、发送短信、请求营销服务等外部动作放进数据库事务。外部接口的响应时间不可控，放进事务会延长锁持有时间；但如果完全不管顺序，又可能出现订单已创建、优惠已扣除而库存没有锁定的半成功状态。
更稳妥的做法通常是：在本地事务中完成必要的数据变更，并记录可靠的业务事件；事务提交后由消息消费者调用外部服务；消费者使用业务幂等键，失败可重试，超过次数后进入人工可见的补偿队列。具体方案仍要根据支付、库存和财务规则评审。
05 / E数通示例项目
下面的“E数通电商项目”是为了说明方法而构造的示例，不是对 E数通真实客户、真实产品指标或线上架构的描述。假设一个企业正在使用 E数通相关能力规划多渠道订货系统，预计在一次促销活动中有 30 分钟集中流量。产品团队先提出“支持 20 万用户访问”，我会要求把它改写为以下可测量场景。
| 业务动作 | 示例峰值 | 目标 | 主要风险 |
|---|---|---|---|
| 商品详情读取 | 800 req/s | P95 ≤ 300ms | 缓存回源、关联查询 |
| 库存可售查询 | 120 req/s | P95 ≤ 250ms | 库存口径不一致 |
| 订单提交 | 40 req/s | P95 ≤ 800ms | 重复提交、锁等待 |
| 支付回调 | 25 req/s | 成功率 ≥ 99.9% | 重复通知、消息积压 |
| 运营报表 | 5 req/s | 10秒内返回 | 扫描交易明细 |
这张表立刻暴露出一个事实：详情读取约占主要访问量，但订单提交虽然次数少，却承担库存和资金风险。我们不能只按请求数量排优先级，而应按“资源压力 × 失败代价 × 恢复难度”综合判断。
示例观察
图表数据为方法演示用的假设值，展示不同业务动作的峰值请求量差异。
产品经理不必替研发写出所有字段，但应该参与关键实体的边界确认。以订单为例，我会要求至少区分订单主表、订单明细、支付单、库存流水、优惠使用记录和状态变更记录。这样做不是为了增加表数量，而是让每一种变化都有独立的事实依据。
订单主表适合保存用户、金额、当前状态和创建时间等高频主信息；订单明细保存购买快照，避免商品名称、价格后来变化影响历史订单；库存流水记录每次锁定、扣减、释放和调整的来源；状态变更记录则帮助排查“谁在什么时间把订单从待支付改成已取消”。
我会反对把所有字段都塞进一张“大宽表”，也会反对把每个小属性都拆成难以查询的键值对。建模的目标是让核心交易可验证、常用查询可优化、历史事实可追溯。
列出商品、规格、库存、订单、支付和售后之间的关系，定义每个状态的进入条件和退出条件。
从列表筛选、详情查询和后台检索出发，查看执行计划，避免只凭字段名称创建索引。
同时压测读写链路，并制造缓存失效、数据库慢、消息延迟和重复回调等异常。
把历史数据分层，持续观察慢查询和容量增长，根据真实使用量调整模型与阈值。
06 / 数据库设计管理方法
技术主键用于关联和存储效率，业务订单号用于展示、客服和对账，两者通常不应混为一谈。业务编号是否需要连续、是否允许按租户隔离、是否需要隐藏创建顺序，都应该在需求中明确。不要为了“看起来简单”而把手机号、商品编码等会变化的业务字段当成主键。
金额需要明确币种、精度和舍入规则，避免浮点误差；数量需要明确计量单位和小数位；时间需要统一时区和展示规则。一个订单的原价、优惠、应付、实付不能只保留一个最终金额，否则售后和财务无法解释变化过程。
订单状态应尽量按照状态机转移，而不是任何接口都能直接更新 status 字段。例如待支付可以转已支付、已取消或关闭，但已发货不能直接回到待支付。状态机不仅是技术实现，也是产品规则和客服培训的共同依据。
软删除便于审计，但会让所有查询都需要附带过滤条件，长期积累后也会增大表体积。产品经理应区分“用户不可见”“业务不可用”和“物理删除”，并明确恢复、合规保留、归档和数据脱敏要求。
数据库表不是报表。若一个运营页面需要跨越数年订单进行多条件组合统计，应评估汇总表、搜索引擎、数仓或导出任务，而不是要求交易数据库一次性完成所有工作。查询条件、排序方式和分页策略应在原型评审时就出现。
支付回调、订单提交、优惠领取和库存扣减都可能被客户端或消息系统重复触发。幂等键应有明确的生成方、有效期、唯一约束和结果返回规则。只在代码中“先查再写”不一定安全，并发下仍可能产生重复记录。
对于价格、库存、订单状态和优惠资格等关键数据，至少要能回答“发生了什么、何时发生、由谁触发、关联哪次请求”。审计记录不等于把所有日志永久塞进业务表，而是建立可检索、可留存、可脱敏的事实链。
设计完成度
以下是一个项目评审模板中的示例比例，不代表真实项目完成情况。
07 / 高峰性能治理
活动配置要有冻结时间，临近开始不应随意修改核心规则。产品、研发、运维、客服和业务负责人要共同确认库存口径、优惠范围、活动开关、限购规则、降级页面和回滚条件。压测数据需要使用接近真实的数据分布，尤其要覆盖热门商品造成的热点。
高峰期间优先保护商品展示、库存判断、下单和支付确认，推荐、评论、排行榜和复杂报表可以降低刷新频率或暂时关闭。限流不是简单拒绝所有请求，而是根据用户身份、接口风险和活动规则决定排队、返回稍后重试或展示替代信息。
活动结束不能只看销售额。需要对账订单数、支付单数、库存流水、优惠使用量、退款和异常订单；检查消息是否全部消费；检查是否存在重复扣减、已支付未发货、库存负数、状态卡住等问题。复盘结果应回写到下一次需求模板。
| 组件 | 关注重点 | 产品侧验收 |
|---|---|---|
| 缓存 | 过期、穿透、击穿、更新 | 明确可接受延迟和失效后的降级 |
| 消息队列 | 积压、重复、乱序、重试 | 定义幂等键、最大延迟和死信处理 |
| 读写分离 | 复制延迟、读到旧值 | 区分强一致读取与普通读取 |
| 分库分表 | 路由、跨片查询、扩容 | 评估迁移窗口和运营查询影响 |
| 搜索服务 | 索引延迟、数据丢失 | 说明搜索结果不是交易事实源 |
我要求压测报告至少回答五件事。第一，使用了什么数据规模，热门商品和长尾商品的比例怎样；第二，各类请求的流量配比是什么；第三，响应时间分布如何，是否存在少量请求极慢但平均值掩盖了问题；第四，瓶颈出现在应用、数据库、缓存、网络还是下游接口；第五，压力停止后系统是否能自动恢复。
例如，平均响应时间 180 毫秒并不一定好。如果 P99 达到 8 秒，部分用户会连续点击，重试反而进一步放大压力。相反，某个可延迟的推荐接口 P95 为 900 毫秒，若它已从核心链路隔离并允许降级，风险可能低于订单接口 500 毫秒但频繁锁等待的情况。
图表数据为示例假设值，单位为毫秒；实际阈值应按业务体验和技术基线共同确定。
08 / 不同情况下的取舍
优先保持模型清晰、部署简单和可观测。单体应用、单库加合理索引、规范事务和后台任务隔离，可能比过早引入多套中间件更适合。产品经理应把预算用在数据口径、自动化测试和监控上。
重点是缓存策略、热点识别、静态资源分发、预热和回源保护。商品详情和营销内容可以缓存，但库存、价格和资格判断必须有明确的实时边界。
重点是数据库锁策略、扣减顺序、唯一约束、排队和失败补偿。宁可让少量用户稍后重试，也不要用不可靠的并发写入换取表面上的“全部成功”。
重点是归档、分层、汇总和查询隔离。交易数据库保留在线必要数据，历史分析转移到更合适的存储或计算链路中。
| 选择 | 收益 | 代价 | 适用条件 |
|---|---|---|---|
| 增加索引 | 降低特定查询扫描 | 写入变慢、占空间 | 查询条件稳定且有执行计划证据 |
| 增加缓存 | 降低读库压力 | 一致性与失效复杂 | 数据允许明确延迟 |
| 异步化 | 缩短用户等待 | 最终一致、需补偿 | 非核心结果可延迟 |
| 读写分离 | 扩展读能力 | 复制延迟、路由复杂 | 读请求占比高且能接受延迟 |
| 分库分表 | 突破单库容量边界 | 跨片事务和查询困难 | 已有明确容量瓶颈和治理能力 |
行动清单
整理活动日历、渠道、用户动作、商品热点和订单状态，统一 QPS、TPS、并发用户的定义。
确认实体、状态机、金额、库存、幂等、审计、归档和后台查询边界，形成评审记录。
构造接近真实的数据分布，覆盖正常、慢、失败三类路径，提前验证开关、限流和补偿。
检查压测报告、监控、告警、回滚、值班安排和对账方案，不以“代码合并”代替上线准入。
09 / 热门问答 FAQ
我不认为产品经理必须亲自编写建表 SQL，但我需要理解实体关系、事务边界、索引影响、数据生命周期和一致性等级。比如库存扣减不能只写“调用库存接口”，而要说明扣减时机、重复请求、扣减失败、取消释放以及超卖如何核对。只有这样，数据库方案才能真正服务于业务规则，而不是等开发完成后再被动验收。
我会同时看订单量、峰值 QPS、写入 TPS、请求持续时间和业务动作配比，不能只看其中一个数字。日订单量适合估算存储增长，峰值 QPS适合估算读压力，订单提交和库存写入则要单独测算。一个日均订单不高但集中在十分钟内完成的活动，可能比全天均匀分布的更容易触发锁等待和连接池耗尽。
可以缓存不等于可以用同一种缓存策略。商品名称、图片和描述通常能接受较长时间的缓存；库存摘要要规定允许的展示延迟，不能用旧值绕过最终扣减；支付状态则要避免缓存导致用户误以为支付失败或重复付款。我会把每种数据的更新频率、最大延迟、失效方式和回源保护写进产品与技术方案。
用户只点击一次，并不能保证服务端只收到一次请求。网络重试、浏览器重复提交、网关重试、消息重复投递和支付平台重复通知都可能形成多次调用。订单创建、优惠领取和支付回调应使用可追踪的幂等键，并配合唯一约束或状态判断。这样重复请求可以返回原结果，而不是产生多个订单或重复扣款。
我会先要求团队拿出真实证据，例如存储容量逼近边界、核心表维护窗口不可接受、单库读写资源持续饱和，且索引、归档、读写隔离和查询治理已经不足以解决问题。分库分表会带来跨分片查询、全局编号、数据迁移、事务一致性和运营检索问题。没有明确瓶颈时过早拆分，可能让系统更复杂却没有明显收益。
我会先保护登录、商品核心信息、库存判断、下单和支付确认，再评估推荐、评论、排行榜、复杂筛选、实时大屏和导出等非核心功能是否可以降级。关闭功能前要给用户清晰反馈，并保留订单和支付状态的可追踪性。降级不是简单地返回错误，而是提前设计简化结果、排队、稍后重试和人工补偿的路径。
不能只看某条 SQL 从 500 毫秒变成 100 毫秒，还要观察同一业务流量下的 P95、P99、错误率、锁等待、连接池、缓存命中率和数据正确性。若索引让查询变快，却使写入变慢或磁盘空间迅速增长，整体结果未必更好。我的验收方式是对比优化前后的同口径压测，并检查异常路径和恢复时间。
10 / 总结
回到最初的问题：怎样把数据库设计转化为保障高峰性能的方法？我的答案是，不要从数据库产品或技术名词开始，而要从用户动作、数据事实和业务损失开始。先知道高峰时谁在读、谁在写、谁必须正确；再决定哪些数据进入事务，哪些进入缓存，哪些通过消息异步处理；最后用压测、监控、限流、降级、回滚和对账把方案落地。
以 E数通示例项目为代表的企业电商场景，往往同时面对多渠道、多人协作、活动波峰、运营分析和数据追溯。产品经理的价值不在于替代数据库专家，而在于把业务目标说得足够精确，让研发可以设计、测试可以验证、运维可以监控、客服可以解释、管理层可以判断是否值得投入。
我最终希望团队形成一种习惯：每一项“高峰性能”承诺，都对应一组明确数据；每一项“一致性”承诺，都对应状态和补偿；每一项“可用性”承诺，都对应降级和恢复。这样，数据库设计才不再是项目末期的风险清单，而是从产品立项开始就持续产生价值的管理工具。
