MyISAM在真实高并发读场景下性能常低于调优后的InnoDB，因其表级锁易阻塞、OS文件缓存不可控、索引与数据分离导致CPU和IO负担加重，而InnoDB通过行锁、Buffer Pool统一管理及异步机制更适应高并发。
因为MyISAM的“读快”只在单线程、无锁竞争、无缓存抖动的真空环境下成立；真实高并发读场景下，它的表级锁机制、OS文件缓存不可控、索引与数据分离结构，反而让CPU和IO更忙，QPS常低于调优后的InnoDB。
MyISAM表级锁在高并发读时会意外阻塞查询
很多人忽略一个事实：MyISAM的READ LOCK虽允许多个并发读，但只要有一个写操作（哪怕只是INSERT DELAYED或REPAIR TABLE）排队，所有后续读请求都会被挂起等待——状态变成Waiting for table level lock。而InnoDB的普通SELECT是快照读，不加锁，完全不参与行锁等待队列。
- 现象：
SHOW PROCESSLIST里大量Locked或Waiting for table level lock，但Threads_running不高，CPUsy（system time）偏高 - 原因：MySQL内核需频繁调度线程检查锁状态，而非真正执行SQL
- 对比：
INFORMATION_SCHEMA.INNODB_TRX中几乎看不到对应锁等待记录，因InnoDB行锁释放极快
MyISAM依赖OS page cache导致IO抖动加剧CPU负担
MyISAM只缓存索引（key_buffer_size），数据文件（.MYD）全靠操作系统page cache管理。高并发随机读时，.MYD块反复换入换出，触发大量缺页中断和dirty page回写调度，CPU被迫频繁处理内存管理逻辑。
- 典型指标：
Key_reads飙升但Key_read_requests增长缓慢 → 索引缓存命中率崩塌 - perf top可见
__GI___libc_read和try_to_unmap占比异常高 - InnoDB则统一由
innodb_buffer_pool管理热数据页，LRU策略可控，预读+change buffer合并均为后台异步动作
InnoDB在读密集负载下可通过配置逼近甚至反超MyISAM
不是InnoDB“天生快”，而是它把原本消耗CPU的同步行为转为可控的批量/异步处理。关键配置不调，InnoDB读性能照样拉胯。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 从库必须设
read_only=ON（防误写），并关闭innodb_flush_log_at_trx_commit=2和sync_binlog=0（非金融类业务） - 大只读表可用
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩率40%+，比MyISAM压缩表更安全且支持索引 - 启用
innodb_read_io_threads=4+innodb_read_ahead_threshold=56，提升顺序扫描和范围查询吞吐 - 避免在从库跑
ANALYZE TABLE——它会持MDL写锁，瞬间堵死所有查询
MyISAM的COUNT(*)优势在真实读写分离中根本不存在
MyISAM快是因为它把行数存在磁盘元数据里，SELECT COUNT(*) FROM t是O(1)；但读写分离场景下，你几乎不会只跑这个语句——一旦加WHERE，两者都得走索引或扫描，MyISAM反而因无MVCC、无覆盖索引优化而更慢。
- 实测：10万行用户状态表，在TPS 500+压测下，MyISAM从库CPU常飙至95%，InnoDB稳定在60%以下
-
SELECT COUNT(*) WHERE status = 1→ MyISAM仍需全表扫描匹配，InnoDB可走status索引+采样估算（innodb_stats_method=sampled） - MyISAM不支持主从复制一致性保障，主库若用InnoDB（99%情况），从库根本没法接MyISAM表，所谓“读快”前提就不存在
真正卡住性能的从来不是引擎名字，而是EXPLAIN里那个type: ALL，是SHOW ENGINE INNODB STATUS里反复出现的Lock wait timeout exceeded，以及vmstat中藏不住的sy飙升——这些信号，MyISAM不会报错，只会默默让你的QPS掉进坑里。
