MySQL 在虚拟机里启动失败：检查 innodb_buffer_pool_size 和内存分配
虚拟机常因内存不足导致 MySQL 启动卡在 Starting MySQL database server 或直接报 InnoDB initialization failed。根本原因不是磁盘或配置文件语法错，而是 InnoDB 缓冲池申请不到足够内存。
- 默认
innodb_buffer_pool_size是 128MB，但很多虚拟机（尤其 2GB 内存以下）实际可用内存远低于系统标称值——宿主机可能已占用 30%~50%，且 Linux 自身缓存、swap 策略会进一步挤压 MySQL 可用空间 - 建议设为物理内存的 40%~60%，但必须 ≤ 虚拟机实际空闲内存（
free -h看available列，不是free） - 若仍报错，临时降为
64M测试能否启动；确认后逐步调高，避免直接设1G导致 OOM killer 杀掉 mysqld 进程
虚拟机磁盘 I/O 慢得离谱：禁用 innodb_flush_method 默认值
MySQL 在 VMware/VirtualBox 上默认用 fsync 刷盘，而虚拟化层对 fsync 的模拟开销极大，写入延迟常飙到 100ms+，INSERT 或 UPDATE 直接卡住。
- Linux 虚拟机优先设
innodb_flush_method = O_DIRECT（绕过 OS 缓存，减少双缓冲） - 若用 ext4 + LVM，可尝试
O_DSYNC；但 XFS 下O_DIRECT更稳 - 切勿设成
async_unbuffered（已废弃）或留空（等价于fsync），这是性能陷阱最常见配置 - 注意：改完需重启 MySQL，且
O_DIRECT要求数据目录所在分区支持 direct I/O（多数现代虚拟磁盘都支持）
主从复制延迟高：关掉虚拟机时间同步干扰
虚拟机被宿主机暂停、迁移或 CPU 抢占时，系统时间可能跳变，MySQL 的 binlog_timestamp 和复制心跳会误判“时间倒流”，触发重连或延迟堆积，Seconds_Behind_Master 突然涨到几百秒。
- 在虚拟机内停用
systemd-timesyncd或ntpd，改用宿主机提供的时间源（如 VMware Tools 的vmtoolsd --timesync-enable） - MySQL 配置加
slave_net_timeout = 30（别用默认 3600），缩短网络抖动后的重连等待 - 监控项重点看
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否持续追平，而非只盯延迟数字
连接数爆满却查不到活跃会话：检查 wait_timeout 和虚拟机休眠行为
虚拟机挂起/恢复后，MySQL 的连接状态没及时清理，show processlist 显示大量 Sleep 状态连接，但 Threads_connected 持续接近 max_connections，新连接被拒。
-
wait_timeout默认 28800 秒（8 小时），远超虚拟机休眠周期，必须调低——生产环境建议 ≤ 300（5 分钟） - 应用层也要配连接池的 idle timeout，且必须 ≤ MySQL 的
wait_timeout，否则连接池以为连接还活，MySQL 却已断开 - 虚拟机恢复后执行
KILL手动清理残留连接不治本，关键是让超时机制在休眠前就生效
虚拟化环境里，MySQL 不是单纯“装上就能跑”，每个参数背后都连着宿主机资源调度、虚拟磁盘栈、时钟虚拟化三层耦合。最容易被忽略的是：你看到的内存和磁盘，MySQL 看到的未必一样。
