调 read_buffer_size 对大表扫描几乎没用，除非你用的是 myisam 且真在做无索引全表扫——innodb 基本不走它；盲目调大反而容易触发 oom。
调 read_buffer_size 对大表扫描几乎没用，除非你用的是 MyISAM 且真在做无索引全表扫——InnoDB 基本不走它；盲目调大反而容易触发 OOM。
为什么改了 read_buffer_size 却没提速？
因为真正起作用的场景非常窄：
- EXPLAIN 显示
type: ALL，且Extra没有Using index（即非覆盖索引） - 表引擎是 MyISAM —— InnoDB 的顺序读由
innodb_buffer_pool_size和预读机制控制，几乎不依赖这个参数 - 查询确实没走任何索引，又必须扫完整张表（比如归档导出、历史数据清洗）
- 服务器内存充足，且并发连接数很低（否则每连接多占几 MB，积少成多）
常见误判：看到慢查询日志里有 Using filesort 或 Using temporary，就去调 read_buffer_size —— 这俩和它完全无关，该查 sort_buffer_size 或 tmp_table_size。
read_buffer_size 和 read_rnd_buffer_size 到底谁管啥？
别混用，它们服务完全不同的读模式：
-
read_buffer_size：只用于**顺序读**，比如从头到尾扫一个没索引的 MyISAM 表。对 InnoDB 全表扫描影响微乎其微 -
read_rnd_buffer_size：用于**排序后回表**或 **MRR（Multi-Range Read）** 场景，典型如ORDER BY non_index_col LIMIT 100+ 非覆盖索引 → MySQL 先排好主键，再按主键批量回聚簇索引取字段 - 两者都是会话级变量，
SET SESSION才生效；全局设大 = 给每个新连接加压，风险极高
验证是否生效？看状态变量：SHOW STATUS LIKE 'Handler_read%'; 中 Handler_read_rnd_next 下降才说明 read_rnd_buffer_size 起效；Handler_read_next 变化才和 read_buffer_size 有关。
怎么设才安全、有效？
记住三条铁律：
- 全局值保持默认（
131072），或最多设为524288（512KB）；超过 2MB 官方明确说“收益趋零”，Linux 下还可能触发慢分配路径 - 真要跑大范围 MyISAM 全扫，只在当前会话临时加大：
SET SESSION read_buffer_size = 8388608;（8MB），执行完即丢 - 值必须是 4KB 倍数，否则自动向下舍入；比如设
1000000，实际生效的是999424 - 别碰
my.cnf全局配置——改了要重启，且高并发下max_connections × read_buffer_size很快吃光内存
最后提醒一句：如果你的表是 InnoDB，且 EXPLAIN 显示 type: ALL，第一反应不该是调缓冲区，而是立刻检查有没有漏建索引、WHERE 条件是否隐式类型转换、或者是不是用了函数导致索引失效——这些才是根因。
