存储选型先看数据不变量和访问模式，再看团队能否可靠运维。多数业务系统以成熟关系库为默认起点更稳妥；只有明确收益超过同步、一致性和运维成本时，才引入专用存储。
Table of contents
五类候选的重心
| 候选 | 擅长方向 | 重点验证 |
|---|---|---|
| MySQL | 通用 OLTP、成熟生态、复制与运维 | SQL/索引、事务、扩展边界 |
| PostgreSQL | 丰富 SQL、类型、扩展与复杂查询 | 团队经验、扩展治理、复制方案 |
| MongoDB | 文档聚合、结构演进、按文档访问 | 文档边界、跨文档事务、索引与膨胀 |
| ClickHouse | 列式分析、聚合和高吞吐扫描 | 写入模型、更新删除、查询并发 |
| 对象存储 | 大文件、低成本容量、生命周期管理 | 一致性需求、元数据、权限与删除 |
OLTP 是面向短事务的在线交易处理；OLAP 是面向扫描与聚合的在线分析。把分析查询直接压到核心交易库，或把逐行交易更新硬塞进分析库，都会违背存储的主要工作负载。
用六个问题做决策
- 必须原子维护哪些不变量？
- Top 查询按什么键过滤、关联、排序和聚合？
- 读写量、数据量、保留期和增长率是多少？
- 允许多旧的数据，故障时 RPO/RTO 是多少？
- 团队能否完成监控、备份、升级和恢复？
- 将来如何迁移、双写、校验与退出？
StorageAdvisor.java下载只是把工作负载映射为调查起点，它故意不返回“万能答案”。真实 ADR 应附数据规模、候选版本、实验结果和淘汰理由。
多存储架构的隐性税
每增加一种数据库，就增加驱动、账号、备份、监控、升级、值班和数据同步链路。同步又带来重复、乱序、延迟、删除传播和 Schema 演进问题。能由一个关系库加对象存储清晰解决时，不必为了“技术栈完整”引入五种系统。
最小验证应使用真实查询与数据分布，测吞吐和 P99，同时演练节点故障、恢复、扩容与版本升级。基准快但恢复不了的数据系统不能进入生产。
本阶段检查点
完成本章后，你应能从 Mapper 代理追到 JDBC 和 InnoDB，能用执行计划解释索引选择，能设计事务、恢复和迁移验证，也能说明一个存储“不适合”的边界。
下一步
当前 06.MyBatis与MySQL 阶段到此完成。按照暂停约定，本轮不进入 07.Redis与分布式缓存；恢复目标后再从 Redis 数据结构与单线程模型开始。