技术博客
MySQL 的 InnoDB 默认用行锁，但很多情况下会 silently 升级成表锁——最常见的是在 WHERE 条件中使用了非索引字段或函数。比如执行 UPDATE user SET status=1 WHERE CONCAT(name, ”) = ‘alice’，即使 name 有索引，CONCAT 也会让优化器放弃索引，触发全表扫描+全表加锁。
os.RemoveAll 确实递归删除，但它的行为和你手动 rm -rf 不完全一致：它不跳过只读文件，遇到权限不足或打开中的文件会直接报错退出，不会“尽力删完剩下”。测试时如果 mock 不够细，很容易漏掉这类失败路径。
是的，但只限于 log buffer 刷到 OS cache 并调用 fsync() 写入磁盘日志文件（ib_logfile0 等）——不是刷数据页，也不是刷 binlog。它不保证操作系统或磁盘固件没缓存，也不绕过存储栈的写缓存（比如 RAID 卡、NVMe 的 write cache）。如果磁盘掉电且未禁用写缓存，仍可能丢最后几条事务。
会，但只在特定条件下。MySQL 的行锁（如 InnoDB 的 RECORD LOCK）和表锁（如 LOCK TABLES … WRITE 或 FLUSH TABLES WITH READ LOCK）属于不同层级的锁机制，它们不共享锁管理器，因此互斥行为不是“自动协调”的，而是靠 MySQL Server 层统一仲裁——一旦某线程持有表级写锁，所有试图获取该表任何行锁的事务都会被阻塞；反之，若已有事务在该表上持有了未提交的行锁（比如正在执行 UPDATE），再执行 LOCK TABLES t1 WRITE 也会被挂起，直到行锁释放。
这个参数不是越大越好，也不是越小越稳。它本质是把整个 innodb_buffer_pool_size 拆成 N 个独立的子池，每个子池有自己的 LRU 链表和 mutex 锁。设得太大，锁虽然分散了，但每个子池太小，缓存命中率暴跌；设得太小（比如 1），所有线程抢同一把锁，高并发下明显卡在 buf_pool_mutex 上。
不能直接混搭做主从，尤其是 5.7 作为主库、8.0 作为从库时，大概率会报错 ER_SLAVE_INCIDENT 或复制中断在 GTID_PURGED 初始化阶段。根本原因是 8.0 默认启用 enforce_gtid_consistency=ON 且要求所有事务带 GTID，而 5.7 的部分语句（如非事务性 DML、CREATE TEMPORARY TABLE）在未显式开启 gtid_mode=ON 时无法生成合法 GTID，导致从库拒绝执行。
标准库 sync.Mutex 只作用于单个进程内，多进程同时写同一个文件时完全无效。真正起作用的是系统级的 flock（Linux/macOS）或 LockFileEx（Windows），Go 通过 syscall 或封装好的第三方包调用它们。os.File.Fd() 是关键入口——必须基于打开的文件描述符加锁，不能对路径字符串操作。
不是代码写错了，而是默认配置把连接压垮了——gorilla/websocket 的 Upgrader.CheckOrigin 默认返回 false，看似安全，实则在高并发握手阶段直接阻塞；更隐蔽的是 WriteBufferSize 和 ReadBufferSize 默认只有 4096 字节，小包多、心跳密的场景下，频繁系统调用 + 内存拷贝会吃掉大量 CPU。
这个值决定 InnoDB 能缓存多少数据和索引，设得太小会导致频繁磁盘读，太大则可能挤占系统内存引发 swap。关键不是看“推荐 70%~80%”，而是看实际工作集大小。
KVM/QEMU 虚拟机配置优化，核心在于资源匹配、I/O 效率和内核协同——不是堆参数，而是让虚拟机真正“像物理机一样呼吸”。