能，但仅限于InnoDB表且导出期间禁止DDL操作；它通过REPEATABLE READ事务获取一致性快照，对MyISAM等非事务引擎无效，混合引擎需改用--lock-all-tables或物理备份。
mysqldump --single-transaction 能否真正保证一致性？
能，但仅限于 InnoDB 表，且前提是导出期间没有 DDL 操作（如 DROP TABLE、ALTER TABLE）。MySQL 8.0 的 --single-transaction 会启动一个 REPEATABLE READ 事务，在事务开始时刻获取一个全局一致性快照 —— 所有已提交的数据可见，未提交的不可见，后续写入也不影响该快照。
常见错误现象：导出后发现某张表数据“少了一部分”，往往是因为该表是 MyISAM 或 Memory 引擎，它们不支持事务，--single-transaction 对其完全无效，导出过程仍可能被并发写入干扰。
- 确认引擎：导出前执行
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'db_name'; - 混合引擎库必须配合
--lock-tables（会锁所有表）或改用物理备份 - DDL 操作会隐式提交当前事务，导致快照失效 —— 导出期间禁止
CREATE INDEX、TRUNCATE等
为什么 --single-transaction + --quick 是标配组合？
--quick 强制 mysqldump 逐行读取结果集，而不是把整张表缓存在客户端内存里。对千万级表来说，不加它极易触发 OOM（Out of Memory），尤其在低配服务器或容器环境下。
性能影响明显：一张 5000 万行的 InnoDB 表，启用 --quick 后内存占用稳定在 ~20MB；关闭后，客户端进程内存可能飙升至 2GB+ 并最终被系统 kill。
-
--quick不影响服务端，只控制客户端 fetch 行为 - 与
--single-transaction无冲突，二者可安全共用 - 若同时用
--where或--tables限定范围，--quick依然必要
导出命令中哪些参数容易被忽略却关键？
实际跑通海量导出，光靠 --single-transaction 和 --quick 远不够。下面这些参数不显眼，但缺一不可：
-
--skip-lock-tables：默认 mysqldump 会对非事务表加 LOCK TABLES，但加锁会阻塞业务写入 —— 对纯 InnoDB 库必须显式跳过 -
--set-gtid-purged=OFF：MySQL 8.0 默认开启 GTID，导出时若不关掉，还原时可能因 GTID 冲突失败（尤其跨实例导入） -
--compress：客户端和服务端之间启用压缩传输，对千兆内网提升有限，但在跨公网或高延迟链路下可减少 30%+ 传输时间 - 导出路径建议用管道直连 gzip：
mysqldump -u root -p --single-transaction --quick db_name | gzip > backup.sql.gz，避免生成巨大临时文件
导出后校验一致性有哪些低成本办法？
导出完成不代表数据可靠。最易被忽略的是字符集和排序规则差异 —— MySQL 8.0 默认 utf8mb4_0900_ai_ci，若目标库仍是 utf8mb4_general_ci，某些 emoji 或特殊字符可能被静默截断或转换。
建议导出后立即做两件事：
- 检查导出文件头是否含
SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;—— 若没有，还原时需手动指定 - 快速抽样校验：从原库和导出 SQL 中各取 100 行主键，用
md5sum或sha256sum对比哈希值（注意去除注释和空格） - 不要依赖
SELECT COUNT(*)：InnoDB 的行数是估算值，可能不准；应查information_schema.tables.table_rows并结合SHOW TABLE STATUS综合判断
事务一致性快照本身很可靠，但落地成文件的过程受 IO、编码、权限、网络等多环节影响 —— 校验不是可选项，而是上线前必走一步。
