mysql如何迁移数据到分布式系统_mysql分布式架构迁移

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