无主键大表用mysqldump备份极易卡死或导出不一致，因--single-transaction无法保证MVCC快照一致性，且无法分页导出；应改用SELECT...INTO OUTFILE分块导出或XtraBackup物理备份。
直接用 mysqldump 备份无主键大表，极大概率卡死或导出不一致——因为缺乏主键时 --single-transaction 无法保证快照一致性，--quick 也难缓解内存和锁竞争问题。必须换策略。
为什么无主键表会让 mysqldump 失效
无主键的 InnoDB 表在启用 --single-transaction 时，MySQL 无法构造可靠的 MVCC 快照；事务内多次读可能看到不同版本数据，导致导出内容逻辑错乱。同时，没有主键意味着无法分批次 ORDER BY + LIMIT 导出，--where 条件也难写得既高效又不漏数据。
- 现象：备份中途连接超时、
mysqldump进程长时间卡在Sending data状态、恢复后发现部分记录缺失或重复 - 根本原因：InnoDB 在无主键时会隐式生成
ROW_ID，但该值不可见、不可排序、不保证单调递增，无法作为分片依据 - 影响范围：只要表结构里没定义
PRIMARY KEY或NOT NULL UNIQUE索引，就属于此类风险表
用 SELECT ... INTO OUTFILE 分块导出（推荐）
绕过 mysqldump 的事务层，直接走 SQL 查询导出，可控性强。前提是目标表有某个能支撑分页的字段（如时间戳、自增伪ID、业务单号），且该字段有索引。
- 先确认可分片字段是否可用：
SHOW INDEX FROM your_table WHERE Key_name = 'your_index'; - 导出第一块（按时间切片最稳妥）：
SELECT * FROM your_table WHERE create_time >= '2020-01-01' AND create_time - 注意：
INTO OUTFILE路径必须是 MySQL 服务端本地路径，且 MySQL 用户需有FILE权限；导出文件不包含建表语句，需单独用SHOW CREATE TABLE保存结构 - 若连时间字段都没有，可尝试用
SELECT MIN(id), MAX(id) FROM your_table;估范围，再配合WHERE id BETWEEN x AND y分段——但要接受少量空块或边界重叠
恢复时避免主键冲突与重复导入
无主键表恢复后无法靠唯一约束防重，一旦重复执行导入脚本，数据就会翻倍。必须从流程上杜绝。
- 恢复前清空目标表只能用
TRUNCATE TABLE（比DELETE快，且重置隐式ROW_ID计数器），不能用DROP TABLE+CREATE，否则新表的ROW_ID会从头开始，跟原数据物理顺序不一致 - 导入 CSV 用
LOAD DATA INFILE，不是mysql命令管道：LOAD DATA INFILE '/backup/your_table_2020.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n'; - 关键检查点：恢复完立刻执行
SELECT COUNT(*)对比源表行数，并抽样SELECT * FROM your_table ORDER BY create_time DESC LIMIT 5验证最新数据是否完整
真正海量（>1TB）时考虑 XtraBackup + 过滤恢复
当单表超过几百 GB，连 SELECT ... INTO OUTFILE 都变慢且占用大量 buffer pool 时，物理备份反而更稳。
- 用
xtrabackup做全量备份：xtrabackup --backup --user=root --password=xxx --target-dir=/backup/xtra_full - 恢复时不全量还原，而是用
innobackupex --export提取单表空间，再ALTER TABLE ... DISCARD TABLESPACE+IMPORT TABLESPACE导入——但要求原表使用独立表空间（innodb_file_per_table=ON） - 风险点：XtraBackup 恢复后表仍是无主键状态，且
ROW_ID会重排；如果业务后续要加主键，务必先ALTER TABLE ADD COLUMN id BIGINT AUTO_INCREMENT FIRST, ADD PRIMARY KEY (id);，否则ADD PRIMARY KEY会失败
无主键表的备份本质是“妥协的艺术”：没有银弹，只有根据字段特征选分片维度、靠人工校验兜底、在物理与逻辑路径间权衡IO和可控性。最容易被忽略的是恢复后的行数比对——别只信日志里“Query OK”，COUNT(*) 才算数。
