全表扫描无法加速，但可降低代价：关键在精准控制缓冲区策略而非盲目调大参数；read_buffer_size仅对MyISAM顺序扫描有效，InnoDB影响有限；read_rnd_buffer_size主要支撑MRR和排序回表，需结合EXPLAIN与Handler状态验证效果；根本优化应优先索引、分区与SQL改写。
全表扫描本身无法“加速”，但能减少其代价——关键在控制缓冲区分配策略，而不是盲目调大 read_buffer_size 和 read_rnd_buffer_size。
什么时候该调 read_buffer_size？
这个参数只在真正发生顺序扫描（type=ALL）且无法走索引时起作用。它为每个线程分配一块连续内存，用于批量读取数据页。但注意：
- 它对 InnoDB 表影响有限——InnoDB 自己用
innodb_read_io_threads和缓冲池管理读取，不怎么依赖这个变量 - MyISAM 表才真正靠它提升顺序扫描吞吐，比如
SELECT * FROM logs WHERE date > '2025-01-01'没索引时 - 默认 128KB 太小，但设到 64MB 就危险：每并发 100 个扫描线程，光这一项就吃掉 6.4GB 内存
- 值必须是 4KB 倍数，否则自动向下舍入；最大允许 2GB，但 Linux 下超过 2MB 可能触发慢速内存分配路径
建议：全局保持默认或设为 512KB～2MB，仅对明确需要跑大范围 MyISAM 扫描的会话临时加大：SET SESSION read_buffer_size = 8388608;
read_rnd_buffer_size 实际影响哪些场景？
它不只用于“随机读”，更关键的是支撑 MRR（Multi-Range Read）优化和排序后回表——尤其当 EXPLAIN 显示 Using filesort + Using where 时：
- ORDER BY 非索引字段后需回表取数据，MySQL 会先排好主键/行指针，再按
read_rnd_buffer_size分批顺序读基表 - MRR 启用时（
optimizer_switch='mrr=on'），这个 buffer 决定每次批量回表的行数 - 值太小 → 回表次数多、磁盘随机 IO 高；值太大 → 单次内存占用高、可能触发 swap
- 它是会话级变量，全局设大等于给所有连接加压，不推荐
典型配置：全局留 256KB，对含 ORDER BY ... LIMIT 的报表类查询，在执行前设 SET SESSION read_rnd_buffer_size = 4194304;（4MB）即可
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么调了也没效果？常见误判点
很多 DBA 调完发现 Sort_merge_passes 或 Handler_read_rnd_next 没降，问题往往不在缓冲区本身：
-
read_buffer_size不影响索引扫描（type=range/ref），只管全表扫；确认EXPLAIN的type真是ALL -
read_rnd_buffer_size对没有排序、没启用 MRR、或使用覆盖索引的查询完全不生效 - 真正瓶颈可能是磁盘 IO（尤其是机械盘）、buffer pool 不够、或查询本身返回太多行导致网络/应用层卡住
- MySQL 8.0+ 默认启用 MRR，但若
read_rnd_buffer_size小于 1MB，MRR 可能被自动禁用
验证是否生效：查 SHOW SESSION STATUS LIKE 'Handler_read%';，重点看 Handler_read_rnd_next 是否下降，而非只盯配置值
比调参更有效的替代方案
缓冲区只是补救手段。绝大多数生产环境的“慢全表扫描”，根因不在内存分配，而在设计层面：
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0.16+）看是否真绕不开全表扫；如果possible_keys有值但key为空，优先检查隐式类型转换或函数包裹 - 小表（1GB）还扫，说明索引或分区缺失
-
ANALYZE TABLE更新统计信息，避免优化器误判索引选择率 - 对时间范围查询，优先考虑按月分区 + 子查询下推，比调
read_rnd_buffer_size管用十倍
缓冲区参数是手术刀，不是止痛药。调它们之前，先确认是不是真的需要动刀——还是说，那张表早该加索引、拆分区、或者换个查询写法了。
