read_buffer_size用于优化无索引的全表扫描，仅在内存充足且确需顺序读大表时微调有效；盲目增大易致OOM，优先优化SQL和索引。
read_buffer_size 是干啥的，调它真能提速？
read_buffer_size 是 MySQL 为每个客户端连接分配的、用于顺序扫描（比如 SELECT 全表扫描或索引范围扫描）的内存缓冲区。它不作用于索引查找、排序、临时表这些场景——那些靠 sort_buffer_size、tmp_table_size 管。
真正受益的场景很窄：大表没走索引、又必须扫全表（比如归档导出、低效 WHERE 条件），且服务器内存充足。盲目调大反而浪费连接内存，尤其高并发时容易 OOM。
- 默认值通常 131072 字节（128KB），对多数 OLTP 查询完全够用
- 超过 2MB 后收益急剧衰减，MySQL 官方文档明确说“再大也没用”
- 它是会话级变量，
SET SESSION read_buffer_size = 2097152只影响当前连接
怎么改才安全？别直接写进 my.cnf
全局修改 read_buffer_size 必须重启 MySQL，而且所有新连接都会继承这个值——并发 1000 连接 × 4MB = 直接吃掉 4GB 内存，非常危险。
更稳妥的做法是按需动态设置：
- 只在执行明确知道要全表扫描的语句前设置：
SET SESSION read_buffer_size = 2097152; SELECT * FROM huge_log_table WHERE created_at > '2024-01-01';
- 确认当前值：
SELECT @@session.read_buffer_size; - 如果非得改全局，先算好最大连接数：
max_connections × read_buffer_size ≤ 总内存 × 10%，再用SET GLOBAL（注意：部分版本要求 SUPER 权限，且重启后失效）
常见错误现象和排查线索
调了 read_buffer_size 却没效果？大概率不是它的问题。典型误判场景：
- 执行计划显示
type: ALL但实际走了索引覆盖（Extra: Using index）→ 缓冲区根本不用 - 慢查询日志里出现
Using temporary; Using filesort→ 该查sort_buffer_size或优化ORDER BY - ERROR 1038 (HY001): Out of sort memory → 和
read_buffer_size无关，是排序内存炸了 - show processlist 看到大量
Copying to tmp table→ 重点看tmp_table_size和max_heap_table_size
和 read_rnd_buffer_size 的区别在哪？
很多人把这两个搞混。read_buffer_size 用于**顺序读**（从磁盘连续读数据页），而 read_rnd_buffer_size 用于**随机读**（比如排序后回表取字段，按主键 ID 乱序访问聚簇索引）。
如果你的查询有 ORDER BY ... LIMIT + 非覆盖索引，或者 JOIN 后需要回表，read_rnd_buffer_size 才可能成为瓶颈。
- 两者默认值相同，但调整逻辑独立
-
read_rnd_buffer_size在 8.0.22+ 版本已废弃，由优化器自动管理，不建议手动设 - 检查是否启用随机读优化：
SELECT @@optimizer_switch LIKE '%read_rnd_buffer_size%'
实际调参时，最常被忽略的是：它只对没有合适索引的全表扫描起作用，而这类查询本身就应该被优化掉。留着 128KB，把 EXPLAIN 搞明白，比硬调缓冲区靠谱得多。
