mysql单库导出需适配分布式系统：禁用扩展插入与存储过程，转enum/set为varchar，timestamp改datetime；主键需含分片列，索引须显式重建；增量同步应设binlog_row_image=full，避免ddl自动拆分；校验用业务主键分段md5，统一字符集与时区。
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 BY - MySQL 的
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
