分布式数据库一旦进入高并发写入和实时读取并存的场景，单纯增加节点往往不能解决延迟升高和吞吐下降的问题。核心瓶颈通常不在硬件资源，而在数据分片策略、事务隔离级别、索引设计以及跨节点通信这四个环节。先把写入热点找出来，再调整数据分布，比盲目扩容更有效。
拆分热点键与写入扩散
高并发下最容易出问题的是单分片热点。比如订单表如果直接用用户ID做分片键，遇到大促时少数几个大客户账号可能产生数倍于普通用户的写入量，导致某个分片CPU和磁盘IO被打满。解决方法不是把分片键换成时间戳，而是对热点键做二次拆分。可以在业务层为热点用户生成多个逻辑桶，例如用户ID后拼接随机数0到9，写入时随机选择一个桶，读取时对十个桶并发查询再合并。这样单个逻辑分片的压力立刻下降到原来的十分之一左右。
另一种方式是针对时序数据做分区滚动。日志、流水、监控类表如果按时间做范围分片，写入会集中在最新时间对应的分片上。可以将时间分片粒度从按天改为按小时，并配合预创建分区，避免分区自动分裂时的锁竞争。同时开启数据库的批量提交，把单条insert合并成每批500到1000条，能显著降低网络往返和事务日志刷盘次数。
降低锁竞争与事务冲突
高并发下事务冲突带来的锁等待往往比SQL本身更耗时。很多业务并不需要可重复读或串行化隔离级别，但默认配置却使用了较高的隔离级别。将读已提交作为默认级别，配合乐观锁或版本号字段，可以让大量并发更新同一行时减少死锁概率。更新语句写成条件更新，例如“update account set balance=balance-100, version=version+1 where id=123 and version=5”，失败后由应用层重试，而不是让数据库持有行锁等待。
对于需要多行操作的场景，尽量保证所有事务以相同的顺序访问行。比如转账操作如果事务A先锁账户1再锁账户2，事务B先锁账户2再锁账户1，就很容易死锁。统一按账户ID升序加锁，能消除大部分死锁。分布式数据库的全局死锁检测本身也有开销，减少死锁发生比依赖检测机制更划算。
索引与查询路径优化
高并发下索引维护的成本会被放大。每多一个二级索引，写入时就要多一次索引更新，并且分布式数据库中二级索引可能跨节点通信。建议对写入频繁的表只保留必要的索引，把复杂的查询需求转移到异步构建的物化视图或搜索引擎中。联合索引的列顺序要按等值查询优先、范围查询靠后的原则设计。例如查询条件是“where status=1 and create_time>某个时间 order by create_time”，索引应该建在(status, create_time)上，而不是(create_time, status)。
分页查询在高并发下不要使用大offset。offset 100000 limit 20这种写法会让数据库扫描并丢弃前十万行，分片场景下还要跨节点汇总排序。改用游标分页，记录上一页最后一条的主键或排序字段，下一页用“where id>上一页最后id order by id limit 20”。这样每次只扫描固定行数，延迟稳定且不随页数增长。
跨节点通信与网络开销控制
分布式数据库的跨节点数据交换是延迟的重要来源。关联查询如果涉及不同分片上的表，数据库需要把数据拉到协调节点做join，数据量大时网络传输会变成瓶颈。解决办法是让需要频繁关联的数据落在同一个分片。例如订单表和订单明细表都使用订单ID作为分片键，这样同一个订单的主表和子表数据在同一个物理节点上，join操作可以本地完成，不需要跨节点搬数据。
对于确实需要跨节点聚合的统计类查询，不要把原始明细拉到协调节点。利用数据库的下推能力，把聚合操作下推到各个分片执行，只返回局部聚合结果。比如count和sum可以在分片先算好，协调节点只做二次汇总。如果数据库支持，使用并行查询让多个分片同时执行，而不是串行扫描。
连接池与批量处理调优
应用层连接池配置不当会直接限制并发能力。连接数设得太小，请求在应用端排队；设得太大，数据库端线程切换和锁竞争加剧。通常每个应用实例的连接池大小设置为数据库最大连接数除以实例数量，再留出20%余量。同时开启连接池的空闲连接回收和泄漏检测，避免长时间占用连接不释放。
批量操作是提升吞吐最直接的手段。对于日志采集、数据同步这类场景，把单条insert改成批量insert，每批1000条左右，吞吐可以提升数倍。但批量不能无限大，过大的批次会导致单次事务过长，占用undo日志和锁的时间增加，反而影响并发。批量更新时也要注意不要一次更新过多行，避免长时间持有行锁阻塞其他事务。
读写分离与缓存策略
高并发读场景下，把读请求分流到只读副本可以减轻主节点的压力。但分布式数据库的只读副本存在复制延迟，如果业务对实时性要求高，需要把刚写入的数据从主节点读取，其他数据从副本读取。可以在应用层做标记，写入后短时间内强制走主库，超过一定时间后再走副本。
缓存能挡住大量重复读请求，但缓存更新策略要避免缓存穿透和雪崩。对于热点数据，使用本地缓存加分布式缓存两级结构，本地缓存设置很短的过期时间，比如3到5秒，既能挡住极端热点，又能保证数据基本新鲜。缓存key的设计要包含版本号，数据变更时更新版本号让旧缓存自然失效，而不是主动删除缓存导致瞬时回源压力。
监控与容量规划
优化不能靠猜，需要监控数据支撑。重点监控每个分片的CPU使用率、磁盘IO等待时间、慢查询数量、锁等待次数和网络流量。当某个分片的指标明显高于其他分片时，说明存在数据倾斜或热点。分布式数据库通常提供分片级别的监控视图，可以快速定位问题分片。
容量规划要留出足够的余量。当整体CPU使用率持续超过60%或磁盘IO利用率超过70%时，就应该考虑扩容，而不是等到资源耗尽。扩容时优先增加分片数量，让数据重新分布，而不是只增加副本。副本增加只能提升读能力，对写入吞吐没有帮助。
实际调优顺序建议
先处理写入热点和锁竞争，因为这两类问题在高并发下影响面最大，且优化后效果立竿见影。然后优化慢查询和索引，减少资源占用。接着调整连接池和批量参数，提升吞吐上限。最后完善缓存和读写分离策略，进一步降低数据库压力。每一步优化后都要用压测工具验证，对比优化前后的吞吐、延迟和错误率，避免某个调整在低并发下有效但在高并发下反而恶化。
分布式数据库的高并发处理没有银弹，需要根据业务特征和数据分布持续调整。关键是建立分片级监控，让数据分布和访问模式尽量均匀，减少跨节点交互，把数据库的并行能力真正发挥出来。
