512MB内存运行MySQL可行但需极致精简：关闭非必要功能、限制连接数至32、禁用二进制日志与性能模式、仅启用InnoDB，否则必因OOM崩溃。

512MB内存跑MySQL是可行的，但必须关闭所有非必要功能、严格限制连接数、禁用查询缓存（8.0已移除）、且不能开InnoDB以外的引擎——否则服务会频繁OOM或启动失败。

为什么默认配置在512MB上必然失败

MySQL 8.0默认 innodb_buffer_pool_size 是128MB，但还会额外占用：每个连接约3–4MB（含排序缓冲、临时表等）、key_buffer_size（MyISAM用）、tmp_table_size、max_connections=151 等。加起来轻松超512MB，系统直接杀掉 mysqld 进程。

常见错误现象包括：

• mysqld: OOM killed process（dmesg 可查）
• 服务启动后几秒内自动退出，systemctl status mysqld 显示 “exited with code=137”
• mysql -u root -p 连不上，报错 Can't connect to local MySQL server

my.cnf 必须精简到最小可用集

编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，只保留以下核心项（其他全删或注释掉）：

[mysqld]
datadir=/var/lib/mysql
socket=/var/run/mysqld/mysqld.sock
pid-file=/var/run/mysqld/mysqld.pid
<h1>内存控制（关键！）</h1><p>innodb_buffer_pool_size=128M
innodb_log_file_size=16M
innodb_flush_log_at_trx_commit=2
skip-log-bin
disable_log_bin</p><h1>连接与线程</h1><p>max_connections=32
wait_timeout=60
interactive_timeout=60
table_open_cache=64
sort_buffer_size=64K
read_buffer_size=64K
read_rnd_buffer_size=64K
tmp_table_size=16M
max_heap_table_size=16M</p><h1>引擎与安全</h1><p>default-storage-engine=INNODB
skip-innodb_doublewrite
skip-innodb-adaptive-hash-index
skip-performance-schema
skip-ssl
local_infile=OFF</p><p>[client]
socket=/var/run/mysqld/mysqld.sock

说明：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• innodb_buffer_pool_size=128M：占总内存¼，留足给OS（至少128MB）和连接开销
• skip-log-bin 和 disable_log_bin：二进制日志极其吃内存，小内存场景必须关
• skip-performance-schema：默认启用会多占30–50MB，关掉无损基础功能
• sort_buffer_size 等设为64K而非默认256K，避免单连接突发内存暴涨

启动前必须做的三件事

不执行这三项，即使配置改了也大概率起不来：

• 手动清理旧日志：rm -f /var/lib/mysql/ib_logfile*（否则 innodb_log_file_size 不匹配会拒绝启动）
• 确认 /var/lib/mysql 所在分区有 ≥500MB 空闲空间（InnoDB重做日志+数据文件最低需求）
• 运行 sudo sysctl vm.swappiness=1 并写入 /etc/sysctl.conf，防止OOM killer误杀

启动后立刻验证：

mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"

如果 Threads_connected 长期 >20，说明连接数仍偏高，需进一步调低 max_connections 或检查应用是否未正确复用连接。

应用层必须配合的约束

服务器端压得再紧，应用乱开连接或查大表照样崩：

• 禁止使用 SELECT *，尤其带 TEXT/BLOB 字段——容易触发隐式磁盘临时表
• 所有客户端必须启用连接池（如 Java 的 HikariCP，Node.js 的 mysql2/pool），maxPoolSize ≤ 16
• 禁用长事务：SET autocommit=1，避免 undo log 持续膨胀
• 定期执行 ANALYZE TABLE（每周一次），防止统计信息过期导致执行计划劣化

最后提醒：512MB是临界值，不是推荐值。只要业务稍有增长（比如并发从10→30，或单表数据从1万→10万行），就必须升级到1GB+内存。别指望“再优化一点就能撑住”——内存不足时的抖动和延迟突增，比扩容成本更难排查。