oltp 面向实时业务，查询快、小、频繁，依赖索引与 acid；olap 面向分析决策，查询慢、大、复杂，侧重全表扫描与聚合计算；二者优化目标与存储结构根本不同，不可混用。
OLTP 查询模型：快、小、频繁
OLTP 面向的是实时业务操作，比如用户下单、支付确认、库存扣减。它的查询模型天然围绕“单点事务”构建：
- 每次查询只读或写几行数据（如SELECT * FROM orders WHERE order_id = 12345）
- 95% 以上是简单条件查询，高度依赖主键或二级索引
- 写操作占比高，INSERT/UPDATE/DELETE 频繁且要求 ACID 强一致性
- 并发请求量大，但单个请求资源消耗极低
OLAP 查询模型：慢、大、复杂
OLAP 面向的是决策支持分析，比如“近半年华东区各品类 GMV 同比、环比及 Top10 城市分布”。它的查询模型本质是“全表扫描 + 多维聚合”：
- 一次查询常扫描百万至亿级行，涉及多张事实表与维度表 JOIN
- 大量使用 GROUP BY、SUM/AVG/COUNT/DISTINCT、窗口函数、子查询嵌套
- 绝大多数为只读 SELECT，不关心单条记录准确性，更关注整体统计结果的合理性
- 查询耗时从秒级到分钟级不等，允许一定延迟，但需稳定可预期
优化逻辑的根本分歧
OLTP 优化的核心是 减少 I / O 路径和锁竞争 ；OLAP 优化的核心是 提升 CPU 与内存吞吐效率：
- OLTP 调优聚焦索引设计、查询重写避免全表扫描、连接池管理、事务粒度控制
- OLAP 调优聚焦列式存储、物化视图 / 预聚合、分区裁剪、向量化执行、谓词下推
- 同一 SQL 在两类系统中表现可能天壤之别：在 MySQL 里跑得慢的聚合，在 ClickHouse 或 StarRocks 里可能毫秒返回
不能混用的底层原因
不是数据库“不够强”，而是设计契约不同：
- OLTP 引擎（如 InnoDB）为 B + 树结构优化，适合随机点查，但面对大范围扫描时磁盘寻道开销巨大
- OLAP 引擎（如 Doris、Trino、Redshift）默认按列压缩 + 编码 + 向量化，天然适配批量计算，却无法高效处理高并发短事务
- 强行让 OLTP 扛分析负载，会导致连接耗尽、锁等待堆积、主从延迟飙升——交易接口直接超时
