确认mysqldump报“packet too large”是max_allowed_packet问题，需查错误信息是否含“packets larger than max_allowed_packet”或“got packet bigger than”，并执行select @@global.max_allowed_packet验证服务端真实值（字节），同时mysqldump命令必须显式加--max-allowed-packet=512m（单位大写m、置于命令前）且服务端配置须在[mysqld]段、重启生效。
max_allowed_packet 就行，但必须服务端和客户端同步改、单位写对、重启生效，否则备份照样失败。
mysqldump 报错 “Packet too large” 怎么确认是 max_allowed_packet 问题？
错误信息里出现 Packets larger than max_allowed_packet are not allowed 或 Got packet bigger than 'max_allowed_packet' bytes (X > Y) 就是它。括号里左边 X 是实际要发的包大小（字节），右边 Y 是当前限制值——比如 8808741 > 4194304 表示要发 8.4MB，但限制只有 4MB。
- 别只看配置文件，登录 MySQL 执行
SELECT @@global.max_allowed_packet;查真实服务端值（单位字节） -
SHOW VARIABLES LIKE 'max_allowed_packet';默认查会话级，可能被连接池或 ORM 覆盖，不准 - 如果用云数据库（如阿里云 RDS），
SET GLOBAL通常被禁用，查出来仍是默认值，得去控制台改参数组
服务端怎么改 max_allowed_packet 才真正生效？
必须改在 [mysqld] 段，单位用大写 M，改完必须重启服务。
- 配置路径：先执行
SHOW VARIABLES LIKE 'config_file';确认真实生效的文件（常见：/etc/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf） - 只允许写在
[mysqld]下，例如：max_allowed_packet = 512M；写在[client]或[mysql]段完全无效 - 不能写
512MB、512m或带空格的512 M，MySQL 启动会失败 - 改完必须执行
systemctl restart mysql（或service mysqld restart），mysqladmin reload不起作用
mysqldump 命令怎么配才不白忙活？
mysqldump 是客户端工具，它不读 [client] 段，也不继承服务端设置，必须显式传参。
- 参数位置很重要：
mysqldump --max-allowed-packet=512M -u root -p db_name > dump.sql——--max-allowed-packet必须放在数据库名之前 - 单位必须是
M（大写），不能写512m或漏掉单位（512表示 512 字节） - 如果导出含 BLOB 的表，建议加
--hex-blob，避免二进制内容干扰协议解析；若字段含 emoji，加--default-character-set=utf8mb4 - 避免单条 INSERT 过长：加
--skip-extended-insert，每行生成独立语句，包体积可控（但导入变慢）
为什么设成 1G 还失败？真正容易被忽略的点
不是配置没生效，而是源数据本身触发了协议边界问题。
- CSV 或 SQL 文件里一个未转义的换行符，会让 MySQL 把整行当一个 packet 解析——哪怕字段本身不大，行宽超限就直接拒收
- LOAD DATA INFILE 不走客户端缓冲，只依赖服务端
max_allowed_packet和local_infile = ON，但云环境通常禁用local_infile - mysqldump 默认把几千行拼成一条 INSERT，SQL 模板 + 数据 + 转义字符会让实际包体积翻倍，光看字段长度会低估
- 物理内存不足时，MySQL 启动阶段分配连续内存失败，设 2G 可能直接启动不了，推荐起步值 128–512M，够用且安全
