调小max_allowed_packet不能防SQL注入，因其仅限制单包字节数，与注入逻辑无关；攻击者可用短payload绕过，反而导致合法大字段操作失败。
为什么调小 max_allowed_packet 不能防 SQL 注入
它完全不防 SQL 注入。这个配置只限制单条 SQL 语句或结果集的最大字节数，和注入逻辑无关。攻击者用 UNION SELECT 1,2,3 或 OR 1=1 这类短小精悍的 payload，根本不会触发 packet 超限。强行调小反而容易导致合法大字段插入失败、LOAD_FILE() 报错、长文本截断，甚至让 mysqldump 备份中断。
max_allowed_packet 的真实作用场景
它解决的是「数据传不全」问题，不是「语句安不安全」问题：
- 应用向 MySQL 发送一条含 5MB JSON 字段的
INSERT，但服务端max_allowed_packet是 4MB → 报错MySQL server has gone away - 执行
SELECT GROUP_CONCAT(large_column)返回超长字符串，客户端收不到完整结果 → 需同步调大客户端连接的max_allowed_packet - 主从复制中，一个大事务的 binlog event 超过从库设置值 → 复制中断，错误日志出现
Packets larger than max_allowed_packet
真正该在配置层做的三件事
防注入不靠封包大小，而靠切断攻击链路和暴露面：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 关闭
sql_mode中的STRICT_TRANS_TABLES以外的宽松模式（如NO_AUTO_CREATE_USER已废弃，但ALLOW_INVALID_DATES等会弱化校验） - 设置
secure_file_priv为非空路径（如/var/lib/mysql-files/），禁止攻击者用LOAD DATA INFILE或SELECT ... INTO OUTFILE读写任意文件 - 禁用危险函数：在启动参数中加入
--disable-functions=load_file,sys_eval,sys_exec（需编译支持）或通过mysql.func表删除对应 UDF
最容易被忽略的配置细节
很多团队改了 my.cnf 却没生效，因为：
-
max_allowed_packet在服务端（mysqld）、客户端（mysql命令行）、连接池（如 HikariCP 的connection-properties）三处都要一致，否则以最小值为准 - 动态修改需用
SET GLOBAL max_allowed_packet = 64*1024*1024，但重启后丢失；持久化必须写进配置文件并重启mysqld - PHP 的
mysqli扩展默认不读取 my.cnf，需显式调用mysqli_options($link, MYSQLI_OPT_READ_TIMEOUT, ...)类似逻辑控制连接行为
