mysqldump导出单表结构冲突的典型表现是报错ERROR 1050或字段顺序/类型不一致，根源在于默认启用--add-drop-table和--create-options；解决方法是加--no-create-info仅导数据，并配合--complete-insert显式指定列名、--skip-foreign-key-checks禁用外键检查、--default-character-set=utf8mb4统一字符集。
mysqldump 导出单表时结构冲突的典型表现
导出单表却报错 error 1050 (42s01): table 'xxx' already exists，或导入后字段顺序/类型与原表不一致——这不是数据问题，是 mysqldump 默认带了 --add-drop-table 和 --create-options，导致导出 sql 包含完整建表语句，而目标库已有同名表（哪怕结构不同）就会冲突。
用 --no-create-info 精准剥离建表语句
只导数据、不导结构，最直接的办法就是关掉建表逻辑：
mysqldump -u root -p --no-create-info database_name table_name > data_only.sql- 该参数会跳过
CREATE TABLE和DROP TABLE语句，只保留INSERT INTO - 注意：必须确保目标库已存在同名表，且字段数量、顺序、类型兼容；否则
INSERT会因列数不匹配或类型转换失败报错 - 若表有自增主键，导出文件里不会带
SET INSERT_METHOD=FIRST，导入时默认走 AUTO_INCREMENT，一般没问题
当字段顺序不一致时，显式指定列名更安全
如果源表和目标表字段顺序不同（比如 ALTER TABLE 调整过顺序），光靠 --no-create-info 还不够，INSERT 语句可能列对不上：
- 加
--complete-insert，让每条INSERT都带列名，例如：INSERT INTO t (id, name, created_at) VALUES (1, 'a', '2024-01-01'); - 这样即使目标表字段顺序不同，也能按名匹配，避免值错位
- 代价是导出文件体积略大，但可读性和安全性明显提升
- 不建议依赖
--skip-extended-insert来“方便调试”——它只是把多行合并改成单行，不解决列名缺失问题
遇到外键约束或字符集差异怎么办
导出后导入失败常卡在两个地方：外键检查和字符集声明：
- 加
--skip-foreign-key-checks，在导出 SQL 开头插入SET FOREIGN_KEY_CHECKS=0;，避免导入时因父表不存在报错 - 如果源库用
utf8mb4_0900_as_cs而目标库是utf8mb4_general_ci，导出时不带--default-character-set可能触发隐式转换；稳妥做法是显式指定：--default-character-set=utf8mb4 - 不要依赖
--compatible=mysql40之类降级参数——它会删掉现代语法（如分区信息），反而增加兼容风险
mysqldump -u root -p --no-create-info --complete-insert --skip-foreign-key-checks --default-character-set=utf8mb4 mydb users > users_data.sql。最容易被忽略的是字段顺序和字符集这两层隐性依赖——没报错不代表数据没错位，导入后务必抽样比对几条记录的字段值。 
