MySQL RSS内存远超innodb_buffer_pool_size，主因是InnoDB控制结构开销叠加每连接私有缓冲区（如sort_buffer_size、join_buffer_size、thread_stack）的乘数效应；1000个活跃连接×2MB sort_buffer即可额外占用2GB，Sleep连接同样持续耗内存，需通过performance_schema和SHOW PROCESSLIST精准定位各模块真实占用。
MySQL RSS 内存远超 innodb_buffer_pool_size 设置值，不是配置写错了，而是 InnoDB 控制结构开销 + 每连接私有缓冲区（sort_buffer_size、join_buffer_size、thread_stack）叠加导致的——哪怕 innodb_buffer_pool_size 设为 2G，1000 个活跃连接光 sort_buffer_size=2M 就能吃掉 2GB。
查清真实内存构成，别只盯 buffer_pool
先确认到底哪些部分在吃内存：
-
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'—— 看你设的值（单位字节），再用free -h对比available列，确认是否超可用内存 -
SHOW VARIABLES LIKE 'sort_buffer_size'、'join_buffer_size'、'read_rnd_buffer_size'、'max_connections'—— 这些乘起来就是潜在连接内存上限 -
mysqladmin ext -ri1 | grep -E "Innodb_buffer_pool_bytes|Threads_connected"—— 实时观察Innodb_buffer_pool_bytes_data（实际缓存数据量）与Threads_connected变化趋势 - 云环境务必查
sys.memory_global_total（MySQL 8.0+）或performance_schema.memory_summary_global_by_event_name，它能拆出memory/innodb/buf_buf_pool、memory/sql/JOIN_CACHE、memory/temptable/physical_ram等明细
限制 per-connection 内存，Sleep 连接最危险
每个连接独占栈和缓冲区，空闲 Sleep 连接照吃不误。1000 个连接 × sort_buffer_size=2M = 2GB，还没算其他项。
- 查真实连接堆积：
SHOW PROCESSLIST看大量Sleep且Time持续增长；SHOW STATUS LIKE 'Threads_connected'长期 >70%max_connections - 收紧保活：
wait_timeout = 300、interactive_timeout = 300（默认是 28800 秒，即 8 小时） - 调低 per-connection 缓冲区：生产环境慎用默认 2MB
sort_buffer_size，可设为512K或1M；join_buffer_size同理，避免全局设高，改由优化器提示（/*+ JOIN_BUFFER() */）按需分配 - 确认应用连接池配置：HikariCP 的
idle-timeout、max-lifetime是否合理；PHP 不要用mysql_connect()无持久化连接
动态调小 innodb_buffer_pool_size 要避开整数倍陷阱
SET GLOBAL innodb_buffer_pool_size 看似方便，但新值必须是 innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances 的整数倍，否则会被向下取整，且重建过程会卡顿。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 先查当前分块参数：
SHOW VARIABLES LIKE 'innodb_buffer_pool_chunk_size'、'innodb_buffer_pool_instances'（常见组合如 128M × 8 = 1G） - 计算安全新值：比如 chunk=128M，instances=8，则只能设 1G、2G、3G… 若设
2500M，实际生效仍是2G - 执行后立刻验证：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'，别信命令返回的“OK” - 注意：内存不会秒退，
Innodb_buffer_pool_pages_free会缓慢上升，Innodb_buffer_pool_resize_status显示 “Resizing also buffer pool” 表示还在进行中
Kylin V10 上 open_files_limit 会引发内存雪崩
这不是 MySQL 配置问题，是 Kylin V10 内核读取 /proc/self/limits 时返回异常高的 soft limit（比如 1073741816），MySQL 据此预分配句柄管理结构，直接触发 GB 级内存申请。
- 验证：
cat /proc/self/limits | grep "Max open files"，若第二列（soft limit）接近 10 亿，基本锁定 - 修复首选容器启动加：
--ulimit nofile=65536:65536（Docker/K8s 均适用） - 次选
my.cnf显式设：open_files_limit = 65536（仅 MySQL 启动时有 root 权限才生效，容器内通常无效） - 禁用热加载机制：
innodb_buffer_pool_dump_at_shutdown = OFF、innodb_buffer_pool_load_at_startup = OFF，尤其当热数据远小于 buffer pool 总大小时，加载反而拖慢启动、多占 I/O 缓存
真正难控的是连接数和 per-connection 缓冲区的乘数效应——buffer pool 是静态大头，但连接内存是动态放大器，一个没关的 Sleep 连接、一个没设限的 sort_buffer，都可能让内存占用翻倍。监控必须落到 Threads_connected 和 performance_schema.memory_summary_by_thread_by_event_name 这一级，不能只看总 RSS。
