max_allowed_packet 是 mysql 服务端和客户端能接收的最大单个数据包大小，影响 sql 语句、结果集、blob、load data 等传输；需同时配置服务端（my.cnf 中 [mysqld] 段或 set global）和客户端（命令行/jdbc/驱动参数），单位注意区分（配置文件支持 m，sql 必须字节整数）；推荐起步值 50–100mb，避免盲目设过大引发 oom 或复制延迟。
max_allowed_packet 是什么，为什么改它
这个配置项控制 MySQL 服务端和客户端能接收的最大单个数据包大小。不是“上传文件大小”，而是 SQL 语句、结果集、BLOB 字段、LOAD DATA 的行数据等在传输过程中打包的上限。超过就直接报错 Got a packet bigger than max_allowed_packet，连接中断，不给重试机会。
常见触发场景：INSERT 含超长 JSON 字符串、UPDATE 批量写入大文本、用 mysqldump 恢复含大 BLOB 的库、ORM 执行带巨量参数的批量插入（比如 1000 行 × 每行 2MB）。
怎么改：服务端 vs 客户端要分开设
MySQL 的 max_allowed_packet 有两套独立值：服务端（mysqld 进程）和客户端（mysql 命令行、JDBC、Python 的 pymysql 等）。只改服务端，客户端仍可能因自身限制提前截断；只改客户端，服务端照样拒绝大包。
- 服务端生效需重启或动态设置：
SET GLOBAL max_allowed_packet = 64*1024*1024;（64MB），但该值在重启后丢失；持久化必须写进配置文件/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf的[mysqld]段下：max_allowed_packet = 64M - 客户端也要配：命令行启动加
--max-allowed-packet=64M；JDBC URL 加&maxAllowedPacket=67108864；Python 的pymysql.connect()传参max_allowed_packet=67108864 - 注意单位：配置文件里支持
64M，但 SQL 语句里必须是整数字节（如67108864），不能写64*1024*1024
改多大才安全？别盲目拉到 1G
设太大不光浪费内存，还会放大问题：超大包失败时重传成本高、OOM 风险上升、主从复制延迟加剧（尤其 binlog 格式为 STATEMENT 时，一个大包可能对应几万行变更）。
- 先确认真实需求：用
SELECT LENGTH(blob_col) FROM tbl ORDER BY LENGTH(blob_col) DESC LIMIT 1;查当前最大单字段长度；用SHOW VARIABLES LIKE 'max_allowed_packet';看当前值 - 推荐起步值：50–100MB。够覆盖绝大多数业务大字段场景，又不至于失控
- 若用
mysqldump，记得加--max-allowed-packet=128M参数，它的默认值不读全局配置 - 云数据库（如阿里云 RDS、AWS RDS）通常限制修改该参数，得走控制台申请或选更高规格实例
改完没生效？检查这三处
最常踩的坑不是不会设，而是设了却没起作用——因为生效层级或加载顺序错了。
- 配置文件路径是否正确？
mysqld --help --verbose | grep "Default options"能看到实际加载的 cnf 文件列表，优先级从高到低：命令行 >/etc/my.cnf>/etc/mysql/my.cnf>$MYSQL_HOME/my.cnf>~/.my.cnf - 确认改的是
[mysqld]段，不是[client]或[mysql]段（后者只影响客户端工具，不影响服务端接收能力） - 动态 SET 后没验证：执行
SHOW VARIABLES LIKE 'max_allowed_packet';，对比GLOBAL和SESSION值；新连接才继承 GLOBAL，旧连接保持原 SESSION 值
SET GLOBAL，但客户端连接不重启就不会读新值；很多问题卡在这一步，而不是配置本身写错了。
