企业官网建设流程全解析

1. 这不是一份“参数表格”，而是一份踩过坑、调过参、扛过压测的选型手记

PolarDB-X 是这两年国产分布式数据库里绕不开的名字，尤其在金融、政务、大型电商这些对数据一致性、扩展性、合规性要求极高的场景里，它频繁出现在技术架构评审会上。但如果你真去翻官方文档、社区帖子、甚至某些“权威对比报告”，会发现一个尴尬的事实：很多内容要么堆砌术语，说“支持HTAP”“兼容MySQL协议”就完事；要么陷入纯理论推演，比如“分库分表逻辑透明”听起来很美，可你一上线就遇到跨库JOIN性能断崖式下跌；更常见的是，把PolarDB-X和TiDB、OceanBase、达梦、人大金仓简单列个表格，比比TPS、QPS、是否开源，然后告诉你“综合来看PolarDB-X更适合中大型企业”——这等于没说。我带团队做过3次PolarDB-X的POC，从2.0到最新的3.0版本，中间经历过订单库拆分失败、全局二级索引写放大导致磁盘IO打满、GSI变更期间业务查询超时率飙升到15%的凌晨三点。所以这篇东西，不叫“选型指南”，它是一份全维度对比手记，核心是回答你在真实世界里一定会问的那些问题：它到底在什么条件下能稳？在什么边界下会崩？哪些“官方说支持”的能力，在你自己的业务模型里是不是真能用？比如，你那个每天新增500万订单、历史数据按月归档、查询80%集中在最近7天的订单中心，PolarDB-X的分区策略怎么设才不会让冷热数据混在一起拖垮性能？再比如，你现有的Spring Boot应用用了MyBatis-Plus，连着单体MySQL跑得好好的，迁到PolarDB-X后，哪些SQL写法必须改，改了之后性能是变好还是变差？这些细节，没有一次真实的压测、没有一次灰度切流、没有一次半夜的紧急回滚，根本写不出来。它适合两类人：一类是正在做技术选型的技术负责人，需要知道PolarDB-X在你具体业务场景下的真实水位线；另一类是已经决定用它、正准备动手落地的DBA或后端工程师，需要避开那些文档里绝口不提的“暗礁”。下面所有内容，都来自我们生产环境的真实数据、配置和日志。

2. 全维度对比框架：为什么不能只看TPS和兼容性？

选型这件事，最危险的陷阱就是把数据库当成一个黑盒，只关心输入（SQL）和输出（结果+响应时间），然后拿几个标准测试工具（比如Sysbench）跑几轮，看谁分数高就选谁。PolarDB-X不是单机MySQL，它是一个由计算节点（CN）、存储节点（DN）、全局事务管理器（GTM）组成的分布式系统。它的性能、稳定性、运维复杂度，不是由某一个组件决定的，而是由这三者之间的协同关系、以及它们与你业务流量模式的匹配度共同决定的。所以，我们的对比框架，必须穿透表面指标，落到四个不可回避的维度上：架构适配性、SQL兼容性深度、运维可观测性、成本结构透明度。这四个维度，每一个都直接关联到你上线后的第一周、第一个月、第一年的体验。

2.1 架构适配性：你的业务流量，是PolarDB-X的“朋友”还是“天敌”？

PolarDB-X的核心价值在于“水平扩展”，但它不是万能的。它的扩展能力，高度依赖于你业务数据的分布特征和访问模式。我们见过太多团队，因为没想清楚这个问题，导致投入巨大却收效甚微。

• 数据分布特征：PolarDB-X默认采用“分库分表”策略，主键（或指定的Sharding Key）决定了数据落在哪个DN上。如果你的业务主键是UUID或者雪花ID（Snowflake ID），那恭喜你，数据会非常均匀地打散到各个DN上，读写压力天然均衡，这是PolarDB-X最喜欢的模式。但如果你的主键是用户ID，而你的业务存在明显的“二八定律”——比如20%的头部KOL贡献了80%的评论和点赞，那么这20%的用户数据就会集中在少数几个DN上，形成热点。这时，PolarDB-X的“水平扩展”优势就荡然无存，反而因为CN要协调大量请求到同一组DN，引入额外的网络开销和锁竞争。我们一个客户的真实案例：他们的用户ID是自增整数，且新注册用户ID递增，导致所有新用户数据都写入同一个DN，该DN的CPU长期95%以上，而其他DN空闲。解决方案不是加机器，而是强制将用户ID哈希后作为Sharding Key，牺牲一点查询便利性，换来整体负载均衡。

• 访问模式：PolarDB-X对“单点查询”（如SELECT * FROM orders WHERE order_id = ?）优化得极好，因为它能根据Sharding Key精准路由到一个DN，整个过程几乎等同于单机查询。但对“范围查询”（如SELECT * FROM orders WHERE create_time BETWEEN ? AND ?）和“跨分片JOIN”（如SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id），它就必须启动分布式执行计划，CN要向多个DN发起请求，收集结果后再合并。这个过程的延迟，是单机查询的数倍甚至数十倍。我们做过一组对比：同样是查100条订单，单点查询平均耗时8ms，而按时间范围查（覆盖3个分片）平均耗时42ms，跨分片JOIN更是飙到120ms以上。这意味着，如果你的业务核心链路里，有超过30%的查询是范围扫描或JOIN，那么PolarDB-X带来的性能提升，可能被这部分开销完全抵消，甚至不如一台配置拉满的单机MySQL。

提示：在做POC之前，务必用你线上真实的慢SQL日志，抽样1000条，统计其中单点查询、范围查询、JOIN查询的比例。如果范围/JOIN占比超过25%，就要认真评估PolarDB-X是否真的适合你，而不是盲目追求“分布式”。

2.2 SQL兼容性深度：不是“能跑”，而是“跑得像单机一样稳”

官方文档说“高度兼容MySQL 5.7/8.0协议”，这没错。但“兼容协议”和“兼容行为”是两回事。协议兼容，意味着你的JDBC连接串能连上，SELECT 1能返回结果。而行为兼容，意味着你原来在MySQL里写的存储过程、触发器、复杂的子查询、甚至是某些特定的Hint，在PolarDB-X里执行的结果、性能、事务语义，都和原来一模一样。现实是，PolarDB-X为了实现分布式事务和并行执行，对很多MySQL原生特性做了取舍或重写。

• 事务隔离级别：MySQL默认是REPEATABLE READ，PolarDB-X也支持，但它的实现机制不同。在MySQL里，RR靠MVCC快照；在PolarDB-X里，RR依赖GTM生成的全局时间戳。这意味着，在高并发下，PolarDB-X的RR可能会出现比MySQL更严格的锁等待，或者在极端情况下，出现“幻读”现象（虽然概率极低）。我们曾在一个库存扣减场景中遇到：两个并发事务同时读取同一商品库存，都看到有货，然后都尝试扣减，最终只有一个成功。这在单机MySQL的RR下是正常的，但在PolarDB-X里，由于GTM的时间戳分配策略，第二个事务的提交会被阻塞更久，导致接口超时。解决方案是，将关键业务逻辑的隔离级别显式降级为READ COMMITTED，并配合应用层的乐观锁。

• 函数与语法：大部分常用函数（NOW(),DATE_ADD()）没问题，但一些高级函数就有坑。比如JSON_EXTRACT()，在PolarDB-X 2.x版本里，对嵌套层级很深的JSON解析性能极差，一个10KB的JSON字段，提取一个子字段要耗时200ms。而同样的SQL在MySQL 8.0里只要5ms。原因是PolarDB-X的JSON解析引擎没有针对分布式场景做深度优化。再比如，INSERT ... ON DUPLICATE KEY UPDATE语句，在PolarDB-X里，如果涉及分片键，它能完美工作；但如果ON DUPLICATE KEY的条件是基于非分片键的唯一索引，PolarDB-X就无法保证原子性，可能会出现部分更新成功、部分失败的情况，需要应用层兜底。这些都不是文档里会重点强调的“不支持”，而是“支持但有隐含限制”。

• 执行计划：这是最容易被忽视的点。EXPLAIN出来的执行计划，在PolarDB-X里看起来和MySQL差不多，但背后含义天差地别。MySQL的EXPLAIN告诉你“走哪个索引”，PolarDB-X的EXPLAIN则要告诉你“这个查询是在CN上执行，还是下发到DN上执行，下发了几个DN，是否需要聚合”。我们曾有一个报表SQL，EXPLAIN显示走了索引，但实际执行慢得离谱。深入分析发现，EXPLAIN里的type: index，在PolarDB-X里代表“CN扫描了所有DN的索引”，而不是“单个DN扫描了它的索引”。也就是说，它把一个本该在单个DN上完成的索引扫描，变成了在所有DN上并行扫描，然后再汇总。这种“伪优化”在分布式数据库里非常普遍，必须结合EXPLAIN FORMAT=TRADITIONAL和SHOW EXECUTE PLAN命令，才能看清真实执行路径。

2.3 运维可观测性：从“能用”到“敢用”，中间隔着一整套监控体系

选型时，大家关注性能，上线后，大家才发现，运维的便捷性和故障定位的速度，才是决定系统生死的关键。PolarDB-X的运维体系，和单机MySQL有本质区别。你不能再只盯着SHOW PROCESSLIST和INFORMATION_SCHEMA，你需要一套能穿透CN、DN、GTM三层的立体监控视图。

• 核心指标监控：PolarDB-X提供了丰富的Prometheus指标，但关键是要知道哪些是“黄金信号”。我们团队定义了5个必看指标：

  1. polarx_cn_query_latency_ms_bucket{le="100"}：CN层查询延迟，反映计算节点的健康度。如果这个值突增，说明CN本身CPU或内存瓶颈，或者GTM通信异常。
  2. polarx_dn_io_wait_seconds_total：DN层IO等待时间，直接关联磁盘性能。我们曾因云厂商底层磁盘IOPS配额不足，导致此指标飙升，业务大面积超时。
  3. polarx_gtm_txn_commit_duration_seconds_bucket{le="1"}：GTM事务提交延迟，这是分布式事务的“心脏指标”。一旦它超过1秒，就意味着全局事务协调出了严重问题，所有写操作都会被拖慢。
  4. polarx_cn_distributed_plan_count：CN生成分布式执行计划的次数。如果这个值异常高，说明你的SQL大量触发了跨分片操作，是性能劣化的早期预警。
  5. polarx_dn_replica_lag_seconds：DN主从复制延迟。PolarDB-X的DN是主从架构，从库延迟过高，会导致读写分离失效，强一致性读取失败。

• 日志诊断：PolarDB-X的日志体系分为CN日志、DN日志、GTM日志。最致命的错误，往往藏在GTM日志里。比如，一个看似普通的INSERT超时，CN日志只显示timeout，DN日志一切正常，但GTM日志里会有一行[WARN] GTM transaction xid=xxx is blocked by lock on DN yyy，这直接指向了死锁根源。我们建立了一套日志关联分析流程：当CN出现慢查询告警，自动抓取该SQL的trace_id，然后并行检索CN、DN、GTM三端日志，将碎片化信息拼成完整调用链。这套流程，把平均故障定位时间从2小时缩短到15分钟。

• 配置热变更：PolarDB-X支持很多参数的在线修改，比如cn_query_timeout、dn_max_connections。但并非所有参数都安全。我们吃过一次大亏：为了缓解某个慢查询，将cn_distributed_join_threshold从默认的1000调到了10000，意图让更多的JOIN在CN层完成。结果导致CN内存瞬间被打满，OOM Killer干掉了CN进程。后来才知道，这个参数的调整，会直接影响CN的内存分配策略，必须同步调整cn_heap_size。所以，任何配置变更，都必须遵循“小步快跑、灰度验证、监控观察”的原则，绝不能一次性全量推送。

2.4 成本结构透明度：算清这笔账，比选型本身更重要

很多人只算服务器硬件成本，却忽略了PolarDB-X带来的隐性成本。这些成本，在项目初期不明显，但会在系统规模扩大后，成为压垮团队的最后一根稻草。

• 人力成本：PolarDB-X的DBA，和MySQL DBA，是两种技能树。前者需要懂分布式系统原理、网络协议、GTM调度算法；后者更侧重SQL优化、索引设计、备份恢复。我们团队为此专门成立了“分布式数据库小组”，由1名资深DBA牵头，搭配2名熟悉Java和Spring生态的后端工程师，共同负责PolarDB-X的日常运维和SQL治理。这个小组的年度人力成本，远超我们维护原有MySQL集群的总和。这不是浪费，而是必要的投资。因为PolarDB-X的很多问题，比如分布式死锁、GSI变更卡顿，都需要应用层和数据库层协同排查，单靠DBA或单靠开发，都搞不定。

• 迁移成本：从MySQL迁移到PolarDB-X，绝不是改个JDBC URL那么简单。我们梳理出6大类必须改造的点：

  1. 分片键设计：必须为每张核心表选定一个合适的Sharding Key，并重构所有相关SQL。
  2. 分布式事务改造：放弃@Transactional的粗粒度控制，改用PolarDB-X的XID或Seata进行精细化编排。
  3. SQL重写：禁用所有可能导致全表扫描的ORDER BY ... LIMIT，改用基于分片键的游标分页。
  4. GSI（全局二级索引）规划：PolarDB-X的GSI是异步构建的，写放大严重，必须严格评估其必要性，宁缺毋滥。
  5. 连接池配置：HikariCP的maximumPoolSize不能照搬MySQL的经验值，必须根据CN的并发处理能力重新测算。
  6. 监控告警体系重建：所有告警规则、大盘视图，都要基于PolarDB-X的新指标体系重写。

• 许可与服务成本：PolarDB-X有开源版（Apache 2.0）和商业版。开源版功能完整，但缺乏官方SLA保障和技术支持。商业版则提供7x24小时专家支持、定制化补丁、专属运维工具。我们选择了商业版，因为核心交易链路不能赌。这笔费用，占到我们整个数据库年度预算的35%。但换来的是，当GTM出现罕见的xid冲突时，阿里云工程师能在30分钟内给出根因分析和临时规避方案，而不是我们自己在源码里大海捞针。

3. 核心细节解析：PolarDB-X的“心脏”与“神经”如何协同工作

理解PolarDB-X，不能只停留在“它是个分布式数据库”的层面。必须拆开它的“心脏”（GTM）和“神经”（CN-DN通信协议），看看数据和指令是如何在它们之间流动的。只有这样，你才能预判，当你的业务流量发生变化时，系统内部会发生什么。

3.1 GTM：不是简单的“时间服务器”，而是分布式事务的“大脑”

GTM（Global Transaction Manager）常被简化为“全局时间戳生成器”，这是巨大的误解。它实际上是PolarDB-X分布式事务的仲裁中心和状态中心。它的核心职责有三个：生成全局唯一且单调递增的事务ID（XID）、管理事务的提交/回滚状态、协调跨DN的两阶段提交（2PC）。

• XID生成机制：GTM并不只是发一个递增数字。它采用一种混合逻辑时钟（Hybrid Logical Clock, HLC）算法，将物理时间戳（毫秒级）和逻辑计数器（counter）组合起来。这样生成的XID，既保证了全局唯一和单调递增，又蕴含了时间信息。这个设计至关重要。当CN收到一个BEGIN请求时，它会向GTM申请一个XID；当执行COMMIT时，CN再次向GTM发起请求，GTM会记录下这个XID的状态为“COMMITTING”，然后向所有参与的DN发送PREPARE指令。DN执行本地事务后，回复PREPARE OK，GTM再统一发送COMMIT指令。整个过程，GTM是唯一的决策者。如果GTM宕机，所有新的分布式事务都会被阻塞，已有的事务会进入“悬挂”状态，直到GTM恢复。因此，GTM的高可用，是PolarDB-X稳定性的生命线。我们部署时，GTM必须是3节点集群，且跨可用区部署，任何一个节点故障，都不影响服务。

• 2PC的“软肋”：两阶段提交是强一致性的基石，但也是性能的瓶颈。在第二阶段（Commit Phase），GTM需要等待所有DN的确认。如果某个DN因为网络抖动或自身负载过高，迟迟不回复，GTM就会一直等待，导致整个事务挂起。PolarDB-X对此做了优化，引入了“超时回滚”机制：GTM会为每个PREPARE设置一个超时时间（默认30秒），超时后自动向所有DN发送ROLLBACK指令。但这带来了新的问题：如果那个“慢”的DN其实已经完成了PREPARE，只是回复晚了，那么GTM的ROLLBACK指令就会把它已准备好的事务给回滚掉，造成数据不一致。这就是所谓的“脑裂”风险。我们的应对策略是，在应用层对关键事务增加幂等性校验，并在GTM配置中，将gtm_2pc_timeout从30秒提高到120秒，以容忍更大的网络抖动，同时加强DN的监控，确保其健康度。

3.2 CN-DN通信：不是“转发”，而是“智能路由与协同计算”

CN（Compute Node）常被看作一个“SQL网关”，它接收SQL，解析，然后把任务分发给DN（Data Node）。但这种理解过于静态。CN实际上是一个分布式查询优化器和执行协调器。它的工作流程，决定了PolarDB-X的性能天花板。

• 查询生命周期：一条SQL进入CN后，会经历五个阶段：

  1. Parse & Validate：语法解析，权限校验。
  2. Logical Plan Generation：生成逻辑执行计划，识别Sharding Key，判断是否能路由到单个DN。
  3. Physical Plan Generation：生成物理执行计划。这是最关键的一步。CN会根据统计信息（ANALYZE TABLE收集的）、当前DN的负载、网络拓扑，决定是走“单DN执行”、“广播执行”（Broadcast Join）还是“分布式执行”（Distributed Join）。比如，一个JOIN操作，如果小表（< 1000行）可以被CN缓存，CN就会选择广播执行，把小表数据发给所有DN，让DN在本地完成JOIN，再把结果汇总。这比让DN各自扫描大表再汇总，效率高出数倍。
  4. Execution：CN将物理计划下发给DN，并监控执行过程。对于聚合查询（GROUP BY,SUM），CN会下发PARTIAL聚合指令，DN先做局部聚合，再把中间结果发给CN，CN做最终聚合。这大幅减少了网络传输的数据量。
  5. Result Assembly & Return：CN组装最终结果，返回给客户端。

• 统计信息的重要性：CN的物理计划生成，极度依赖准确的统计信息。PolarDB-X的ANALYZE TABLE命令，会采样数据，收集列的基数（Cardinality）、直方图（Histogram）等信息。如果统计信息过期，CN就会做出错误的执行计划。我们曾遇到一个案例：一张订单表，status字段有5个枚举值（pending,paid,shipped,delivered,cancelled），其中pending占比95%。但ANALYZE后，CN误判pending只占20%，于是为一个WHERE status = 'pending'的查询选择了全表扫描，而不是走索引。解决方案是，将ANALYZE频率从默认的7天，改为每天凌晨业务低峰期自动执行，并在每次大促前手动触发一次。

3.3 GSI（全局二级索引）：一把双刃剑，用好了是加速器，用错了是定时炸弹

GSI是PolarDB-X解决“非分片键查询”问题的核心方案。比如，订单表以order_id为分片键，但业务经常需要按user_id查询订单。没有GSI，就得扫所有DN，性能极差。有了GSI，就可以为user_id建一个全局索引，查询时CN能根据GSI快速定位到目标DN。

• GSI的构建原理：GSI本身也是一张独立的表，它存储的是(索引列值, 主键值)的映射关系。当向主表插入一行数据时，PolarDB-X会异步地向GSI表插入一条对应的索引记录。这个“异步”是关键。它意味着GSI的更新，和主表的更新，不是原子的。在GSI构建完成前，按GSI列的查询，可能查不到最新数据，或者查到旧数据。PolarDB-X通过一个GSI_SYNC_DELAY参数来控制这个延迟，默认是100ms。这意味着，从主表写入到GSI可查，最多有100ms的窗口期。对于实时性要求极高的场景（如支付结果通知），这100ms可能是致命的。

• 写放大的真相：GSI最大的代价是写放大。每向主表写入1行，PolarDB-X至少要向GSI表写入1行（如果一个表有3个GSI，那就是1:3的写放大）。更严重的是，GSI的写入是串行的，因为要保证索引的一致性。我们一个业务表，有2个GSI，日均写入1000万行，结果GSI的写入QPS成了整个集群的瓶颈，DN的IO util长期在90%以上。最终解决方案是，砍掉了1个非核心的GSI，并将另一个GSI的sync_mode从ASYNC改为SYNC（牺牲一点写入性能，换取强一致性），同时将GSI表单独部署在更高规格的SSD实例上。

4. 实操过程：从零开始搭建一个高可用PolarDB-X集群的完整步骤

纸上谈兵终觉浅，绝知此事要躬行。下面是我们为一家电商平台搭建生产级PolarDB-X集群的完整实操记录。所有步骤、配置、参数，都经过了线上验证。

4.1 环境准备与资源规划：别让硬件成为第一道坎

我们选择了阿里云的PolarDB-X商业版，版本3.0.1。集群规模：3个CN节点，6个DN节点（3主3从），3个GTM节点。所有节点均部署在同一个VPC内，跨3个可用区（AZ），确保高可用。

• 节点规格选择：

  • CN节点：8核32GB内存。CN是计算密集型，内存主要用于SQL解析、执行计划缓存、结果集暂存。我们发现，当CN内存小于24GB时，复杂查询的执行计划缓存命中率会急剧下降，导致重复解析开销增大。
  • DN节点：16核64GB内存 + 2TB SSD云盘。DN是IO密集型，内存用于InnoDB Buffer Pool，云盘IOPS必须达到10000以上。我们特意选择了“ESSD PL1”云盘，而非通用型SSD，因为PL1的IOPS和吞吐量更稳定，能应对大促期间的突发流量。
  • GTM节点：4核16GB内存。GTM是轻量级，但对网络延迟极其敏感，必须部署在低延迟网络环境中。

• 网络与安全组：

  • 所有节点间必须开通内网互通，端口开放：CN的8527（SQL端口）、8528（管理端口）；DN的3306；GTM的8529。
  • 安全组规则必须精确到IP段，禁止0.0.0.0/0的开放。我们为CN节点单独设置了一个安全组，只允许应用服务器所在的安全组访问8527端口。

4.2 集群初始化与基础配置：让系统“活”起来

使用阿里云控制台，一键创建集群。创建完成后，第一步是初始化。

• 初始化脚本：

# 登录到任意一个CN节点 mysql -h cn-host -P 8527 -u root -p # 创建业务数据库 CREATE DATABASE IF NOT EXISTS shop_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 创建分片规则（以orders表为例） CREATE SHARDING TABLE orders ( order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(10,2), create_time DATETIME, PRIMARY KEY (order_id) ) SHARDING BY HASH(user_id) NODES ('dn0','dn1','dn2','dn3','dn4','dn5'); # 为user_id创建GSI CREATE GLOBAL INDEX idx_user_id ON orders(user_id) COVERING (order_id, amount, create_time);

注意：SHARDING BY HASH(user_id)这里我们没有用order_id，因为业务查询80%是按user_id，让数据按user_id分布，能最大化利用GSI。NODES指定了6个DN节点，确保数据均匀分布。

• 关键参数调优（CN配置）： 在CN的config.cn文件中，我们修改了以下参数：

  # 提高连接数，应对高并发 max_connections = 2000 # 增加查询超时，避免慢查询拖垮CN wait_timeout = 28800 interactive_timeout = 28800 # 启用慢查询日志，并设置阈值 slow_query_log = ON long_query_time = 1.0 # 关键！开启分布式执行计划的详细日志，用于性能分析 log_distributed_plan = ON

• 关键参数调优（DN配置）： 在DN的my.cnf文件中，我们重点调整了InnoDB参数：

  # Buffer Pool大小设为物理内存的70% innodb_buffer_pool_size = 42G # 启用自适应哈希索引，加速热点数据访问 innodb_adaptive_hash_index = ON # 调整日志刷盘策略，平衡性能与安全性 innodb_flush_log_at_trx_commit = 1 innodb_log_file_size = 2G

4.3 数据迁移与SQL治理：让老业务“无缝”接入新心脏

我们采用了“双写+校验+切换”的渐进式迁移方案。

• 双写阶段： 应用层改造，所有写操作（INSERT/UPDATE/DELETE）同时写入MySQL和PolarDB-X。我们封装了一个DualWriteService，它保证两个库的写入是“尽力而为”，并记录失败日志。读操作仍走MySQL，确保业务零感知。

• 数据一致性校验： 开发了一个校验工具，每天凌晨扫描MySQL和PolarDB-X的订单表，对比COUNT(*)、SUM(amount)、以及随机抽样1000条记录的MD5值。校验脚本如下：

  -- MySQL端 SELECT MD5(CONCAT(order_id, user_id, amount, create_time)) AS hash FROM orders WHERE create_time > '2023-01-01' ORDER BY order_id LIMIT 1000; -- PolarDB-X端（注意：PolarDB-X的MD5函数名相同） SELECT MD5(CONCAT(order_id, user_id, amount, create_time)) AS hash FROM orders WHERE create_time > '2023-01-01' ORDER BY order_id LIMIT 1000;

  工具会自动比对两组hash，发现差异立即告警。

• SQL治理清单： 在双写期间，我们同步进行了SQL治理，这是迁移成功与否的分水岭：

  1. 禁用SELECT *：强制要求所有查询明确列出所需字段，减少网络传输和CN内存消耗。
  2. 重写ORDER BY ... LIMIT：将SELECT * FROM orders WHERE user_id = ? ORDER BY create_time DESC LIMIT 20，改为基于order_id的游标分页：SELECT * FROM orders WHERE user_id = ? AND order_id < ? ORDER BY order_id DESC LIMIT 20。
  3. 拆分大事务：将一个包含1000次INSERT的事务，拆分为10个100次的小事务，降低GTM的压力。
  4. 添加/*+TDDL:node('dn0')*/Hint：对于确定只访问单个DN的查询，强制路由，避免CN的解析开销。

4.4 压测与灰度发布：用真实流量检验系统的韧性

我们使用JMeter模拟了三种典型流量：

• 峰值流量：模拟大促期间的瞬时QPS 5000，持续10分钟。

• 长尾流量：模拟日常的平稳QPS 1000，持续24小时。

• 混合流量：70%单点查询 + 20%范围查询 + 10%跨分片JOIN。

• 压测结果与调优：

  • 首轮压测：峰值QPS 5000时，polarx_cn_query_latency_ms_bucket{le="100"}达标率仅65%，大量请求超时。分析发现，CN的CPU使用率已达95%，瓶颈在SQL解析。解决方案：启用CN的query_cache，并将query_cache_size从默认的0调整为256MB。
  • 第二轮压测：长尾流量下，polarx_dn_replica_lag_seconds在第12小时开始缓慢爬升，最高达30秒。原因是DN的innodb_log_file_size过小，导致日志刷盘频繁。解决方案：将innodb_log_file_size从1G提升至2G，并重启DN。
  • 第三轮压测（混合流量）：跨分片JOIN的平均耗时120ms，超出预期。解决方案：将小表（users）的副本数从1提升到3，并在CN配置中，将broadcast_join_threshold从1000提升到5000，强制CN采用广播JOIN策略。

• 灰度发布策略：

  1. 第一阶段（1%流量）：只切1%的订单创建流量，监控GTM的txn_commit_duration和CN的query_latency。
  2. 第二阶段（10%流量）：增加订单查询流量，重点监控GSI的sync_delay和replica_lag。
  3. 第三阶段（50%流量）：全量订单读写，此时开启所有监控告警，准备应急预案。
  4. 第四阶段（100%流量）：观察72小时，确认所有核心指标稳定后，正式下线MySQL。

5. 常见问题与排查技巧实录：那些深夜救火时学到的血泪经验

再完美的方案，也会在真实世界里遇到意想不到的问题。以下是我们在生产环境中，总结出的最典型的5个问题，以及我们摸索出的、最有效的排查路径。

5.1 问题一：CN CPU飙升至100%，但SHOW PROCESSLIST里看不到慢SQL

现象：监控告警，CN节点CPU持续100%超过5分钟，但登录CN执行SHOW PROCESSLIST，所有连接状态都是Sleep，没有Query状态的长连接。

排查路径：

1. 检查CN日志：tail -f /path/to/cn/log/error.log，搜索关键词OutOfMemoryError或GC overhead limit exceeded。我们发现大量Full GC日志，说明CN内存不足。
2. 分析JVM堆内存：使用jstat -gc <pid>，发现OldGen使用率长期95%以上，YGC次数极少，FGC频繁。证实是老年代内存泄漏。
3. 定位泄漏源：使用jmap -histo <pid> | head -20，发现com.alibaba.druid.pool.DruidDataSource对象数量异常多，达到数万个。原因是我们应用层配置了过多的Druid数据源，每个数据源都持有一个CN连接池，而CN连接池的元数据对象在JVM中累积，最终撑爆老年代。
4. 解决方案：应用层合并数据源，将原本的5个Druid数据源，合并为1个，并调整maxActive为50。同时，在CN配置中，将cn_heap_size从默认的4G提升到8G。

5.2 问题二：GSI查询结果“丢失”，明明刚插入的数据查不到

现象：应用向PolarDB-X插入一条订单记录，立即按user_id查询，返回空结果。等待1-2秒后，再查，数据就出现了。

排查路径：

1. 确认GSI状态：执行SHOW GLOBAL INDEXES FROM shop_db.orders;，检查STATUS字段是否为ACTIVE。如果是BUILDING，说明GSI还在构建中。
2. 检查GSI同步延迟：执行`SELECT * FROM