skip-external-locking设为on可彻底跳过flock()系统调用，消除内核态切换开销；innodb自身锁机制已保障一致性，外部文件锁冗余，故on是安全且有效的性能优化选择。
直接关掉 skip-external-locking，设为 ON（即启用跳过外部锁）——这是唯一有效且安全的做法。
为什么必须设为 ON 才能降低系统调用开销
MySQL 默认 skip-external-locking=OFF，意味着每次打开表文件（如 .ibd、.frm）都会调用 flock() 获取文件级独占锁。这个动作发生在内核态，每次都要上下文切换，高并发下积少成多。而 InnoDB 本身已通过行锁、意向锁、事务日志等机制保证数据一致性，外部文件锁纯属冗余。
设为 ON 后，mysql_file_lock() 函数直接返回 0，跳过所有 flock() 调用 —— 不是“减少”，而是彻底移除该路径的系统调用。
- 该参数对 InnoDB 完全无副作用：InnoDB 不依赖外部锁做并发控制
- MyISAM 场景下需谨慎：若存在外部程序（如老式备份脚本）直接读写
.MYD/.MYI文件，则开启后可能引发数据损坏 - 绝大多数现代部署（Docker/K8s/云主机 + 应用层统一访问）已无外部程序直触数据文件，可放心启用
如何确认当前值并安全修改
先查当前状态：
SELECT @@skip_external_locking;
返回 0 表示未启用（即默认），1 表示已跳过外部锁。
修改方式分两类：
- 动态生效（仅限当前会话，不推荐用于生产）：
SET GLOBAL skip_external_locking = ON; - 持久化修改（推荐）：在
my.cnf的[mysqld]段添加一行：skip-external-locking = ON，然后重启 MySQL
注意：skip-external-locking 是只读变量，无法通过 SET SESSION 修改；SET GLOBAL 在某些版本（如 MySQL 8.0.30+）可能被禁用，必须走配置文件。
容易被忽略的兼容性陷阱
这个参数名带连字符，但变量名是下划线：@@skip_external_locking，不是 @@skip-external-locking —— 写错会报 Unknown system variable 错误。
某些云厂商 RDS（如阿里云早期 5.6 版本）默认强制关闭该参数且不允许修改，需确认控制台是否开放配置项；AWS RDS 允许在参数组中设置，但需注意参数组需绑定到实例并重启才生效。
真正要警惕的不是这个参数本身，而是它暴露的底层假设：如果你的运维流程仍依赖直接 cp/rsync 数据文件做备份，那关掉外部锁只是把风险从“性能瓶颈”转移到“静默数据损坏” —— 这类场景应优先迁移到 mysqldump、mydumper 或 Percona XtraBackup。
