只读实例并发瓶颈源于MySQL 8.0默认配置未适配纯只读场景，需调优innodb_thread_concurrency、启用线程池、关闭binlog与写相关开销、优化缓冲池参数，并避免SELECT...FOR SHARE引发隐式锁争用。
只读实例的并发查询能力瓶颈，往往不在SQL本身，而在MySQL 8.0默认配置对只读负载的“无感适配”——它仍按通用读写混合场景设计，很多参数没为纯只读压测过。
调整 innodb_thread_concurrency 和线程池策略
MySQL 8.0默认 innodb_thread_concurrency=0，看似自动管理，实则在高并发只读下易触发内部争用。尤其当大量 SELECT 持有共享锁（如 READ-COMMITTED 下的 consistent read）时，线程调度反而变保守。
- 对只读实例，建议显式设为
innodb_thread_concurrency=32或64（不超过CPU核心数×2），避免InnoDB内部线程排队阻塞 - 必须开启线程池：在
my.cnf中配置thread_handling=pool-of-threads（MySQL 8.0.14+ 支持），否则每连接一个线程，高并发下线程创建/销毁开销会吃掉大量CPU - 配套调大
thread_cache_size至64或更高，减少线程反复分配成本
关闭写相关开销，释放资源给只读路径
只读实例不需要处理事务提交、binlog写入、redo刷盘等动作，但默认配置仍保留这些逻辑链路，徒增判断和上下文切换。
- 设
innodb_flush_log_at_trx_commit=2—— 虽然只读不提交，但某些隐式事务或XA操作仍可能触发日志写，设为2可跳过强制刷盘路径 - 禁用 binlog：
log_bin=OFF（即使主从复制已通过log_slave_updates=1开启，只读实例自身无需生成binlog） - 关闭 query cache（已移除）不用管，但确认
query_cache_type=0且query_cache_size=0，避免残留逻辑干扰 -
skip_log_bin必须显式加上，防止某些DDL语句（如CREATE TEMPORARY TABLE）意外触发binlog检查
优化缓冲池与读取局部性
只读流量通常具备强访问局部性（比如热点用户数据、聚合报表缓存区间），但默认 innodb_buffer_pool_instances=8 在小规格实例上反而增加分片锁竞争。
- 若实例内存 ≤32GB，设
innodb_buffer_pool_instances=1；≥64GB 可设为16，避免多实例间同步开销 - 开启预热：确保
innodb_buffer_pool_dump_at_shutdown=ON和innodb_buffer_pool_load_at_startup=ON，重启后快速恢复热点页 - 对固定报表类查询，可配合
innodb_old_blocks_pct=20和innodb_old_blocks_time=2000，把扫描类临时结果更早踢出热区，保护高频点查页不被挤出
避免 SELECT ... FOR SHARE 引发的隐式锁升级
业务代码里常误用 SELECT ... FOR SHARE 声明“我只是读”，但在 READ-COMMITTED 隔离级别下，这会申请 record lock，导致并发读之间互相等待——本质是“只读锁”变成了“读写锁”。
- 除非明确需要防止其他事务修改当前行（比如读后再更新），否则一律改用普通
SELECT - 检查慢查询日志中是否频繁出现
Waiting for table level lock或Waiting for global read lock，这类等待往往源于FOR SHARE+ 大范围扫描 - 用
performance_schema.data_locks实时查锁持有情况：SELECT * FROM performance_schema.data_locks WHERE LOCK_MODE LIKE '%S%';，确认是否存在非预期的共享锁堆积
真正卡住只读并发的，常常不是单条SQL慢，而是几十个 SELECT 同时在等同一个 buffer pool mutex、或同时尝试分配线程、或因一个 FOR SHARE 扫描把整张表的二级索引页锁住。优化方向得从“让SQL更快”转向“让MySQL更愿意并发执行这些SQL”。
