应改MySQL的max_allowed_packet至512M并重启服务，同时用split或脚本分批导入SQL文件，避免Navicat预加载整文件导致内存溢出。
Navicat导入大SQL文件报 Out of memory 怎么办
直接改navicat内存设置基本无效——它不真正控制sql执行时的内存，只是影响ui加载。真正卡住的是mysql服务端在解析和执行sql时的缓冲区限制，以及navicat自身对sql文件的预加载行为。
max_allowed_packet 必须调，但不能只调它
Navicat导入失败时，错误日志里常看不到明确提示，但实际根源往往是MySQL拒绝接收超长SQL语句（比如单条INSERT含几万行）。max_allowed_packet 默认只有4MB甚至1MB，远不够处理GB级SQL文件中的大INSERT或BLOB字段。
- 编辑MySQL配置文件：
my.ini（Windows）或my.cnf（Linux），在[mysqld]段下添加或修改：max_allowed_packet = 512M（不建议直接设1G，容易触发其他OOM） - 必须重启MySQL服务才能生效，仅重连Navicat无效
- 注意：客户端连接也要同步放宽，可在Navicat连接的「高级」设置里勾选「使用自定义
max_allowed_packet」并填同样值，否则Navicat仍按旧值截断
分批导入比调参数更可靠
即使max_allowed_packet调高，Navicat仍会把整个SQL文件读入内存做语法预检，遇到几百万行INSERT或大量注释就直接崩。这时候分批不是“可选优化”，而是唯一可行路径。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 用
split（Linux/macOS）或gsplit（Windows需安装CoreUtils）按行数切分：split -l 50000 full.sql part_ - 或用Python脚本按
CREATE TABLE/INSERT INTO块切分，保留结构完整性 - 导入时关闭Navicat的「自动提交每个语句」选项，改用事务包裹每批，减少日志压力
- 优先导入表结构（
CREATE TABLE部分）单独成文件，再逐个导入数据，避免结构+数据混在一起导致解析失败
为什么lower_case_table_names=1有时会误救
有些大SQL导出自Linux服务器（默认大小写敏感），而目标MySQL在Windows上运行（默认不敏感），但Navicat在导入前尝试校验表是否存在时，因大小写匹配失败反复重试，间接加剧内存占用。加lower_case_table_names = 1后跳过这部分逻辑，看起来“好了”，其实掩盖了根本问题——这不是内存问题，是元数据不一致。
真正该检查的是SQL文件头部是否有SET NAMES、SET SQL_MODE等会干扰解析的语句，以及是否混有/* */跨多行注释（Navicat某些版本会因注释解析卡死）。
