一句话定义：OLTP（Online Transaction Processing，联机事务处理）关注把每一笔业务准确、快速地办理完成；OLAP（Online Analytical Processing，联机分析处理）关注把海量历史业务汇总起来，观察规律和趋势。
先打个比方。超市收银台就是 OLTP：扫一件商品、扣一次库存、收一笔钱，每笔操作都很小、很快，而且绝对不能出错，也不能丢失。老板年底让财务把一整年的流水拉出来，算哪个品类卖得最好、周末和工作日客流差多少，这就是 OLAP。两者其实是同一批数据的两个方向：一个往前写，一个往回看。它们对系统的要求几乎相反：
| 维度 | OLTP | OLAP |
|---|---|---|
| 典型动作 | 下单、支付、改地址、查订单 | 汇总、分组、同比环比、趋势 |
| 单次涉及数据 | 几行 | 几十万行到几十亿行 |
| 响应预期 | 毫秒级 | 秒到分钟，能等 |
| 并发形态 | 大量用户同时发小请求 | 少量人跑大查询 |
| 数据状态 | 当前最新值，随时在变 | 历史快照，批量导入 |
| 优化方向 | 事务、索引点查、行式存储 | 列式存储、并行扫描、压缩 |
和相邻概念的区别：OLTP 所在的位置，一般就是“业务库”，是事实发生的地方；OLAP 通常落在数据仓库、数据集里，是事实被回看的地方。两者之间靠 ETL 或 CDC（变更数据捕获）搬运数据。近年也有 HTAP（混合事务分析处理）想在一套系统里兼顾两边，但代价通常是两边都不极致，选型时要清楚自己主要承受的是哪一侧压力。
为什么 AI 应用别直接在业务库上跑重查询：这是实践中最常见的坑之一。一条不带好索引的 GROUP BY 全表扫描，会把磁盘 IO 和 CPU 占满，前台用户的下单就开始转圈；大查询还会长时间占用连接池，把连接数吃光，相当于收银台前全被一个搬货的人堵住；反复的相似查询还会把缓存里的热数据挤出去，让原本很快的查询变慢。再加上给分析脚本开一个高权限账号，误删误改的风险也实打实存在。
比较稳妥的做法是：业务库只负责写和点查，把数据通过 CDC 或定期同步复制到只读副本、分析库或离线数仓，重查询和模型训练在那里跑；向量检索的 embedding 也放在专门的向量索引里，别塞进业务表。以各产品官方文档为准，具体同步方案和参数要看自家情况。
对从业者的意义：判断一个需求是“记账”还是“算账”，选型、建索引、限流、分库分表的决策基本就有依据了。对普通人的意义：月底报表为什么慢、为什么促销当天不能随便跑大数据，答案往往就在这条线上。