MySQL没有max_result_size配置项，它被忽略且不报错；真正控制结果集规模的是sql_select_limit、max_allowed_packet和应用层LIMIT。
MySQL 没有这个配置项，直接设它不会生效，还可能掩盖真正的问题。
为什么找不到
？
这是个常见误解——把其他数据库（比如 PostgreSQL 的
或某些中间件的限流逻辑）的参数名套到了 MySQL 上。MySQL 官方配置中从不存在
，
mysql
d 启动时会忽略它，且不报错，导致你以为“设了但没用”，其实是根本没被读取。
真正能控制结果集规模的，是以下三个层面的组合：
（会话级限制，影响
返回行数）
（限制单次传输最大包，超了会报
）
应用层显式加
（最可靠、最可控的方式）
怎么用才安全？
它能强制给每个
语句加上隐式
，但行为容易踩坑：
只对当前会话生效，全局设置需写进配置文件并重启，或用
（需要 SUPER 权限）
它不阻止大结果集生成，只是截断返回——意味着服务器仍要扫描全表、排序、生成临时结果，内存和 CPU 该爆还是爆
对
、子查询、视图内部查询无效
如果应用依赖
或分页总条数，它会让
也返回截断后的值，逻辑出错
示例：
之后执行
，只会返回前 500 行，但执行时间可能依然很长。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
真正防内存爆炸的关键在哪儿？
不是靠某个“神奇开关”，而是分层防御：
应用代码里所有
必须带
，没有例外；分页场景用游标（cursor-based）代替
，避免深分页扫全表
设为合理值（比如
），防止客户端一次拉回几百 MB 结果压垮连接或本地内存
监控慢查询日志 +
，对 > 10w 行扫描的查询主动优化（加索引 / 改写逻辑 / 拆任务）
禁止开发环境直连生产库执行无
的
，可通过代理层（如 ProxySQL）或 RDS 的 SQL 审计规则拦截
比如发现某接口调用
却没
，而该表每天新增百万行——这时候加
是掩耳盗铃，必须改代码。
最容易被忽略的是：
修改后，客户端驱动（如 MySQL Connector/J、pymysql）也要同步调大
参数，否则会在客户端侧先报错，让你误以为服务端限制没生效。
max_result_sizemax_result_sizestatement_timeoutmax_result_sizesql_select_limitSELECTmax_allowed_packetPackets larger than max_allowed_packet are not allowedLIMITsql_select_limitSELECTLIMITSET GLOBAL sql_select_limit = 1000INSERT ... SELECTSELECT COUNT(*)COUNT(*)SET SESSION sql_select_limit = 500;SELECT * FROM huge_table;SELECTLIMITOFFSETmax_allowed_packet64MRows_examinedLIMITSELECT *SELECT * FROM order_log WHERE user_id = ?LIMITsql_select_limitmax_allowed_packetmax_allowed_packet