一致。MySQL的锁机制由存储引擎实现，与操作系统无关；Windows和Linux下SQL加锁范围、等待行为及死锁检测逻辑完全相同，差异仅源于文件系统特性与默认配置。

MySQL 的表级锁和行级锁在 Windows 和 Linux 下行为一致吗？

一致。MySQL 的锁机制（如 InnoDB 的行锁、MyISAM 的表锁）由存储引擎实现，与操作系统无关。Windows 和 Linux 下执行相同 SQL、相同隔离级别、相同事务流程时，加锁范围、等待行为、死锁检测逻辑完全相同。

真正影响锁表现的，是底层文件系统对并发 I/O 的处理方式，以及 MySQL 在不同系统上默认配置的隐性差异。

Windows 默认用 NTFS，Linux 多用 ext4/xfs：这对 MySQL 锁有啥实际影响？

NTFS 和 ext4/xfs 在文件元数据更新、目录遍历、锁粒度上存在差异，会间接影响 MySQL 的锁等待时间或崩溃恢复行为，但不会改变锁语义。常见可观察现象包括：

• flock() 和 fcntl() 系统调用在 Windows 上不可用，MySQL 在 Windows 下改用 CreateFile() + LockFileEx() 实现文件级互斥（如 mysql.pid、ibdata1 打开保护），这部分逻辑与 Linux 完全不同，但对用户 SQL 锁无感知
• NTFS 对小文件（如 .frm 或临时表文件）的目录项更新较慢，在高并发 DROP TABLE 或频繁 CREATE TEMPORARY TABLE 场景下，可能延长“waiting for table metadata lock”状态——这不是 MySQL 表锁本身变慢，而是元数据文件操作被文件系统拖住
• ext4 默认启用 barrier=1，xfs 强制日志同步，而 NTFS 在非 BitLocker 加密卷上对写缓存更激进；若 MySQL 配置了 innodb_flush_log_at_trx_commit=1 且磁盘写缓存开启，Windows 下实际 fsync 延迟可能更高，导致事务提交变慢，进而拉长行锁持有时间

为什么同样的 SQL 在 Windows 上更容易出现 “Lock wait timeout exceeded”？

通常不是锁机制变了，而是以下三个现实因素叠加：

windows-auto

Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。

下载

• Windows 下 MySQL 默认安装包（如 MySQL Installer）常启用 skip-external-locking，但该选项在 Windows 下无实际作用（因为本就不支持 fcntl 锁），容易让人误以为“外部锁已关闭”，实则内部仍依赖文件句柄独占，排查时易混淆
• Windows Defender 或第三方杀毒软件会扫描 ib_logfile*、ibdata1 等大文件，造成 I/O 毛刺，使 innodb_thread_concurrency 等控制失效，间接放大锁等待
• Windows 的默认页面文件（pagefile.sys）和 MySQL 的 innodb_buffer_pool_size 若总和接近物理内存，易触发系统级内存压缩或分页，导致线程调度延迟升高，原本 50ms 的锁等待被拉长到 500ms+，超过 innodb_lock_wait_timeout（默认 50）就报错

生产环境必须检查的跨平台配置项

这些配置在 Windows 和 Linux 下默认值不同，直接影响锁相关行为：

• innodb_flush_method：Linux 常用 O_DIRECT，Windows 只支持 async_unbuffered（即绕过系统缓存但不绕过磁盘缓存），若未显式设置，Windows 下可能意外走缓冲 I/O，加剧锁等待期间的脏页刷盘压力
• table_open_cache 和 table_definition_cache：Windows 下文件句柄限制更紧（默认约 2048），若这两个值设得过高，会导致 Cannot open table 错误，进而卡在“waiting for table flush”状态，看起来像锁问题
• innodb_log_file_size：Windows 下大日志文件（如 >1GB）在崩溃恢复时重放更慢，恢复期间所有 DML 被阻塞，表现为“全局锁等待”，而 Linux 下 xfs 日志重放效率通常更高

最常被忽略的是：Windows 下 MySQL 服务默认以 Local System 账户运行，对 NTFS 权限继承敏感；若手动移动了 datadir 到非系统盘，未重置 ACL，可能导致 ibtmp1 创建失败，临时表锁无法释放，最终拖垮整个实例。