MySQL高并发核心瓶颈是连接数、锁竞争、IO瓶颈和主从延迟；需按读多、写多或读写混合场景差异化优化，重点防控锁冲突、死锁及主从延迟。
MySQL 高并发场景下的核心瓶颈在哪？
高并发下 MySQL 的压力主要来自连接数、锁竞争、IO 瓶颈和主从延迟。不是 CPU 或内存先扛不住，而是连接池打满、行锁升级成表锁、慢查询堆积、binlog 写入跟不上提交速度，导致事务排队甚至超时。关键要分清是读多、写多，还是读写混合——不同场景优化路径差异很大。
如何避免高并发下的锁冲突和死锁？
死锁本质是多个事务循环等待对方持有的锁。常见诱因包括：非固定顺序访问多张表、长事务、在事务中做耗时操作（如调用外部接口）、没走索引导致锁住全表。预防重点有：
- 确保所有事务按相同顺序操作表和行（比如统一先更新 user，再更新 order）
- 尽量缩短事务时间，DML 后尽早 commit，避免在事务里做日志打印、RPC 调用等
- UPDATE/DELETE 必须走索引，否则会升级为间隙锁或表锁；可通过 EXPLAIN 和 SHOW ENGINE INNODB STATUS 查看实际加锁范围
- 业务层对热点数据（如账户余额、库存）采用“先扣后查”或版本号控制，减少重试次数
读多写少场景下怎么扛住流量？
典型如商品详情页、资讯列表。核心思路是分层减压：
- 应用层加缓存（Redis），把高频只读结果缓存，设置合理过期+主动更新策略，避免缓存雪崩/穿透
- 数据库层做读写分离，但要注意主从延迟带来的脏读问题；强一致性读走主库，最终一致性读走从库
- 必要时拆分查询：大字段、历史数据、统计汇总单独建表或归档，主表只留核心字段
- 用 SELECT ... FOR UPDATE 要极度谨慎，优先考虑乐观锁（version 字段 + CAS 更新）
写多场景下如何保障性能与一致性？
比如秒杀下单、支付流水、IM 消息写入。单库单表极易成为瓶颈，需组合手段：
- 分库分表：按用户 ID 或订单号做 hash 或 range 拆分，避开单点写入热点
- 异步化：非核心写操作（如日志记录、通知推送）通过消息队列削峰，数据库只处理核心事务
- 批量写入：合并多次 INSERT 为 INSERT INTO ... VALUES (...), (...), (...)，减少网络往返和事务开销
- 调整 innodb_flush_log_at_trx_commit=2（牺牲极小可靠性换吞吐），配合 sync_binlog=0 或 1000 平衡主从安全与性能
主从延迟大了怎么办？
延迟本质是备库 SQL 线程单线程回放 binlog 跟不上主库并发写入。解决方向分三类：
- 治标：监控延迟（Seconds_Behind_Master），自动切读流量到主库；或让应用根据业务容忍度决定是否强制走主库
- 治本：升级 MySQL 到 5.7+，开启 slave_parallel_workers > 1，利用逻辑时钟（MTS）并行回放
- 源头优化：减少大事务（比如一次删百万行拆成多次）、避免长事务、控制单条语句影响行数
有没有推荐的线上排查工具链？
别只靠 show processlist。真实高并发问题需要多维度交叉验证：
- slow log + pt-query-digest：定位慢查询及其执行频次、平均耗时、锁等待时间
- performance_schema：查锁等待（data_lock_waits）、IO 延迟（file_summary_by_event_name）、语句执行阶段耗时
- innotop / mysqladmin debug：实时看 InnoDB 状态、事务列表、锁信息
- 配合应用 APM（如 SkyWalking）追踪 SQL 调用链，确认是 DB 慢还是网络/连接池/代码逻辑拖慢
