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