一句话理解
数据库选型首先服务于业务模型、事务边界、数据规模、合规约束、团队能力和迁移成本；分库分表也不是性能焦虑下的默认方案，应先把单库单表、SQL、索引、连接池和读写模型优化到合理，再用数据证明需要拆分。
一、选型判断框架
| 维度 | 需要回答的问题 |
|---|---|
| 业务 | 事务复杂度、报表分析、批处理和实时查询是什么比例？ |
| 数据 | 当前与未来数据量、增长速度、热点和归档策略是什么？ |
| 可靠性 | 是否需要高可用、备份恢复、容灾和明确 RPO/RTO？ |
| 合规 | 是否有信创、内网、国产软硬件或供应商认证要求？ |
| 兼容 | 现有 SQL、存储过程、驱动、ORM 和运维工具能否迁移？ |
| 团队 | 团队最熟悉什么，现场交付和问题响应能力如何？ |
| 成本 | 许可、硬件、服务、迁移、培训和长期运维成本如何？ |
不要只用"哪个数据库性能高"回答。企业系统的总成本通常包括迁移和运维，理论峰值不是唯一决策依据。
二、Oracle、达梦、MySQL 的定位对比
| 维度 | Oracle | 达梦 | MySQL |
|---|---|---|---|
| 常见优势 | 企业级事务、复杂 SQL、成熟工具和大型项目经验 | 国产化场景、与部分 Oracle 语法和生态有较高兼容度 | 开源生态、易上手、互联网和中小型业务广泛使用 |
| 典型场景 | 大型核心系统、复杂事务和存量项目 | 信创替代、政企和国产化交付 | Web 业务、企业应用、成本敏感项目 |
| 关注点 | 许可和运维成本、专业能力 | 版本、驱动、工具和生态适配 | 复杂存储过程、超大规模和强一致复杂场景需专项评估 |
| 迁移重点 | 作为源库时梳理方言和对象 | 验证兼容性与性能，不能只看语法 | 从其他数据库迁移时检查函数、类型和事务语义 |
"达梦兼容 Oracle"应表述为：对很多 Oracle 语法和开发习惯兼容度较高，但必须针对 SQL、存储过程、数据类型、函数、驱动、工具链和性能做验证，不能绝对宣称完全兼容或零改造。
三、Oracle 与达梦迁移方法
1. 盘点对象
text
表/索引/约束
+ 视图/序列/同义词
+ PL/SQL 存储过程、函数、包、触发器、Job
+ JDBC 驱动、连接池、ORM 方言
+ 报表、脚本、ETL 和运维工具2. 重点差异
- 数据类型映射：精度、字符集、时间类型、LOB 和空值语义；
- 分页与函数：
ROWNUM、窗口函数、日期函数、字符串函数等逐条验证； - 序列与主键：序列缓存、并发取值和回滚后的间隙是否影响业务；
- 存储过程：游标、异常、批量处理、包、动态 SQL 和事务边界；
- 驱动与连接池：URL、驱动类、参数、连接验证和超时；
- 事务与锁：隔离级别、锁行为、自动提交和长事务；
- 执行计划：同一 SQL 在新数据库上可能选择不同索引或连接顺序。
3. 验证而不是口头判断
迁移应建立代表性数据集和回归用例，至少覆盖：功能结果、金额和数量精度、分页顺序、并发写入、异常回滚、批处理耗时、核心 SQL 执行计划、备份恢复和高峰压测。生产迁移前进行双跑或灰度比对，保留回退路径。
四、MySQL 企业应用实践
在数据规模可控的 SRM、ERP、办公和业务管理系统中，MySQL 常是务实选择。重点不是盲目换数据库，而是：
- 按业务查询设计联合索引并用
EXPLAIN验证； - 避免循环中的 N+1 查询、无条件大分页和全表扫描；
- 控制事务范围，避免长事务和大批量锁表；
- 连接池设置上限、超时和泄漏检测，保护数据库；
- 热点读使用缓存，但明确缓存失效和一致性策略；
- 大表按时间归档，先降低在线数据量；
- 对核心字段设置唯一约束、外键或应用层约束，防止脏数据。
数据库升级和字符集调整也应经过备份恢复演练与兼容性测试，不能只在开发环境验证。
五、何时考虑分库分表
先按顺序排查：
text
慢 SQL / 索引
→ 查询与事务设计
→ 连接池和并发模型
→ 缓存与读写分离
→ 归档、分区和历史数据治理
→ 垂直拆分
→ 水平分表只有当单表体量、写入压力、索引维护、备份恢复或业务隔离确实成为瓶颈，并且优化单库单表已不能满足目标，才进入分片评估。分片会引入跨库查询、全局 ID、分布式事务、分页、排序、扩容和运维复杂度。
六、垂直与水平拆分
1. 垂直拆分
按业务域或读写特征拆分，例如把采购、商城、对账等高耦合度较低的域分开。优点是边界清晰、故障和容量隔离；代价是跨域查询和事务需要重新设计。垂直拆分前应先清理跨模块表访问，避免只是把一个大库切成多个互相直连的库。
2. 水平分表
同一业务表按租户、组织、订单号或时间拆成多个物理表。分片键要满足：
- 查询大多数带分片键；
- 数据分布相对均衡；
- 业务生命周期稳定；
- 后续扩容和迁移可执行；
- 不把高频热点集中到一个分片。
| 策略 | 优点 | 风险 |
|---|---|---|
| 按时间范围 | 便于归档、范围查询 | 当前时间段可能写热点 |
| 按哈希 | 分布均衡、写入稳定 | 范围查询和扩容迁移复杂 |
| 按租户/组织 | 隔离清楚、适合多租户 | 大租户可能成为热点，租户规模不均衡 |
七、分库分表的配套设计
- 全局 ID：雪花算法、号段或数据库服务，需处理时钟回拨、趋势递增和跨系统追踪。
- 路由：明确哪些 SQL 必须带分片键，禁止无条件广播查询进入核心链路。
- 跨库查询：通过冗余字段、搜索索引、汇总表或离线分析解决，不把跨库 JOIN 当常规能力。
- 事务：优先调整业务边界和流程；确需跨库时评估最终一致性、可靠事件或分布式事务，明确补偿和失败语义。
- 分页排序：避免全局深分页，使用游标、时间范围或分片内分页后归并。
- 扩容：提前设计双写、数据迁移、校验、切流、回滚和旧分片下线方案。
- 运维：监控各分片容量、热点、慢 SQL、复制延迟、路由错误和数据校验差异。
ShardingSphere 等中间件可以降低路由接入成本，但不会消除分片后的业务复杂度，尤其不能替团队决定事务边界和查询模型。
八、数据库性能排查顺序
- 用监控、traceId 或慢查询日志确认瓶颈是否真的在数据库。
- 通过
EXPLAIN检查访问路径、扫描行数、连接方式和回表情况。 - 检查索引是否匹配过滤、排序和联合索引最左前缀，注意函数、隐式转换和前导通配符。
- 检查锁等待、事务持续时间、连接池耗尽和磁盘 IO。
- 优化 SQL、索引、批量方式和事务边界后重新压测。
- 仍不能满足容量目标，再评估缓存、读写分离、归档、垂直或水平拆分。
九、常见风险
- 把达梦完全兼容 Oracle 当成迁移结论，没有做对象和性能验证；
- 只迁移表结构，没有迁移存储过程、脚本、报表和驱动配置；
- 看到大表就分表，结果跨库 JOIN 和事务复杂度超过收益；
- 选分片键只看当前查询，不看未来报表和扩容；
- 分布式 ID 依赖本地时钟，却没有处理时钟回拨；
- 通过中间件隐藏广播查询，线上出现全分片扫描；
- 忽略备份恢复、数据校验和切换回滚；
- 只做平均耗时测试，没有覆盖热点、峰值和长事务。