ReadRndBufferSize 仅影响 SELECT 的排序与随机读取，与 DML 内存占用完全无关；DML 内存关键参数包括 sort_buffer_size、tmp_table_size、max_heap_table_size 和 innodb_sort_buffer_size。
ReadRndBufferSize 是什么，它真能控制 DML 内存占用吗？
ReadRndBufferSize 是 MySQL 中一个**仅影响 SELECT 语句的排序与随机读取行为**的会话级参数，和 INSERT/UPDATE/DELETE 这类 DML 语句的内存占用**完全无关**。很多用户在排查 DML 内存飙升时误调这个参数，结果毫无改善——因为 DML 不走 ReadRndBufferSize 的路径。
它的实际作用是：当优化器选择使用“索引扫描 + 回表”（例如 Using where; Using index; Using filesort 或需要按非索引顺序读行）时，MySQL 会用该缓冲区暂存一批主键或 rowid，再批量回表读取数据行，减少磁盘随机 I/O。值太小会导致频繁回表；太大则浪费内存，但只对 SELECT 生效。
真正影响 DML 内存的关键参数有哪些？
DML 语句的内存开销主要来自三类操作：临时表、排序、批量写入缓冲。对应的核心参数如下：
-
sort_buffer_size：UPDATE/DELETE 带ORDER BY或LIMIT时可能触发排序（如DELETE FROM t ORDER BY ts LIMIT 1000），此时每个连接独占一份该缓冲 -
tmp_table_size和max_heap_table_size：INSERT … SELECT、UPDATE 多表关联等场景若生成内部临时表，会先尝试用内存临时表，超限才落磁盘 -
innodb_sort_buffer_size：InnoDB 在创建索引（如 ALTER TABLE ADD INDEX）或 bulk insert（LOAD DATA、INSERT ... VALUES (...), (...)批量插入）时用于排序页内记录，直接影响 B+ 树构建阶段内存 -
bulk_insert_buffer_size：专用于 MyISAM 的批量插入优化（InnoDB 不用），可忽略
如何定位某条 DML 实际用了多少内存？
MySQL 没有直接暴露单条 DML 的实时内存用量，但可通过组合手段缩小范围：
- 开启 performance_schema，查
events_statements_current+memory_summary_by_thread_by_event_name，过滤出执行中的线程及其内存事件（注意：开销大，仅临时诊断） - 用
SHOW PROCESSLIST观察状态：若卡在Sorting result或Creating sort index，说明正在用sort_buffer_size - 执行前设
SET SESSION tmp_table_size = 64*1024, max_heap_table_size = 64*1024，再跑 DML，看是否立刻报ERROR 1160 (HY000): Got an error writing communication packets或降级到磁盘临时表（Created_tmp_disk_tables状态变量上升） - 对于大批量 INSERT，用
EXPLAIN FORMAT=JSON查INSERT ... SELECT计划，关注using_temporary_table和using_filesort字段
调整建议与典型陷阱
盲目增大全局 sort_buffer_size 或 tmp_table_size 可能引发 OOM，尤其在高并发场景下——每个连接都分配一份缓冲。更安全的做法是按需会话级设置：
- 对已知会触发排序的 UPDATE/DELETE，执行前显式设小点：
SET SESSION sort_buffer_size = 256*1024（默认 256KB，够大多数场景） - 批量导入时，优先用
LOAD DATA INFILE（比 INSERT 快且内存更可控），并确保innodb_sort_buffer_size≥ 单次插入行数 × 平均索引键长（一般 2–4MB 足够） - 避免在 DML 中嵌套复杂子查询或 JOIN，它们极易触发大内存临时表；拆成中间表或应用层分批处理更稳
-
ReadRndBufferSize的默认值（256KB）已足够，除非你有大量带ORDER BY RAND()的 SELECT，否则别碰它——它真不碰 DML
最常被忽略的一点：DML 内存压力往往不是参数本身的问题，而是语句设计不合理（比如没加 WHERE 的全表 UPDATE）或事务过大（未分批提交）。先检查 SQL 逻辑和事务粒度，再调参数。
