MySQL 8.0 可取代 MyISAM 实现高并发安全点查，关键在于合理设置 innodb_buffer_pool_size（建议物理内存60%–70%）、禁用无效参数（如 sort_buffer_size）、关闭死锁检测（仅限纯读场景）、善用 SKIP LOCKED/NOWAIT，并监控缓冲池命中率与等待指标。
MySQL 8.0 完全可以取代 MyISAM 实现更高并发、更安全的点查性能，但前提是放弃“直接照搬 MyISAM 配置”的思路——InnoDB 的点查优化不靠索引缓存单独调大，而靠缓冲池热数据驻留 + 精准预热 + 锁与日志策略协同。
innodb_buffer_pool_size 设多少才真正扛住点查压力
设太小（比如 1G）会导致每次点查都触发物理读，Innodb_buffer_pool_reads 持续上升；设太大（超过物理内存 75%）又会挤占 OS 缓存和连接线程内存，反而引发 swap 或连接拒绝。
- 初始值建议为物理内存的
60%–70%（例如 64G 机器设为40G），不是拍脑袋，而是让热数据集（如用户 ID → 用户信息主键查询）能长期驻留 - 必须监控
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)，真实命中率 ≥99%才算稳住点查底座 - 别信“调大就快”——如果点查集中在某几张表，盲目拉高缓冲池可能把冷数据页也带进来，反而挤走热页；此时应配合
innodb_buffer_pool_dump_at_shutdown=ON和innodb_buffer_pool_load_at_startup=ON做重启后自动预热
为什么 SET_VAR(sort_buffer_size=...) 对点查完全无效
点查（如 SELECT * FROM users WHERE id = ?）根本用不上 sort_buffer_size 或 join_buffer_size，这些是为 ORDER BY、GROUP BY、JOIN 等需要临时排序/关联的场景准备的。给点查强行加 /*+ SET_VAR(sort_buffer_size = 16M) */ 不仅没收益，还浪费 per-connection 内存。
- 点查真正依赖的是：主键或唯一索引是否覆盖查询字段、
innodb_buffer_pool_size是否容纳下索引 B+ 树的非叶节点 + 热数据页、以及innodb_flush_log_at_trx_commit是否为1（确保单条点查事务不丢） - 验证是否走索引：用
EXPLAIN SELECT * FROM users WHERE id = 123，看type是const或eq_ref，且key显示用了主键 - 若点查变慢，优先查
Innodb_buffer_pool_wait_free是否非零（说明缓冲池缺空闲页）、或SHOW ENGINE INNODB STATUS中SEMAPHORES下 wait array 是否积压
如何关闭死锁检测来提升高频点查吞吐
纯点查（只读）本身不涉及行锁竞争，但若业务混杂了写操作（如点查后紧跟 UPDATE），默认开启的 innodb_deadlock_detect 会在每个锁等待时构建 wait-for graph，带来毫秒级开销。对 QPS 过万的点查服务，这个开销可感知。
- 确认业务确实无写冲突：点查不带
FOR UPDATE、不跨事务持有锁、UPDATE 语句有确定主键且不产生间隙锁（如WHERE id = ?而非WHERE status = ?） - 动态关闭：执行
SET GLOBAL innodb_deadlock_detect = OFF，无需重启；但注意这会让真实死锁不再被自动终止，需应用层保证事务简短、顺序一致 - 不能只关全局：某些中间件或连接池会重置 session 变量，建议在应用初始化 SQL 中加上该设置，或在 my.cnf 中写入
innodb_deadlock_detect = OFF
为什么 skip locked + nowait 是点查高并发的隐藏开关
当点查用于抢购、库存扣减等场景（即 SELECT ... FOR UPDATE 后立刻 UPDATE），传统方式会因锁等待导致线程阻塞，QPS 上不去。MySQL 8.0 的 SKIP LOCKED 和 NOWAIT 让点查从“排队等锁”变成“立即返回可用行”或“立刻报错”，彻底释放连接资源。
-
SELECT * FROM stock WHERE item_id = 123 AND qty > 0 ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED：多个请求同时执行，各自拿到不同行，无锁等待 -
SELECT * FROM orders WHERE user_id = 456 FOR UPDATE NOWAIT：若已被锁，直接报错ERROR 3572 (HY000): Statement aborted because lock(s) could not be acquired immediately，应用可快速重试或降级 - 注意：这两个语法只对
SELECT ... FOR UPDATE/LOCK IN SHARE MODE生效，普通点查不用加
InnoDB 点查性能的瓶颈从来不在 SQL 写法本身，而在缓冲池能否稳住热数据、锁机制是否被误用、以及你是否意识到 MySQL 8.0 已经把“等待”这件事从内核里抽出来交给你控制。跳过 MyISAM 式的粗放调优，盯住 Innodb_buffer_pool_read_requests、Innodb_buffer_pool_wait_free、innodb_deadlock_detect 这几个真实指标，比调一百个 buffer 参数都管用。
