external-locking 在现代 MySQL（5.7+）中默认关闭且已被弃用，必须禁用；启用会导致 mysqldump 卡顿、多实例死锁、xtrabackup 拒绝备份，并应迁移到 InnoDB。
external-locking 在现代 MySQL（5.7+）中默认关闭，若你发现它被启用，反而会拖慢单机性能、干扰备份、甚至让 xtrabackup 拒绝工作——直接禁用是正确选择，不是“可选优化”，而是必须清理的过时配置。
确认 external-locking 当前是否启用
别猜，查运行时变量最准：
SHOW VARIABLES LIKE 'external_locking';
如果返回 ON，说明它正开着。注意：这个值只反映当前生效状态，不等于配置文件里写了什么；它可能来自配置文件、启动参数，或旧版本遗留的隐式行为。
在 my.cnf 中正确关闭 external-locking
新版 MySQL 不再识别 skip-external-locking（这是 5.6 以前的写法），硬写会导致服务启动失败。必须用标准布尔写法：
- 编辑
/etc/my.cnf或/etc/mysql/my.cnf，定位到[mysqld]段 - 添加或修改为：
external-locking = OFF（不能写成= off、= false或= 0，MySQL 只认OFF或ON） - 重启前务必验证语法：
mysqld --defaults-file=/etc/my.cnf --validate-config，避免配置错误导致启不来
开了 external-locking 会立刻出哪些具体问题
这不是理论风险，而是已有明确故障链：
-
mysqldump备份卡在Waiting for table flush，超时后中断，备份内容不一致 - 同一台机器跑多个 MySQL 实例时，
external-locking = ON会让它们争抢同一个文件锁，引发死锁或元数据损坏 -
xtrabackup启动时直接报错：External locking is not supported，拒绝执行任何备份 - 哪怕只跑单实例，MyISAM 表在高并发写入下也会因等待外部锁而排队，吞吐下降明显
替代方案比开关参数更重要
真正麻烦的不是怎么关掉 external-locking，而是为什么还在用 MyISAM 并试图靠它解决并发问题。如果你的业务真需要“外部程序操作表时不被 MySQL 干扰”，正确路径是：
- 停写期间用
FLUSH TABLES WITH READ LOCK+ 显式解锁，比文件锁可控得多 - 对 MyISAM 表用
LOCK TABLES ... READ LOCAL允许并发INSERT，比全局外部锁粒度细 - 终极解法：把表引擎迁移到
InnoDB—— 它的行级锁和 MVCC 天然不需要external-locking
留着 external-locking = ON 还想靠它提升性能，就像给算盘装 SSD，方向错了。
