关系型数据库工具
关系型数据库共同使用 SQL，却拥有完全不同的进程模型、权限体系、复制机制、备份工具和扩展路线。选型不能停在“团队会不会写 SQL”，还要同时评估一致性、恢复目标、运维能力、生态兼容和长期成本。
产品地图
| 工具 | 更适合解决的问题 | 决策时重点观察 |
|---|---|---|
| MySQL | 通用互联网事务、成熟主从生态 | InnoDB、复制延迟、读写分离、分库分表与云托管 |
| PostgreSQL | 复杂查询、扩展能力、严格数据模型 | role/schema、MVCC、VACUUM、WAL、扩展与连接池 |
| MariaDB | MySQL 生态下的开源替代与 Galera 路线 | 兼容差异、GTID、Galera、MaxScale 与升级路径 |
| SQLite | 单机嵌入、CLI、小型应用与测试夹具 | 文件锁、WAL、并发边界、备份和容器卷 |
| SQL Server | 微软技术栈和企业数据应用 | edition、登录与用户、加密连接、备份及 Always On 路线 |
| Oracle | 复杂企业系统和成熟商业生态 | CDB/PDB、tablespace、授权、Data Pump 与高可用成本 |
| openGauss | PostgreSQL 生态迁移与国产化场景 | 兼容模式、驱动、主备能力和迁移验证 |
| 达梦 DM8 | 国产数据库适配和商业支持场景 | 模式、兼容参数、驱动、授权与迁移差异 |
| KingbaseES | 国产化替换和 PostgreSQL 兼容路线 | DB_MODE、编码、驱动、授权与高可用产品边界 |
共同验证矩阵
同样一条 SQL，在不同数据库里可能落到完全不同的身份、命名空间和恢复责任上。团队做技术验证时，应当把下面六个问题放在同一张记录里，不要只留下“连接成功”的截图。
| 产品 | 身份模型 | 命名空间 | 高可用入口 | 恢复入口 | 长期成本 |
|---|---|---|---|---|---|
| MySQL | account@host、role 与动态权限 | instance → database → table | GTID 复制、Group Replication / InnoDB Cluster、第三方 PXC / MHA | 逻辑备份、物理备份、binlog 与 PITR | 复制延迟、单写瓶颈、代理与分片治理 |
| PostgreSQL | cluster role、membership 与对象 owner | cluster → database → schema → object | 流复制、同步复制、Patroni / repmgr 或托管控制面 | pg_dump、base backup、WAL 归档与 PITR | VACUUM、WAL 保留、连接池、extension 生命周期 |
| MariaDB | account@host、role 与 privilege | instance → database → table | 复制、Galera、MaxScale | mariadb-dump、MariaDB Backup 与 binlog | MySQL 兼容验证、集群写放大和版本耦合 |
| SQLite | 文件权限与应用进程身份 | database file → attached database → table | 应用级冗余，不提供服务端 HA | 在线 backup API、文件快照、WAL 检查点 | 文件锁、写并发和分发升级责任 |
| SQL Server | login、database user、role | instance → database → schema → object | Always On、Failover Cluster 或托管服务 | full / differential / log backup 与时间点恢复 | edition、CAL / core 授权、tempdb 和日志容量 |
| Oracle | common / local user、role、profile | CDB → PDB → schema → object | Data Guard、RAC 或云托管控制面 | Data Pump、RMAN、archive log 与时间点恢复 | 授权、选件、存储、补丁和专业运维团队 |
| openGauss / 达梦 / KingbaseES | 产品账号、角色和兼容模式共同决定权限 | 以实际兼容模式和实例参数验证 | 厂商主备、集群套件或托管能力 | 厂商导出、物理备份与日志链 | 授权支持、迁移差异、工具生态和退出路径 |
验证结论至少要留下：实际连接身份、默认命名空间、最小权限拒绝证据、备份制品位置、恢复后的业务校验、故障切换责任人，以及容量和许可的年度成本口径。
MySQL 与 PostgreSQL 学习路径
MySQL 先从部署与项目接入建立可重复环境，再进入 InnoDB、查询与事务，最后用高可用、扩展与恢复处理复制、路由、分片和容灾。
PostgreSQL 先从部署与项目接入理清 role、database、schema 和 search_path，再进入查询、事务与 VACUUM，最后用高可用、恢复与治理贯通 WAL、复制、连接路由和 PITR。
从单机走向生产
演进不是固定阶梯。低流量核心系统也可能因为 RPO 要求直接选择高可用或云托管；高并发系统也不应在没有容量证据时过早分库分表。每一步都要用连接数、事务冲突、复制延迟、容量增长、恢复时间和团队值守能力证明必要性。
关系库的共同故障面
- 字符集、时区、排序规则和大小写规则在本机与共享环境不一致。
- 初始化脚本只在空数据目录执行，旧 volume 让新账号或 schema 看似“没有生效”。
- 应用复用管理员身份，迁移工具拥有永久 DDL 权限，误操作无法限制爆炸半径。
- 长事务、热点更新、锁等待和连接风暴相互放大，最终表现为全链路超时。
- 只做备份不做隔离恢复，故障时才发现文件、日志链或密钥不完整。
建议先学习 MySQL 与 PostgreSQL，建立复制、MVCC、索引、锁和恢复的基本模型；再根据技术栈、国产化要求、嵌入式需求或商业支持约束进入其他文章。