直接结论：不是内存不够，而是innodb_buffer_pool_size设太高了，必须立刻调低——2GB内存机器设成32M是最稳妥起点；需修改XAMPP\mysql\bin\my.ini中[mysqld]段的innodb_buffer_pool_size=32M、innodb_buffer_pool_instances=1、max_connections=30及tmp_table_size=max_heap_table_size=16M，删query_cache配置，管理员重启后用SHOW VARIABLES验证。
直接结论：不是内存不够，而是 innodb_buffer_pool_size 设太高了，必须立刻调低——2GB 内存机器设成 32M 是最稳妥的起点。
为什么 XAMPP 启动就报 “Out of memory”
这不是系统真没内存，而是 MySQL 启动时硬分配一块固定大小的匿名内存（innodb_buffer_pool_size），它不随负载释放、也不走 swap。XAMPP 默认设为 128M，在 2GB 内存的笔记本或虚拟机上，光这一项就吃掉近一半可用内存；再叠加上每个连接的 sort_buffer_size、临时表、performance_schema 等开销，RSS 很快冲到 500MB+，触发 Linux OOM Killer 或 Windows 内存不足弹窗。
常见现象包括：
- XAMPP 控制面板点 “Start” 后 MySQL 状态变灰、无响应
- 任务管理器里
mysqld.exeRSS 突增至 400–600MB 后卡死 - PHP 页面加载超时、WordPress 后台打不开、简单
SELECT查询也慢
改哪个文件、怎么改才生效
必须改 XAMPP\mysql\bin\my.ini，其他路径（如 C:\Windows\my.ini 或任意 my.cnf）全无效。打开后定位到 [mysqld] 段落，只保留这几行关键配置：
-
innodb_buffer_pool_size = 32M—— 单位只认M或K，不能写MB或带空格 -
innodb_buffer_pool_instances = 1—— 小于 1GB 缓冲池时设多个实例反而增加锁开销 -
max_connections = 30—— 默认 151 在低配机上是灾难，每连接都独占缓冲区 -
tmp_table_size = 16M和max_heap_table_size = 16M—— 必须相等，否则 MySQL 按小值生效 - 删掉所有
query_cache_*行 —— MySQL 5.7+ 已彻底移除，留着只报 warning
别碰 innodb_additional_mem_pool_size：XAMPP 7.4+（MySQL 5.7.33+）已移除该参数，存在会导致启动警告甚至阻塞。
改完不重启等于白改，验证比修改更重要
保存 my.ini 后，必须以管理员身份重启服务：
- 用 XAMPP 控制面板点 “Stop” 再 “Start” MySQL
- 或命令行运行：
net stop mysql && net start mysql
重启后立即验证是否生效：
mysql -u root -p SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
返回值应为 33554432（即 32×1024×1024 字节）。再执行：
ps -o pid,rss,comm -C mysqld
观察 RSS 是否从 500MB+ 明显回落至 150–250MB 区间。如果仍高，重点查 information_schema.PROCESSLIST 里是否有大量 Creating tmp table 或连接堆积。
最容易被忽略的是：这个值不是“建议上限”，而是 MySQL 启动时就 malloc 的固定内存块；哪怕你只建了一张空表，它也照占不误。调低之后，性能不会下降——因为低配机根本跑不动大缓冲池，所谓“命中率”在内存压爆面前毫无意义。
