国产分布式数据库选型实战：从业务场景出发的四维决策模型

1. 项目概述：国产分布式数据库选型不是“换马甲”，而是重构数据底座的系统工程

最近三个月，我连续参与了三套核心业务系统的国产化迁移项目——一家省级政务平台、一家城商行的信贷中台、还有一家制造业龙头的IoT数据平台。每次启动会，客户第一句话都是：“我们想用国产数据库，但到底该选哪个？”紧接着抛出的问题往往高度雷同：PolarDB-X 和达梦DWS 谁更适合 OLAP 场景？TiDB 在高并发订单写入下会不会丢数据？OceanBase 的“三地五中心”容灾能力在实际机房网络抖动时到底稳不稳？这些问题背后，根本不是单纯的技术参数对比，而是一场涉及架构认知、运维习惯、开发范式甚至组织协同的深层变革。

所谓“数据库国产化替代”，绝不是把 Oracle 的 .sql 文件扔进新数据库里跑通就完事。它本质是用一套全新的数据治理逻辑，去承接过去十年甚至二十年积累下来的业务复杂度。你手里的那套基于 Oracle RAC 的库存扣减逻辑，迁到 TiDB 后可能因事务模型差异导致超卖；你依赖 MySQL 主从延迟做读写分离的报表系统，在 PolarDB-X 分布式事务下反而会因强一致性要求拖慢响应；你用达梦 DM8 的 PL/SQL 写的存储过程，到了 OceanBase 的 PL/SQL 兼容层里，某些系统函数调用路径完全不同。这些坑，文档里不会写，开源社区 issue 里也难搜到，全靠实操踩出来。

这六款主流国产分布式数据库——阿里云 PolarDB-X、TiDB、OceanBase、达梦 DWS、人大金仓 KingbaseES、华为 GaussDB——它们不是同一类物种。PolarDB-X 是典型的“云原生分库分表中间件演进体”，TiDB 是“HTAP 新架构派”，OceanBase 是“金融级强一致硬核派”，达梦 DWS 是“信创生态兼容优先派”，KingbaseES 是“政务场景深度定制派”，GaussDB 则是“全栈自研+AI融合派”。选型时若只看 TPC-C 基准测试分数或“支持 Oracle 语法”的宣传语，大概率会在上线后被凌晨三点的慢查询告警叫醒。这篇文章，就是把我这三年在真实生产环境里拆过的每一块砖、填过的每一个坑、验证过的每一组参数，掰开揉碎讲清楚：什么场景下该选谁，为什么这么选，以及选完之后你真正要面对的那些没人告诉你的细节。

2. 国产分布式数据库选型底层逻辑：从“能不能用”到“值不值得用”的四维决策模型

2.1 为什么不能只看“兼容性”和“性能指标”？

很多技术负责人拿到选型清单的第一反应，是打开官网查“Oracle 兼容度百分比”或“TPC-C 测试排名”。这种思路在单机数据库时代有效，但在分布式环境下，它会直接把你带进沟里。原因有三：

第一，语法兼容 ≠ 行为兼容。比如 Oracle 的SELECT FOR UPDATE SKIP LOCKED在 TiDB 中虽有对应语法，但底层实现是乐观锁 + 重试机制，而 Oracle 是悲观锁直锁行。当你的秒杀系统用这套逻辑做库存预占，TiDB 在高并发下重试次数激增，CPU 瞬间打满，而 Oracle 可能只是锁等待。再比如达梦 DM8 支持ROWNUM，但它的执行计划生成器对ROWNUM < 10这种写法的优化路径，和 Oracle 的 CBO 完全不同，一个原本 200ms 的分页查询，在达梦上可能变成 3s。

第二，基准测试成绩 ≠ 生产环境表现。TPC-C 测试跑的是标准化的、无业务逻辑的交易模型（New Order、Payment、Delivery 等），而你的系统里可能有 70% 的 SQL 带着复杂的多表关联、子查询嵌套、JSON 字段解析。我在某银行迁移项目中实测过：同一套 TiDB 集群，在 TPC-C 下 QPS 达 12 万，但跑他们真实的信用卡账单生成任务（含 5 张大表 JOIN + JSON 解析 + 窗口函数）时，QPS 不足 800，且 GC 压力巨大。这是因为 TPC-C 的数据分布高度均匀，而真实业务数据存在严重倾斜（比如某几个商户占 80% 的交易量），分布式数据库的“数据分片”策略在此时成了性能瓶颈。

第三，“能跑通”不等于“可运维”。OceanBase 的 OCP 运维平台功能强大，但它要求 DBA 必须理解其“Zone”、“Unit”、“Resource Pool”三层资源模型；PolarDB-X 的 X-Engine 存储引擎在 SSD 上性能优异，但一旦换成 NVMe，其 WAL 日志刷盘策略若未调优，反而会导致写放大加剧。这些都不是安装完就能用的，而是需要 DBA 重新学习一套新的运维知识体系。

2.2 四维决策模型：业务、架构、生态、成本的交叉验证

我把选型过程抽象成一个四维坐标系，每个维度都必须用真实业务场景去验证，而非纸上谈兵：

这个模型的核心，是拒绝“一刀切”。比如同样是金融行业，支付清算系统必须选 OceanBase（因其 Paxos 协议保障的绝对强一致），而营销活动系统则更适合 TiDB（因其更灵活的弹性扩缩容应对流量洪峰）。再比如政务系统，若已有大量基于 Oracle Forms 的老应用，达梦 DWS 的 PL/SQL 兼容性可能比 PolarDB-X 更省力；但若新上一套微服务架构的“一网通办”平台，PolarDB-X 的云原生集成度（如直接对接阿里云 ARMS、SLS）反而更具优势。

2.3 六款数据库的本质定位与适用边界

与其罗列参数，不如用一句话定义它们的“灵魂”：

• 阿里云 PolarDB-X：它是“MySQL 生态的分布式延伸”，目标是让老 MySQL DBA 和开发者最小代价平滑过渡。它不挑战 MySQL 的编程模型，而是通过分库分表中间件（DRDS）+ 自研存储引擎（X-Engine）组合，解决单机瓶颈。适合已有成熟 MySQL 应用、团队熟悉 InnoDB 事务模型、且对云服务深度集成有强需求的场景。它的强项是“像 MySQL 一样简单，有分布式的能力”，弱项是“不像原生分布式数据库那样彻底打破 MySQL 的思维惯性”。

• TiDB：它是“Google Spanner 理念的开源实践”，核心是HTAP（混合负载）与真正的弹性。TiKV（分布式 KV 存储）+ TiFlash（列存分析引擎）的分离架构，让它既能扛住 OLTP 的高并发写入，又能跑 OLAP 的复杂分析。适合业务增长快、读写混合负载明显、且愿意为架构先进性付出一定学习成本的互联网公司。它的强项是“一份数据，两种计算”，弱项是“对运维人员的分布式系统功底要求极高”。

• OceanBase：它是“蚂蚁金服双十一流量淬炼出的金融级基石”，设计哲学是“不惜一切代价保一致性”。其独特的“多副本 Paxos + 日志同步”机制，确保在任意单点故障下，RPO=0，RTO<30s。适合银行核心账务、证券清算等对数据零容忍的场景。它的强项是“金融级的确定性”，弱项是“资源消耗大，中小规模业务用起来‘杀鸡用牛刀’”。

• 达梦 DWS：它是“信创生态的‘Windows 兼容层’”，核心价值是“最大程度降低迁移改造成本”。对 Oracle、SQL Server 的语法、系统视图、存储过程、甚至管理工具（DM Manager）都做了深度兼容。适合政务、国企等有强合规要求、且遗留系统改造预算有限的客户。它的强项是“让老 Oracle DBA 感觉还在用 Oracle”，弱项是“在极致性能或云原生创新上相对保守”。

• 人大金仓 KingbaseES：它是“政务场景的深度定制专家”，优势在于“与国产操作系统、中间件、浏览器的深度适配”。其 JDBC 驱动在统信 UOS、麒麟 OS 上的稳定性，远超其他厂商；对国产浏览器（360 安全浏览器、红芯）的 Web 管理界面支持更完善。适合对国产化全栈适配有硬性考核指标的部委、省厅级项目。它的强项是“信创目录里的‘满分选手’”，弱项是“在互联网高并发场景下的社区活跃度和案例沉淀相对较少”。

• 华为 GaussDB：它是“全栈自研+AI 赋能的集大成者”，亮点是“数据库内核与昇腾 AI 芯片、MindSpore 框架的原生协同”。其内置的 AI 查询优化器（Auto Tuning）能根据历史负载自动调整执行计划，AI 故障预测模块可提前 15 分钟预警潜在宕机风险。适合华为云深度用户、或有明确 AI 赋能数据治理需求的大型企业。它的强项是“AI for DB 的落地实践”，弱项是“生态开放度略低于 TiDB/PolarDB-X，部分第三方工具适配需等待华为认证”。

选型时，务必拿着这六句话，去对照你的真实业务合同、SLA 条款、运维 SOP 文档。比如，如果你的 SLA 要求“年度不可用时间 < 5 分钟”，那么 OceanBase 的 RPO/RTO 指标就是硬门槛，其他再好也得往后排。

3. 核心细节解析与实操要点：从安装部署到生产调优的 12 个关键环节

3.1 环境准备：别让“基础环境”成为第一个拦路虎

很多人以为装数据库就是yum install或docker run，但在国产分布式数据库上，这一步的坑深得超乎想象。以 TiDB 为例，官方文档说“推荐 CentOS 7.6+”，但实际部署时，你必须确认：

• 内核参数：vm.swappiness必须设为 0（TiKV 对 swap 极其敏感，哪怕 1% 的 swap 使用率也会导致 Region 调度异常）；net.core.somaxconn需调至 65535（否则高并发连接时出现Connection reset by peer）；fs.file-max至少 100 万（TiDB Server 默认最大连接数 10 万，但每个连接占用多个文件描述符）。

• 磁盘 I/O 调度器：SSD 必须用noop或none，HDD 必须用deadline。我曾在一个项目中，因运维同事按旧习惯给 NVMe 盘设置了cfq调度器，导致 TiKV 的raftstore线程 CPU 占用率长期 95%，排查三天才发现是调度器错配。

• 时钟同步：所有节点必须使用chrony（而非ntpd），且makestep参数必须启用。TiDB 的 TSO（Timestamp Oracle）服务依赖精确时间，误差超过 500ms 就会触发timestamp jump错误，整个集群写入阻塞。实测下来，chrony在局域网内同步精度可达 ±10ms，而ntpd在虚拟机环境下波动常达 ±200ms。

再看 PolarDB-X，它的 X-Engine 存储引擎对transparent_hugepage（THP）极其反感。官方文档只提了一句“建议关闭”，但没说清楚后果。我们在一个 32C64G 的 ECS 上，因未关闭 THP，X-Engine 的 WAL 日志刷盘延迟从 2ms 暴涨到 200ms，导致 TPCC 测试中NewOrder事务成功率从 99.99% 掉到 92%。关闭命令很简单：echo never > /sys/kernel/mm/transparent_hugepage/enabled，但这个细节，90% 的初学者会忽略。

提示：所有国产分布式数据库，都强烈建议使用物理机或裸金属服务器部署。虚拟化层（尤其是 KVM/QEMU）的 I/O 虚拟化开销，会严重劣化分布式事务的延迟表现。我们做过对比测试：同一套 TiDB 集群，在物理机上 P99 延迟为 15ms，在 VMware 虚拟机上为 42ms，在阿里云 ECS（KVM）上为 38ms。对于金融级应用，这 27ms 的差距，就是 SLA 是否达标的生命线。

3.2 部署方式选择：K8s Operator vs 传统脚本，没有银弹

现在主流方案都提供 K8s Operator（如 TiDB Operator、PolarDB-X Operator），但是否一定要用？我的答案是：取决于你的 K8s 成熟度。

• 如果你的 K8s 集群已是生产级，有完善的 CI/CD、监控告警、RBAC 权限体系，那么 Operator 是最优解。它能自动处理滚动升级、故障转移、备份恢复（如 TiDB Operator 的 Backup CRD 可对接 S3），极大降低运维复杂度。

• 但如果你们的 K8s 还停留在“能跑 Demo”的阶段，或者 DBA 团队对 Helm Chart、CRD、Operator Lifecycle 等概念不熟悉，强行上 Operator 反而会制造更多黑盒问题。我们曾有个客户，因 Operator 的tidbclusterCRD 版本与 TiDB Server 版本不匹配，导致集群反复处于Pending状态，而日志里只有一句模糊的failed to reconcile，最终花了两天才定位到是 CRD 的spec.version字段格式错误。

此时，传统 Ansible 脚本反而是更稳妥的选择。我整理了一套经过 5 个项目验证的 TiDB 部署 Ansible Playbook（开源在 GitHub），其核心优势在于：

1. 步骤完全透明：每个shell模块都对应一条真实命令，systemctl start tikv-server就是启动 TiKV，没有 Operator 那种“黑盒 reconcile”。
2. 错误即时反馈：Ansible 的ignore_errors: no保证任何一步失败立即中断，并输出具体错误命令和返回码。
3. 配置可审计：所有配置文件（tikv.toml,tidb.toml）都由 Jinja2 模板生成，变量来源清晰（如{{ cluster.tikv_cpu_cores }}），方便安全审计。

注意：无论用哪种方式，必须禁用所有数据库节点的 SELinux。这是国产数据库部署中最常见的“静默杀手”。SELinux 的enforcing模式会拦截 TiKV 对/dev/shm的 mmap 操作，导致 Region 同步失败，错误日志里却只显示region not found，根本看不出是权限问题。正确做法是：setenforce 0并修改/etc/selinux/config为SELINUX=disabled。

3.3 分片策略设计：数据如何“切”，决定了 80% 的性能上限

分布式数据库的性能，70% 取决于数据分片（Sharding）策略是否合理。这不是一个技术问题，而是一个业务建模问题。

以电商订单表order_info为例，常见错误分片方式有：

• 按order_id取模：看似均匀，但order_id是递增的，导致新订单全部写入同一个分片（热点分片），而历史冷数据分散在其他分片。我们实测过，某平台用此方案，新订单写入延迟从 5ms 涨到 200ms。

• 按user_id分片：解决了写入热点，但带来了严重的“跨分片 JOIN”问题。查一个用户的全部订单，没问题；但查“某商品销量 TOP100”，就需要扫描所有分片，性能暴跌。

正确的方案是“业务主键 + 时间维度”复合分片：

1. 一级分片键（Shard Key）选user_id：保证用户数据局部性，90% 的查询（用户订单、用户评价）都在单分片完成。
2. 二级分片键（Sub-Shard Key）选create_time的年月：将order_info按user_id % 128分 128 个逻辑分片，每个逻辑分片再按YEAR(create_time)*100 + MONTH(create_time)拆成物理子表（如order_202310,order_202311）。这样，既避免了写入热点（user_id分散），又支持按时间范围高效查询（WHERE create_time BETWEEN '2023-10-01' AND '2023-10-31'只扫order_202310子表）。

PolarDB-X 的CREATE TABLE语法对此支持极好：

CREATE TABLE order_info ( order_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, create_time DATETIME NOT NULL, ... ) DBPARTITION BY HASH(user_id) TBPARTITION BY YYYYMM(create_time) TBPARTITIONS 12;

而 TiDB 的SHARD_ROW_ID_BITS参数只能解决写入热点，无法实现时间范围裁剪，必须配合应用层路由（如 ShardingSphere-JDBC）才能达到同等效果。

实操心得：分片策略必须在业务建模阶段就确定，而不是等数据库选型后再补。我们曾接手一个项目，其订单表已按order_id分片上线半年，此时要改成user_id分片，意味着全量数据重分布，停机窗口长达 72 小时。最终方案是：新建order_v2表按user_id分片，新订单写v2，老订单保持v1，通过应用层双写+数据同步，用 3 个月灰度切换。代价巨大，纯属前期设计缺失。

3.4 连接池与事务配置：那些让你的“高并发”变成“高失败”的隐藏开关

应用端的连接池配置，常常是压测失败的罪魁祸首。以 Spring Boot + HikariCP 为例，一个典型错误配置是：

spring: datasource: hikari: maximum-pool-size: 100 # 错！ connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000

问题在于maximum-pool-size: 100。这表示应用最多创建 100 个连接，但分布式数据库的连接消耗远高于单机库。TiDB Server 的默认max_connections是 4096，但每个连接会占用约 2MB 内存。如果 100 个应用实例，每个都配 100 连接，TiDB Server 内存瞬间爆掉。

正确做法是“连接数 = (应用实例数 × 单实例 QPS × 平均事务耗时) / 1000”。例如：5 个应用实例，峰值 QPS 5000，平均事务耗时 200ms，则理论连接数 = (5 × 5000 × 0.2) / 1000 = 5。所以maximum-pool-size设为 10（留 100% 余量）即可。

更关键的是事务隔离级别配置。MySQL 默认REPEATABLE READ，TiDB 默认SNAPSHOT ISOLATION（类似 Oracle 的READ COMMITTED），而 PolarDB-X 默认READ COMMITTED。如果你的应用代码里写了@Transactional(isolation = Isolation.REPEATABLE_READ)，在 TiDB 上会默默降级为SNAPSHOT，导致幻读问题。解决方案只有两个：

1. 应用层适配：将所有REPEATABLE READ逻辑改为READ COMMITTED，并确保业务能接受“不可重复读”（大多数业务其实可以）。
2. 数据库层强制：TiDB 从 v6.0 开始支持SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ，但性能损耗约 15%，且仅对乐观事务有效。

注意：分布式数据库的“全局事务”（Global Transaction）与单机事务有本质区别。OceanBase 的XA START支持真正的两阶段提交（2PC），而 TiDB 的START TRANSACTION WITH CONSISTENT SNAPSHOT只是快照隔离，不保证跨分片的原子性。这意味着，如果你在一个事务里更新了分片 A 的用户余额和分片 B 的订单状态，TiDB 无法保证两者同时成功或失败——它要么都成功，要么都失败（通过乐观锁重试），但不会出现“余额扣了，订单没建”的中间态。这是设计取舍，不是 Bug。

3.5 SQL 重写与执行计划调优：告别“EXPLAIN”里的“Unknown”

国产分布式数据库的EXPLAIN输出，信息量远超 MySQL，但也更难读懂。以 PolarDB-X 为例，它的执行计划分为三层：

• Logical Plan（逻辑计划）：展示 SQL 解析后的抽象语法树（AST），如Projection,Filter,Join。
• Physical Plan（物理计划）：展示实际执行的算子，如IndexScan,TableScan,BroadcastJoin,ShuffleJoin。
• Execution Info（执行信息）：展示每个算子的实际耗时、数据量、网络传输量。

最关键的指标是ShuffleJoinvsBroadcastJoin。BroadcastJoin是将小表广播到所有分片，本地 JOIN，性能极佳；ShuffleJoin是将两表数据按 JOIN KEY 重新分发（Shuffle），跨网络传输，性能差一个数量级。

如何避免ShuffleJoin？核心是让 JOIN KEY 成为分片键。例如，订单表order_info按user_id分片，用户表user_info也必须按user_id分片，这样SELECT * FROM order_info o JOIN user_info u ON o.user_id = u.user_id就能走BroadcastJoin。如果user_info按id分片，就会强制ShuffleJoin。

TiDB 的执行计划则更关注coprocessor下推。coprocessor是 TiKV 上的计算层，能把WHERE,GROUP BY,LIMIT等操作下推到存储层执行，大幅减少网络传输。一个典型优化是：将SELECT * FROM large_table WHERE status = 'active' LIMIT 100改为SELECT id, name, status FROM large_table WHERE status = 'active' LIMIT 100，因为SELECT *会阻止LIMIT下推，导致 TiKV 返回全量数据给 TiDB Server 再过滤。

实操心得：不要迷信EXPLAIN的“rows”估算值。TiDB 的统计信息收集器（ANALYZE TABLE）在大数据量下采样率不足，估算偏差常达 10 倍。我们的做法是：对核心大表，每周凌晨执行ANALYZE TABLE t WITH SAMPLE_SIZE = 10000000（指定采样 1000 万行），并用SHOW STATS_HEALTHY检查健康度（> 80% 为佳）。这比盲目调优执行计划更有效。

4. 实操过程与核心环节实现：从 Oracle 迁移到 PolarDB-X 的完整流水线

4.1 迁移前评估：用“血缘图谱”看清数据依赖

迁移不是技术动作，而是数据治理工程。第一步，必须绘制一张完整的“数据血缘图谱”（Data Lineage Map），涵盖：

• 源头系统：Oracle 的哪些 Schema、哪些 Table 是上游？
• 中间加工：ETL 脚本（Shell/Python）、存储过程（PL/SQL）、物化视图（Materialized View）的依赖关系。
• 下游消费：报表（Tableau/帆软）、API 接口、下游 Kafka Topic、BI 看板的数据源。

我们用 Oracle 的DBA_DEPENDENCIES视图 + 自研 Python 脚本，自动生成了这张图谱。关键发现是：某张核心customer_master表，被 17 个存储过程、8 个物化视图、3 个 ETL 脚本引用，其中 2 个存储过程用了DBMS_ALERT（Oracle 特有包），而 PolarDB-X 完全不支持。这意味着，这两个存储过程必须重写为 Java 微服务，而非简单语法转换。

提示：血缘图谱必须包含“变更影响范围”。例如，修改customer_master的phone字段长度（VARCHAR2(20) → VARCHAR(50)），会影响所有下游的INSERT INTO ... SELECT语句。我们用正则表达式扫描了全部 PL/SQL 代码，发现 4 个脚本里有硬编码的SUBSTR(phone, 1, 20)，若不修改，迁移后数据会被截断。这种细节，只有血缘分析才能暴露。

4.2 对象迁移：不只是 DDL，更是“行为迁移”

DDL 迁移工具（如阿里云 DTS、Ora2Pg）能自动转换CREATE TABLE，但以下“行为”必须人工干预：

• 序列（Sequence）：Oracle 的NEXTVAL是全局唯一，PolarDB-X 的AUTO_INCREMENT是分片局部唯一。解决方案：用SELECT LAST_INSERT_ID()获取刚插入的 ID，或改用 UUID（但会牺牲索引效率）。

• 物化视图（MV）：Oracle MV 支持FAST REFRESH（增量刷新），PolarDB-X 不支持。我们的替代方案是：用 Flink CDC 监听 Oracle 的 Redo Log，实时将变更写入 Kafka，再由 Flink Job 计算聚合结果，写入 PolarDB-X 的汇总表。虽然架构变重，但实时性更好。

• 分区表（Partition）：Oracle 的RANGE分区在 PolarDB-X 中需转为LIST或HASH分区，因为 PolarDB-X 的RANGE分区仅支持DATE类型，且不支持INTERVAL自动扩展。我们把PARTITION BY RANGE (create_time)改为PARTITION BY LIST COLUMNS(create_time)，并每月手动ALTER TABLE ADD PARTITION。

• 约束（Constraint）：Oracle 的DEFERRABLE约束（延迟校验）在 PolarDB-X 中不支持。我们把所有DEFERRABLE INITIALLY DEFERRED的外键，改为应用层校验，并在事务开头加SET FOREIGN_KEY_CHECKS=0（临时关闭）。

4.3 数据迁移：准不停服的“双写+校验”三阶段法

我们采用业界公认的“双写 + 全量校验 + 增量追平”三阶段法，确保 RPO=0：

阶段一：双写（Dual Write）

• 应用层改造：所有写操作（INSERT/UPDATE/DELETE）同时写 Oracle 和 PolarDB-X。
• 关键控制：用 RocketMQ 事务消息保证双写原子性。应用先发Prepare消息，成功后再写 Oracle，Oracle 提交后发Commit消息，消费者收到Commit后写 PolarDB-X。若 Oracle 写失败，Prepare消息超时回滚，PolarDB-X 不写。
• 持续时间：2 周，观察 PolarDB-X 的写入延迟、错误率、资源消耗。

阶段二：全量校验（Full Validation）

• 工具：阿里云 DTS 的“数据一致性校验”功能，或自研的checksum工具（对每张表按PRIMARY KEY分块，计算MD5(CONCAT(...))）。
• 重点：校验TEXT,BLOB,CLOB字段的二进制一致性（Oracle 的CLOB和 MySQL 的TEXT编码可能不同）。
• 结果：发现 3 张表因字符集转换（AL32UTF8 → utf8mb4）导致中文乱码，回滚修复。

阶段三：增量追平（Incremental Catch-up）

• 切换读流量：将 10% 的读请求路由到 PolarDB-X，逐步提升至 100%。
• 切换写流量：在业务低峰期（凌晨 2-4 点），停止双写，将写流量切到 PolarDB-X。
• 最终校验：用 DTS 的“增量数据比对”功能，确认最后 1 小时的增量数据 100% 一致。

注意：双写期间，Oracle 的SYSDATE和 PolarDB-X 的NOW()时区可能不同（Oracle 默认+08:00，PolarDB-X 默认SYSTEM），导致时间字段不一致。解决方案：统一在应用层用new Date()生成时间戳，数据库字段类型全用BIGINT存毫秒时间戳，彻底规避时区问题。

4.4 应用适配：那些“看起来一样，其实不一样”的 SQL 陷阱

即使语法兼容，SQL 行为也可能天差地别。我们整理了 12 个高频陷阱：

1. ROWNUM伪列：OracleSELECT * FROM t WHERE ROWNUM <= 10是先取 10 行再排序；PolarDB-X 的LIMIT 10是先排序再取 10 行。必须重写为SELECT * FROM (SELECT * FROM t ORDER BY id) t1 LIMIT 10。

2. NVL函数：OracleNVL(col, 'default')在 PolarDB-X 中需改为IFNULL(col, 'default')，且col为NULL时，IFNULL返回'default'，而NVL在col为''（空字符串）时也返回'default'。需加OR col = ''判断。

3. TO_DATE格式：OracleTO_DATE('2023-10-01', 'YYYY-MM-DD')在 PolarDB-X 中需用STR_TO_DATE('2023-10-01', '%Y-%m-%d')，且后者对非法日期（如'2023-13-01'）返回NULL，而 Oracle 抛异常。

4. CONNECT BY层次查询：Oracle 的树形查询在 PolarDB-X 中无直接对应，需用递归 CTE（WITH RECURSIVE），但 PolarDB-X v5.4 才支持，旧版本需用存储过程模拟。

5. FOR UPDATE NOWAIT：Oracle 此语句在锁冲突时立即报错；PolarDB-X 的SELECT ... FOR UPDATE默认会等待，需