MySQL 单库数据如何导出为分布式系统可接入格式
直接 mysqldump 出来的 SQL 文件，在 TiDB、OceanBase 或 StarRocks 等分布式系统中大概率执行失败——不是语法不兼容，就是主键/索引/自增行为差异导致导入中断。迁移第一步不是“往哪迁”，而是“导成什么样”。
mysqldump --compatible=postgresql这类参数基本没用，分布式系统并不认 PostgreSQL 兼容模式，反而可能破坏 MySQL 原有语义 真正要关的是
--skip-extended-insert（单行 INSERT）和
--skip-triggers --skip-routines --skip-events（存储过程、事件、触发器几乎全不兼容，先剥离） 导出前手动检查：
SHOW CREATE TABLE中是否含
FULLTEXT、
SPATIAL、
ENUM、
SET类型——TiDB 7.1+ 支持 ENUM，但 StarRocks 完全不支持，得提前转成
VARCHAR时间类型注意：
TIMESTAMP在跨时区写入时行为不一致，建议统一转成
DATETIME并在应用层补时区逻辑
MySQL 主键和索引怎么适配分布式系统的分片逻辑
单机 MySQL 的
PRIMARY KEY在分布式系统里往往不能直接当分片键（shard key），否则容易引发热点写入或范围查询失效。 TiDB 推荐用
SHARD_ROW_ID_BITS+ 复合主键，比如原表是
id BIGINT PRIMARY KEY，应改造成
(tenant_id, id)，其中
tenant_id作为第一列参与分片 StarRocks 要求
DISTRIBUTED BY HASH(...)列必须是非空、不可变，且最好高基数；若原表只有自增
id，需加一列业务标识（如
region_code）并联合分片 所有
UNIQUE KEY必须包含分片列，否则建表报错：
ERROR 1105 (HY000): UNIQUE KEY must contain all columns in DISTRIBUTED BYMySQL 的
INDEX在分布式系统中不自动生效，StarRocks 需显式建
ROLLUP或
MATERIALIZED VIEW，TiDB 的二级索引默认异步构建，查旧数据可能延迟秒级
增量同步用什么工具能绕过 binlog 解析陷阱
用 canal / maxwell 直接解析 MySQL binlog 接入 Kafka，再由 Flink CDC 消费——这条路看着标准，实际卡在三处：GTID 不一致、DDL 同步丢失、大事务拆分后顺序错乱。
MySQL 开启binlog_row_image=FULL是硬性要求，否则 StarRocks 的 Upsert 无法识别变更前后的完整字段 避免使用
canal.admin的自动 DDL 同步，它会把
ALTER TABLE ADD COLUMN拆成两步（先加空列再填值），而分布式系统要求 schema 变更原子化；建议 DDL 单独走运维通道人工审核 Flink CDC 的
scan.startup.mode设为
latest-offset仅适合纯增量场景；混合迁移必须用
initial，但要注意 checkpoint 间隔设太长会导致全量阶段 OOM 真实线上曾因 MySQL
max_allowed_packet设为 4MB，导致一个 6MB 的 binlog event 被截断，Flink 消费端报
InvalidPacketLengthException却无明确提示——这个值必须大于最大单条记录的二进制长度
校验一致性时为什么 count(*) 和 checksum 都不准
分布式系统里
COUNT(*)不是强一致操作，
SELECT MD5(GROUP_CONCAT(...))这类校验在分片环境下结果不可复现。 TiDB 的
COUNT(*)默认走 TiKV Coprocessor，但若涉及多 Region 扫描，返回值是最终一致而非实时一致；校验必须加
AS OF TIMESTAMP回溯到迁移切流前的 TSO 不要用
pt-table-checksum对比 MySQL 和 TiDB，它依赖
REPLACE INTO和
INSERT ... ON DUPLICATE KEY UPDATE，而 TiDB 的悲观锁机制会让这类语句超时或死锁 推荐按业务主键分段校验：比如每 10 万行算一次
MD5(SUM(UNHEX(CONV(SUBSTR(MD5(id),1,16),16,10))))，既避开了字符串拼接长度限制，又能在分片间独立计算后汇总比对 最容易被忽略的是时区和字符集隐式转换：MySQL 客户端设
utf8mb4_unicode_ci，TiDB 设
utf8mb4_bin，同样字符串
'café'的哈希值不同——校验前必须统一
collation_connection
