优化索引与SQL执行计划，减少全表扫描和回表

数据库延迟最常见的来源是慢SQL。第一步应开启慢查询日志，并结合 performance_schema、pg_stat_statements 或 EXPLAIN ANALYZE 查看执行计划，关注扫描行数、返回行数、过滤比例以及是否出现全表扫描、临时表、文件排序。若发现索引失效，要检查函数包裹列、隐式类型转换、前导模糊匹配、OR条件使用不当等问题。建立联合索引时应遵循最左前缀原则，把选择性高、区分度大的列放在前面，并尽量让查询字段被索引覆盖，从而减少回表随机IO。对大分页查询，可用游标分页、延迟关联或基于上次最大ID继续读取，避免 LIMIT 偏移量过大。还要避免 SELECT *，只取必要列；把复杂子查询重写为 JOIN 或 UNION ALL；定期更新统计信息，防止优化器选错计划。对写多读少的表要控制索引数量，避免写放大。通过索引和SQL双管齐下，多数延迟可从秒级降至毫秒级。

构建多级缓存与读写分离，分流热点与读请求

当热点数据频繁查库，数据库IO和连接会被迅速打满。此时可引入本地缓存加分布式缓存的多级结构：本地缓存承担极热数据，Redis 承担跨节点共享数据。缓存设计要处理穿透、击穿和雪崩：布隆过滤器拦截不存在键，空值缓存短TTL，互斥锁或逻辑过期保证热点重建，TTL 加随机值避免同时失效。对一致性要求不高的读请求走从库，通过读写分离中间件或应用双数据源分流；但必须关注主从复制延迟，写后立即读的关键路径应强制走主库，或使用半同步复制、GTID、并行复制降低延迟。缓存更新推荐 Cache Aside：先更新数据库，再删除缓存，并结合延迟双删或订阅 binlog 异步失效，降低脏读概率。读写分离和缓存配合后，主库压力下降，P99延迟和连接等待都会明显改善。

治理连接池、锁等待与超时，消除阻塞链路

连接池配置不当会造成请求排队：太小导致应用线程等待连接，太大则让数据库线程切换和内存开销飙升。应依据 QPS、平均SQL耗时和数据库核数设置最大连接、最小空闲、连接超时、空闲回收时间，并监控活跃连接、等待线程和获取连接耗时。应用侧必须设置语句超时、事务超时和重试退避，避免慢查询长期占用线程池。数据库侧要排查锁等待和死锁，利用 information_schema.innodb_trx、performance_schema 或 pg_locks 找到阻塞源。缩短事务范围，避免大事务和长事务；按固定顺序更新多行，降低死锁概率；热点行更新可用排队、分段更新或乐观锁。隔离级别在允许时选择 RC，减少间隙锁。连接池、锁和超时治理需要联动，否则偶发延迟尖刺可能演变为雪崩。

推进异步批处理与全链路监控扩容，提升弹性吞吐

同步写链路越长，延迟越容易被下游放大。将非核心写异步化，使用 Kafka、RocketMQ 等消息队列削峰填谷；批量插入替代逐条 insert，开启 rewriteBatchedStatements、批量提交和合并小事务，可显著降低网络往返与日志刷盘次数。报表、统计类查询可走离线数仓、物化视图或预聚合表，避免影响在线交易。架构上根据业务做分库分表、冷热分离和历史归档，扩容时增加读副本、分片和代理层路由。可观测性同样关键：用 Prometheus 加 Grafana 监控 QPS、TPS、连接数、慢查询、锁等待、主从延迟和缓存命中率；用 OpenTelemetry 做全链路追踪，定位跨服务瓶颈；设置合理告警并定期压测。持续复盘慢日志，形成优化闭环，才能让数据库延迟长期稳定。