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