--single-transaction实际未生效，大概率因库中存在MyISAM表、混用--lock-all-tables、多库备份含非InnoDB库、权限不足或长事务阻塞，导致自动降级为FLUSH TABLES WITH READ LOCK。
加了 --single-transaction 仍超时，大概率不是参数没起作用，而是它被悄悄绕过了——或者根本没机会生效。
为什么 --single-transaction 实际没执行锁规避
这个参数只对 InnoDB 表生效，且必须全程“不被打断”。但现实中它极易被以下情况强制降级：
- 库中存在任意 MyISAM 表：
--single-transaction会自动失效，mysqldump 回退到FLUSH TABLES WITH READ LOCK全局锁 - 显式混用了
--lock-all-tables或--lock-tables：后者优先级更高，直接覆盖事务模式 - 备份目标是多个数据库（
--all-databases），但其中某个库含非 InnoDB 表：整个备份流程都会降级 - 用户权限不足，无法执行
START TRANSACTION WITH CONSISTENT SNAPSHOT（需 REPEATABLE READ 隔离级 + SELECT 权限）
--single-transaction 卡在 Waiting for table flush 怎么办
这不是网络或磁盘慢，而是 mysqldump 在等一个长事务释放 undo log。此时它已进入事务快照阶段，但无法获取一致起点。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 查活跃事务：
SELECT trx_id, trx_started, trx_state FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started; - 超过 30 秒未提交的事务，基本就是阻塞源；协调业务方提交/回滚，或
KILL对应线程 - 避免在备份窗口内执行
ALTER TABLE、无LIMIT的DELETE或大范围UPDATE -
innodb_lock_wait_timeout建议设为 120，否则默认 50 秒可能中断备份
参数组合错误导致隐性冲突
看似合理的参数叠加，实际互相抵消：
-
--single-transaction和--skip-lock-tables可共存，但--lock-tables=false不等于--skip-lock-tables，后者才真正禁用锁逻辑 -
--compress若服务端未开启have_compression=ON（MySQL 5.7+ 默认开，但某些定制版可能关），会静默忽略，不报错也不压缩 -
--quick必须配--single-transaction使用：前者控制逐行 fetch，后者控制快照起点，缺一不可；否则大表仍可能 OOM 或拖慢 server -
--net_buffer_length=1M和--max_allowed_packet=512M必须显式设置，否则默认值（如 1MB packet）在 TB 级导出中极易触发Lost connection to MySQL server during query
恢复时才发现备份不完整，但超时早已发生
--single-transaction 要求整个 dump 过程在一个事务内完成。一旦中途失败（kill、磁盘满、连接断），生成的 SQL 文件就是截断的——但超时往往发生在写入阶段，你根本看不到错误，只看到备份进程僵死或客户端断连。
- 检查备份文件末尾是否包含
COMMIT;或UNLOCK TABLES;；缺失即不完整 - 不要依赖
ls -l看大小判断成功：部分场景下 mysqldump 会写入空文件或半截头信息 - 对 >50GB 的库，建议分库或分表导出，并校验每张表的
SELECT COUNT(*)行数与备份前一致 - 务必加
--routines --triggers --events，否则存储过程、事件调度器不会被导出，恢复后功能缺失
真正容易被忽略的是：--single-transaction 不是开关，而是一组前提条件的总和。引擎、事务、权限、参数组合、运行时环境——任一环节松动，它就退化。别只看命令里有没有这个词，要看它执行时有没有“站住脚”。
