myisam全表扫描导致cpu飙升，因其不支持行级缓存，需逐块读取.myd文件、解压行数据、过滤组装结果，所有解析与比较逻辑均由cpu完成；i/o仅触发计算，真正耗资源的是cpu密集型处理。
MyISAM全表扫描为什么CPU飙升
MyISAM引擎本身不支持行级缓存，每次查询都依赖操作系统页缓存和key_buffer_size；当执行SELECT *或无索引条件的WHERE扫描大表时，它必须逐块读取.MYD文件、解压行数据、过滤、组装结果集——所有这些都在CPU上完成，I/O只是触发器，真正耗资源的是解析与比较逻辑。
为什么调I/O调度器能缓解CPU压力
默认的cfq（或deadline）调度器在高并发随机读场景下会频繁合并/排序请求，反而增加内核调度开销；而noop或kyber（5.15+内核）更适配SSD+MyISAM顺序扫描模式：减少队列延迟、降低中断频率、让CPU更快进入批处理循环。
- 确认当前调度器：
cat /sys/block/nvme0n1/queue/scheduler - 临时切换（NVMe盘）：
echo kyber > /sys/block/nvme0n1/queue/scheduler - 永久生效需在
/etc/default/grub中追加nvme_core.default_ps_max_latency_us=0并update-grub
注意：机械盘仍建议用deadline，noop在高负载下可能加剧寻道抖动。
key_buffer_size设多大才不拖慢CPU
key_buffer_size只缓存.MYI索引文件，不缓存.MYD数据——所以即使设到物理内存50%，对无索引的大表扫描也几乎无效。但它直接影响索引查找速度：过小导致频繁重读索引块，引发额外CPU解压和指针跳转；过大则挤占系统页缓存空间，反而让.MYD读取更慢。
- 查当前索引总大小：
SELECT SUM(index_length) FROM information_schema.tables WHERE engine='MyISAM'; - 推荐值 = 索引总大小 × 1.2～1.5，上限不超过4GB（32位系统限制）
- 避免设为
4G硬上限：若实际索引仅800MB，盲目拉满会导致OS缓存失衡，top里看到mysqld%sy升高
比调参数更关键的三个事实
MyISAM在2026年已不是高吞吐场景的合理选择：它的表锁机制在并发扫描时会强制串行化，CPU空转等待锁释放；崩溃后修复REPAIR TABLE需全表重扫；且MySQL 8.4起已标记MyISAM为deprecated。如果业务仍依赖它做分析型查询，优先迁移至ColumnStore或ClickHouse接入层，而非在调度器和缓存上反复调优。
