题目重点：用订单写入和销售分析对比索引/事务与列式扫描/聚合，说明 CDC、延迟和一致性边界。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 用零售订单作为教学例子，OLTP 要及时创建/修改订单，OLAP 要在大量历史订单上统计；实际面试金融领域数据模型未给。
- 这里的 OLTP/OLAP 是工作负载倾向，不是产品二元标签；一个系统可以支持混合负载，性能取舍需以 SLO/查询模式衡量。
解题路线
- OLTP 关注短事务、小范围点查/更新、并发冲突和强约束：如每个 order_id 唯一、库存扣减与订单状态同事务。通常用行组织/主键及二级索引优化少量记录访问，过多索引会放大写成本。
- OLAP 关注跨大量历史行的过滤、分组、join 和趋势分析：列式存储只读相关列、压缩相似值、向量化扫描与分区裁剪可减少 IO；但小事务单行更新、极低延迟主键写不一定适合。
- 从交易系统到分析系统可用 CDC/事件流摄入，给每条变化稳定 ID/顺序/删除标记，作幂等落地与 schema evolution。分析侧的 freshness 可秒/分钟/批次，不得在延迟同步时承诺与交易库完全即时一致。
- 金融场景若统计日终敞口，必须定义事件时间、交易撤销/更正、货币/时区及审计回溯；不能只搬数据表而不定义语义。验证以交易系统 p99 写入、分析查询耗时、数据新鲜度、对账差额和总成本分开衡量。
手动走一遍
用户买一本书需立即写 order、扣 inventory，这是短事务；‘过去一年按月/地区的净销售额’扫描大量订单与退款并分组，适合分析链。若一笔退款刚写入 OLTP 而 CDC 还未到，OLAP 报表可能暂时旧，页面要展示数据水位。
规模与取舍
OLTP 主键点查常见 O(log N) 索引访问加 IO，事务延迟与竞争有关；OLAP 扫描 M 行 C 个所需列的成本更接近所读数据量，分区/列裁剪能减少 M/C，但不能承诺固定 Big-O 改善。题目无数据规模。
易错点与追问
容易失分的边界
- 把 OLTP/OLAP 当某个数据库品牌的绝对属性。
- 声称列存天然适合高频单行更新。
- CDC 延迟时仍承诺分析结果实时强一致。
- 无删除/更正事件处理，报表永久错误。
- 只比较速度不比较审计与成本。
继续深挖
- 什么时候在同一平台做混合负载？
- CDC 重放如何不重复计收入？
- 分析数据延迟如何向业务显示？
- schema 改列后历史分区如何回填？
