会丢数据，因mysqldump只识别物理库表，无法处理分库分表的逻辑映射，直接导出逻辑库会导致遗漏或空库。
分库分表后，mysqldump 直接导出会丢数据吗？
会，而且很常见。因为 mysqldump 默认不理解逻辑库/表和物理库/表的映射关系，它只认 MySQL 实例里真实存在的库名和表名。如果你用 ShardingSphere 或 MyCat 做了分库分表，逻辑表 t_order 可能实际落在 ds_0.t_order_0、ds_1.t_order_1 等多个物理位置，mysqldump -B order_db 只会 dump 出一个空库或部分碎片，根本不是全量。
- 不要直接对中间件暴露的逻辑库执行
mysqldump - 如果必须用
mysqldump，得先连到每个真实 MySQL 实例，分别 dump 物理库（比如ds_0、ds_1），再手动合并或重写路由元数据 - 更稳妥的做法是绕过中间件，直连后端 MySQL 节点，用
SELECT ... INTO OUTFILE导出文本，避免字符集和大字段截断问题
ShardingSphere-JDBC 迁移时，dataSource 配置写错会导致连接池反复创建
这是线上高频问题：迁移脚本里把 driver-class-name 写成 com.mysql.cj.jdbc.Driver，但实际连接的是 ShardingSphere 的 JDBC 数据源代理类 org.apache.shardingsphere.driver.jdbc.core.datasource.ShardingSphereDataSource。结果 Spring Boot 启动时发现类型不匹配，不断尝试重建 dataSource，日志刷屏 Failed to obtain JDBC Connection。
- 迁移工具（如 DataX、Canal）或自研脚本中，JDBC URL 必须指向真实 MySQL 实例，不是 ShardingSphere 的逻辑地址
- 若需复用 ShardingSphere 的分片规则做读取，应调用其
ShardingSphereDataSource的getConnection()，但要注意该连接不支持跨库事务，且getMetaData()返回的是逻辑视图，容易误判表结构 - 检查
application.yml里是否混用了spring.datasource.<em></em>和spring.shardingsphere.datasource.两套配置，后者才是中间件生效的入口
用 DataX 迁移分库分表数据，mysqlreader 插件怎么写才能不漏片
mysqlreader 默认一次只能读一个库的一张表。如果物理表分散在 8 个库、每个库 4 张分表，硬写 32 个 job 配置不仅维护成本高，还容易因并发过高打爆 MySQL。
- 把所有物理表路径列全，用
connection数组一次性声明，例如："connection": [{ "jdbcUrl": ["jdbc:mysql://host1:3306/ds_0?useSSL=false"], "table": ["t_order_0", "t_order_1"] }, { "jdbcUrl": ["jdbc:mysql://host2:3306/ds_1?useSSL=false"], "table": ["t_order_0", "t_order_1"] }] -
column必须显式写出，不能用<em></em>—— 分表间字段顺序或默认值可能不一致，容易导致列错位 - 如果目标库也分库分表，
mysqlwriter的writeMode推荐设为insert，别用replace，否则唯一键冲突会静默跳过，数据就丢了
Canal 订阅 binlog 做增量迁移，destination 配置错一个字符就收不到事件
destination 在 Canal 里不是随便起的名字，它必须和 instance.properties 文件里定义的实例名完全一致，且大小写敏感。比如配置文件写的是 example，而客户端连的是 Example，Canal Server 日志只会打印 no available destination，不会报更具体的错误。
- 先确认 Canal Server 的
conf/example/instance.properties中canal.instance.dbUsername和canal.instance.connectionCharset是否与目标 MySQL 一致（尤其注意 MySQL 8.0 默认utf8mb4） -
canal.instance.filter.regex要写物理库名+物理表名，例如ds_\d+\.t<em>order</em>\d+，不能写逻辑名order_db.t_order - 如果 MySQL 开启了 GTID，Canal 1.1.5 之前版本不兼容，会卡在
running状态但无任何日志输出，必须升级或关闭 GTID
分库分表迁移最麻烦的从来不是工具选型，而是物理拓扑和逻辑规则之间的映射关系——一旦中间件配置、迁移脚本、目标库建表语句三者之间有任意一处没对齐，数据就可能错行、重复或消失，而且这种问题往往在线上跑了一周才被业务侧发现。
