external-locking 是 MySQL 旧版 MyISAM 文件级外部锁机制，现已被弃用；现代 MySQL（5.7+）默认关闭，开启会导致备份卡顿、多实例冲突及 xtrabackup 拒绝备份，应禁用并迁移到 InnoDB。
external-locking 是什么，现在还该开吗
MySQL 的 external-locking 是个老参数，作用是让 MySQL 在 MyISAM 表上配合外部程序（比如 mysqldump、myisamchk）做文件级加锁。但它的实际效果很有限：只对 MyISAM 有效，InnoDB 完全无视；且在多实例或 NFS 环境下反而容易引发死锁或元数据不一致。
现代 MySQL（5.7+）默认关闭它，官方文档也明确标注为「deprecated」。如果你在配置里看到 external-locking = ON，基本可以认定是旧环境迁移遗留，或者误信了某些过时教程。
检查和关闭 external-locking 的实操步骤
确认当前是否启用，最直接的方式是查运行时变量：
SHOW VARIABLES LIKE 'external_locking';
如果返回 ON，说明启用了。关闭它不需要重启服务（前提是没写死在配置文件里），但必须改配置并重启才真正生效：
- 编辑
my.cnf或mysqld.cnf，在[mysqld]段下添加或修改为：external-locking = OFF - 注意：不能写成
skip-external-locking—— 这是 5.6 以前的写法，新版本已不识别，会导致启动失败 - 重启前先用
mysqld --defaults-file=/etc/my.cnf --validate-config验证配置语法
开了 external-locking 会出什么具体问题
不是“可能有问题”，而是已有明确故障模式：
- mysqldump 备份时卡住，日志里反复出现
Waiting for table flush，本质是外部锁等待超时后被强行中断，导致备份不一致 - 同一台机器跑多个 MySQL 实例（比如测试/开发共存），
external-locking = ON会让它们互相干扰，因为底层依赖的是同一个文件系统锁机制 - 使用 Percona XtraBackup 时，若 MySQL 启用了
external-locking，xtrabackup 会主动拒绝备份，并报错External locking is not supported
替代方案：真需要外部协同，该怎么做
如果你的业务逻辑确实依赖“外部程序操作表时不被 MySQL 干扰”（比如定时用 myisamchk 修表），正确做法不是开 external-locking，而是流程控制：
- 停写：先执行
FLUSH TABLES WITH READ LOCK，再操作表文件 - 用
LOCK TABLES ... READ LOCAL允许并发 INSERT（仅 MyISAM），比文件锁更可控 - 迁移到 InnoDB：所有现代场景都应优先选 InnoDB，它的行级锁 + MVCC 天然规避了这类外部锁需求
真正麻烦的从来不是参数开关，而是把 MyISAM 当主力还试图靠 external-locking 解决并发问题——这相当于给自行车装涡轮增压，方向错了。
