MySQL“无故重启”八成是被内核OOM Killer杀死的，dmesg -T | grep -i "killed process.*mysqld"可查第一手证据；若输出含“Out of memory: Killed process”且时间戳匹配错误日志，则确认为OOM；容器中需检查docker inspect输出的"OOMKilled": true和ExitCode 137。

查 dmesg 里有没有 Killed process 记录

MySQL“无故重启”八成是被内核干掉的，dmesg 是第一手证据。执行：
dmesg -T | grep -i "killed process.*mysqld"
如果输出类似：
Out of memory: Killed process 12345 (mysqld) total-vm:12345678kB, anon-rss:987654kB
那就没跑了——OOM Killer 动的手。注意时间戳要和 MySQL 错误日志里的重启时间对得上，否则可能是其他原因。

看 /var/log/messages 或 /var/log/syslog 里是否漏掉关键行

有些系统（尤其是 RHEL/CentOS）会把 OOM 日志写进 /var/log/messages，Ubuntu/Debian 则多走 /var/log/syslog。直接搜：
grep -i "oom\|kill.*mysqld" /var/log/messages
常见线索包括：
mysqld invoked oom-killer
Memory cgroup out of memory（容器场景）
Task mysqld (pid XXXX) killed
如果这俩日志里都找不到 OOM 痕迹，别硬猜，先检查 dmesg 缓冲区是否被轮转覆盖了——dmesg 默认不持久化，重启后旧记录就丢了。

MySQL8 CRM Schema Design Expert

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

下载

确认是不是容器环境导致 dmesg 看不到 OOM

Docker 容器里 MySQL 被杀，宿主机 dmesg 可能有记录，但容器内 dmesg 是空的。更可靠的方式是：
docker inspect <container_name> | grep -A 5 'Status\|OOMKilled'</container_name>
重点盯两个字段：
"OOMKilled": true
"ExitCode": 137
ExitCode 137 = 128 + 9（SIGKILL），这是 OOM 的铁证。另外，docker stats <container_name></container_name> 里如果 MEM USAGE / LIMIT 长期贴近上限，也说明内存配少了。

为什么 mysqld 自己的日志里没写被杀过程

因为进程是被内核强制终止的，MySQL 没机会执行清理逻辑，自然不会写 “shutting down” 或 “got signal 9”。你只会看到上一次启动成功的日志，然后就是下一次启动——中间断层。所以：
• 不要在 error.log 里找“崩溃原因”，它只记录 MySQL 主动写的日志
• error.log 里反复出现 Aborted connection 或 Got an error reading communication packets，大概率是前序 OOM 导致连接异常中断后留下的尾巴，不是根源
• 真正的根因永远在系统层日志或容器元数据里，而不是 MySQL 自身日志