数据库高并发优化核心在于分层防御、精准减压和结构适配：读写分离动态路由、连接池精细调控（如HikariCP+合理超时与检测）、多级缓存协同（本地Caffeine+Redis+布隆过滤器防穿透）、SQL与表结构面向并发重构（乐观锁、分表ID统一分配、大字段拆分）、关键操作异步化（RocketMQ事务消息）及接口层Sentinel降级兜底。
数据库高并发访问优化不是堆配置或加机器就能解决的事，核心在于分层防御、精准减压和结构适配。重点不在“扛住多少QPS”，而在于让每次访问尽可能快、少、稳。
读写分离与连接池精细调控
主库只负责写，从库分担读压力，这是基础但关键的分流手段。不能简单配一主多从就完事——要结合业务读写比动态路由，比如报表类查询走专用从库，实时订单状态查主库加读已提交隔离级别。连接池必须脱离默认配置：
• 最大连接数别盲目设大，按平均并发请求×1.5再结合DBA建议值设定
• 空闲连接超时控制在30–60秒，避免长连接堆积
• 启用连接有效性检测（如testOnBorrow），但避免高频ping语句拖慢响应
• 优先选用HikariCP而非Druid，实测在2000+并发下连接获取延迟低40%以上
缓存穿透防护与多级缓存协同
缓存不是万能解药，用不好反而放大问题。高频Key必须做本地缓存（Caffeine）+分布式缓存（Redis）两级：本地缓存抗90%重复读，Redis兜底并承担跨节点共享。针对穿透风险：
• 布隆过滤器前置拦截非法ID查询，内存开销仅百KB级
• 空值也缓存（带短TTL），防止恶意刷空查询打穿DB
• 热Key自动探测+散列拆分，比如用户订单列表按分页哈希成order_12345_page1、page2…避免单Key锁竞争
SQL与表结构面向并发重构
很多慢查源于设计阶段没考虑并发语义。例如：
• 避免在高并发路径上使用SELECT FOR UPDATE全表扫描式加锁，改用乐观锁（version字段）或基于唯一索引的条件更新
• 用户中心类表，按ID取模分表后，务必禁用自增主键，改用雪花算法或数据库号段服务统一分配ID
• 写多读少场景（如日志、消息记录），直接上MySQL Archive引擎或转存到ClickHouse，别硬扛在OLTP库上
• 大字段（如JSON详情）独立成扩展表，主表只留关键索引字段，减少行锁粒度和缓冲区压力
异步化与削峰填谷落地要点
不是所有操作都得实时落库。把非强一致动作抽离：
• 订单创建成功后，库存扣减、积分发放、通知推送等通过RocketMQ异步处理
• 使用事务消息保证最终一致性，避免本地事务+MQ发送的两阶段失败风险
• 对统计类写入（如PV/UV聚合），先写内存计数器（ConcurrentHashMap + LongAdder），定时批量刷库
• 接口层接入Sentinel，在DB负载超阈值时自动触发降级，返回缓存数据或静态兜底页，保主链路不雪崩
