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扛分析负载，会导致连接耗尽、锁等待堆积、主从延迟飙升——交易接口直接超时
