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 默认不持久化，重启后旧记录就丢了。

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

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

MySQL8 CRM Schema Design Expert

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

下载

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

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