innodb_buffer_pool_size是实例级全局缓冲池，所有用户共享，不按连接分配，故无法限制单用户内存；真正随用户连接数增长的是sort_buffer_size等per-connection参数。
MySQL 本身不支持按用户限制内存使用量，innodb_buffer_pool_size 是全局共享的，所有连接共用同一块缓冲池，无法为单个用户或账号单独设上限。
为什么 innodb_buffer_pool_size 不能用于限制单用户内存
这个参数控制的是整个 InnoDB 存储引擎的数据和索引缓存区域大小，属于实例级资源，不是 per-user 或 per-connection 分配的。用户连接数再多，也不会额外“分走”更多 buffer pool；它只影响缓存命中率和磁盘 I/O 压力。
-
innodb_buffer_pool_size修改后需全局生效，所有用户受益（或受损） - 真正会随连接数线性/指数增长的是
sort_buffer_size、read_buffer_size、join_buffer_size这类 per-connection 参数 - 一个恶意用户执行大量大排序或大连接查询，可能耗尽这些 per-connection 内存，拖垮整个实例，但不会突破
innodb_buffer_pool_size的设定
想限制单用户资源，该调哪些参数
MySQL 提供了基于用户的资源限制机制，通过 CREATE USER 或 ALTER USER 设置，但仅限于 CPU、连接数、查询次数等维度，**不包括内存**：
-
MAX_CONNECTIONS_PER_HOUR：每小时最多新建连接数 -
MAX_QUERIES_PER_HOUR：每小时最多执行语句数 -
MAX_UPDATES_PER_HOUR：每小时最多更新语句数 -
MAX_USER_CONNECTIONS：同时最大活跃连接数（最接近“限制用户资源”的手段）
注意：MAX_USER_CONNECTIONS 能间接控内存——因为每个连接都会分配 sort_buffer_size 等内存，限制连接数就等于限制这部分内存的总潜在开销。
真正影响单连接内存占用的关键参数
如果你发现某个用户连上后 MySQL 内存飙升，问题大概率出在这些 per-connection 配置上，而非 innodb_buffer_pool_size：
-
sort_buffer_size：默认 256KB，大 ORDER BY 可能触发多次分配，连接数 × 该值 = 实际内存压力 -
read_buffer_size：默认 128KB，全表扫描时启用，同样受连接数放大 -
tmp_table_size和max_heap_table_size必须严格相等，否则内存临时表会静默退化为磁盘临时表，不仅慢，还可能因磁盘 I/O 拖垮系统 - 避免在配置文件里把
sort_buffer_size设成 4M 或 8M——这是典型陷阱，小并发就 OOM
生产环境推荐做法
没有“单用户内存限制”，只有“合理抑制单连接失控”：
- 保持
sort_buffer_size≤ 512KB，read_buffer_size≤ 256KB，除非有明确压测依据 - 确保
tmp_table_size = max_heap_table_size，建议都设为 64M（足够日常用，又不至于让单查询吃掉太多内存） - 对高风险账号（如报表用户、ETL 账号），用
MAX_USER_CONNECTIONS = 3严控并发连接数 - 监控
SHOW GLOBAL STATUS LIKE 'Created_tmp%'，若Created_tmp_disk_tables持续上升，说明临时表正在频繁落盘，得查是不是tmp_table_size设低了或 SQL 写法有问题
真正难控的从来不是 buffer pool，而是每个连接悄悄拿走的那几 MB 内存——它们加起来，比 buffer pool 更容易触发 OOM。
