mysqldump默认执行FLUSH TABLES WITH READ LOCK（FTWRL）施加全局读锁，阻塞所有写操作；仅--single-transaction可绕过，但仅限InnoDB且需配合--quick、--skip-lock-tables等参数。
mysqldump 默认就会锁表，不是你配错了，是它本来就这样
不加任何参数执行 mysqldump -u root -p db_name，它会自动对所有表执行 FLUSH TABLES WITH READ LOCK（FTWRL），这是全局读锁，所有写操作（INSERT/UPDATE/DELETE）立刻阻塞。哪怕只备份一张表，只要没显式关锁，它就锁整个库——这不是 bug，是默认安全策略。
--single-transaction 是唯一能真正绕过 FTWRL 的参数，但只对 InnoDB 有效
它靠 InnoDB 的 MVCC 快照机制，在事务中读取一致数据，全程不触发 FTWRL。但以下任一情况都会让它失效：
-
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db'返回任意一行engine是MyISAM、MEMORY或CSV—— mysqldump 会静默退化为 FTWRL，不报错也不警告 - 命令里同时出现
--lock-tables或--lock-all-tables（哪怕设成false）——它们与--single-transaction互斥，一加就覆盖 - MySQL 版本低于 5.6，或未开启
autocommit=1（快照无法正确建立）
执行时怎么确认它真没锁表？别信命令行写了就管用
备份运行中，立刻开另一个终端查：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SHOW PROCESSLIST;—— 如果看到 State 是Waiting for global read lock或Locked，且 Info 含FLUSH TABLES WITH READ LOCK，说明已锁表 -
SELECT trx_id, trx_started, trx_state FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started LIMIT 5;—— 若trx_started超过 30 秒，--single-transaction会卡在等 undo log 清理，表现为Waiting for table flush，这不是锁表，是快照建不起来
必须搭配的三个参数：--quick、--skip-lock-tables、--routines
光有 --single-transaction 不够，缺一不可：
-
--quick（或-q）：强制逐行读取，避免大表把整张表缓存进内存，否则可能触发max_allowed_packet错误或 OOM -
--skip-lock-tables：显式关闭锁逻辑，防止脚本或环境变量里残留--lock-tables导致覆盖 -
--routines：否则存储过程和函数不会导出，恢复后功能缺失；同理--triggers也要加
最终安全命令长这样：mysqldump -u root -p --single-transaction --quick --skip-lock-tables --routines --triggers db_name > backup.sql
混合引擎库没法靠参数解决——MyISAM 表的存在本身就意味着无法无锁全量备份，要么转引擎，要么接受锁表，或者换 XtraBackup/LVM 快照。
