phpMyAdmin导出大库致MySQL崩溃主因是OOM Killer强制终止mysqld，应查错误日志中“Out of memory”或“Killed process mysqld”及dmesg记录，调低innodb_buffer_pool_size、增大max_allowed_packet、分片导出并验证COMMIT位置与表数量。

phpMyAdmin导出大数据库时MySQL崩溃，不是phpMyAdmin“卡了”，而是mysqld进程被系统强制杀死——通常发生在导出触发超大事务、锁表或缓冲池溢出时。直接查mysqld崩溃前的日志和系统OOM记录，比反复重试更有效。

看MySQL错误日志里有没有Out of memory或Killed process

MySQL崩溃后，第一手证据在错误日志（如/var/lib/mysql/hostname.err）。打开它，搜最后几条记录：

• 出现Out of memory或Cannot allocate memory → 基本确认是内存耗尽
• 看到Killed process <code>mysqld（注意不是mysqld_safe）→ 说明Linux OOM Killer出手了
• 有InnoDB: Assertion failure或mysqld got signal 11 → 可能是数据损坏或bug，但概率低于内存问题

用dmesg -T | grep -i "killed process"确认是否被OOM Killer干掉

dmesg记录内核事件，OOM Killer动作一定会留下痕迹。执行命令后若输出类似：

Killed process 12345 (mysqld) total-vm:24567890kB, anon-rss:18234567kB, file-rss:0kB

说明MySQL因内存超限被系统强制终止。此时不用查SQL或权限，优先调低innodb_buffer_pool_size或限制导出粒度。

MySQL8 CRM Schema Design Expert

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

下载

立即学习“PHP免费学习笔记（深入）”；

• 别只看free -h空闲内存——OOM Killer看的是进程实际RSS + 缓冲区压力
• 如果mysqld RSS接近你设的innodb_buffer_pool_size，且该值 > 物理内存 × 0.6，就极可能触发OOM
• 导出时LOCK TABLES会延长InnoDB表锁持有时间，加剧buffer pool争抢，加重OOM风险

导出前检查max_allowed_packet和事务大小是否匹配

phpMyAdmin导出默认用单个大事务拼SQL，一旦某张表含大量TEXT/JSON字段，单条INSERT语句可能远超max_allowed_packet，导致MySQL解析失败并崩溃。

• 运行SHOW VARIABLES LIKE 'max_allowed_packet';，确认值 ≥ 64M（100MB以上库建议设为256M）
• 在Custom导出模式中，把Maximal length of created query调到50000（默认5000），避免单条INSERT括号过多
• 禁用Add DROP TABLE ...和Disable foreign key checks不能解决崩溃，但能减少事务体积；真正关键的是控制每批INSERT行数

导出中断后MySQL没报错，但导入时崩溃——说明导出文件已截断

phpMyAdmin导出失败不会提示“导出不完整”，只会返回一个看似正常的.sql文件。而这个文件若在中途被PHP或MySQL中断，导入时就会因语法断裂或字符集错位引发崩溃。

• 用文本编辑器打开导出文件，搜索COMMIT;——它必须出现在文件末尾附近；若完全找不到，或只在中间出现一次，说明事务未完成
• 搜索CREATE TABLE出现次数，应与SHOW TABLES;结果一致；少于实际表数，就是导出被截断
• 不要对截断文件做任何导入尝试——它大概率会让MySQL在解析阶段崩溃，而非报错退出

真正危险的不是“导不出”，而是“导出看起来成功了”。每次导出完成后花30秒验证COMMIT位置和表数量，比事后排查MySQL崩溃快得多。