海外用户反馈页面慢，不等于数据库副本不够。面向海外用户的数据库读写延迟优化，第一步应判断时间花在网络往返、连接建立、SQL 执行还是数据复制上。若应用服务器和数据库相隔较远，新增副本可能改善部分读取，却未必缩短写入。
先拆开看：延迟究竟在哪一段
一次请求可能经过用户设备、应用服务器和数据库。记录应用侧总耗时，并分别观测数据库连接耗时、SQL 执行时间及返回数据量；按地区、接口和读写类型分组查看 p50、p95、p99。平均值容易掩盖少数很慢的请求，最好同时对照数据库自身的查询日志或性能指标。
跨洲网络的往返时间（RTT）会受距离、运营商路由、拥塞和传输协议影响，可能从数十毫秒到更高，不能只凭地理距离推定。可以从实际用户所在区域发起测试，并在应用服务器上对数据库地址进行受控的连接与查询测试；不要把单次 ping 结果当作业务读写耗时。
优化链路：先减少每次请求的固定成本
如果慢请求主要卡在连接或往返次数，优化链路通常比加副本更直接，且不必引入新的数据一致性问题。建议按以下顺序处理：
- 确认应用与数据库位置。检查请求实际落到哪个应用区域、连接的是哪个数据库节点。用户访问附近的应用服务器，并不代表数据库也在附近；应用到数据库的跨区调用仍会产生额外往返。
- 复用连接。为应用配置合适的连接池，避免每次请求都新建 TCP/TLS 连接。池大小应结合并发量、数据库连接上限和应用实例数调整，过大可能挤占数据库资源。
- 减少数据库往返。检查是否逐条查询，或先取出大量数据再在应用端筛选。合并可合并的查询、分页限制返回量，并用执行计划核实索引是否有效；以 PostgreSQL 或 MySQL 为例，可从慢查询日志和对应的执行计划入手。
- 测量并回归。在相同地区、相近负载下比较优化前后的 p95 和错误率，同时确认查询结果一致、数据库负载没有明显转移。
这些措施适用于读写都慢、建连时间占比高，或单次业务请求需要多轮数据库交互的情况。它们无法消除用户到数据库之间的物理距离，但常能减少不必要的往返和处理工作。
加副本：改善特定区域的读取，不是通用加速器
在海外区域部署只读副本，适合读请求占比较高、数据允许短暂滞后的系统。将可接受旧数据的查询路由到附近副本，能缩短应用到数据库的距离；但写请求通常仍要到主库。若业务要求写后立即读到最新值，就需要明确读写路由规则，必要时让这类读取继续访问主库。
异步复制可能产生复制延迟，副本读到的数据因此落后于主库；同步跨地域提交则可能把远距离网络往返加入写入路径，并增加可用性与故障切换设计的复杂度。副本还需要额外的计算、存储、网络和监控资源。它不能修复低效 SQL，也不能自动解决单一主库的写入瓶颈。
| 方案 | 更适合 | 主要代价或限制 |
|---|---|---|
| 优化连接与查询链路 | 建连慢、往返次数多、SQL 执行低效 | 收益取决于瓶颈；不能突破跨洲网络的物理距离 |
| 增加区域只读副本 | 海外读取量大，且部分查询可容忍复制延迟 | 增加资源与运维成本；写入通常仍受主库位置影响 |
| 调整应用部署或数据架构 | 请求普遍受跨区调用影响，或写入也有严格时延要求 | 需要评估数据一致性、故障切换及改造成本 |
按证据做决定，而不是先扩容
- 选取慢的真实业务请求，记录用户区域、应用区域、读写类型及分段耗时。
- 检查连接池、慢查询、执行计划、返回数据量和数据库负载，先排除可修复的连接与 SQL 问题。
- 若瓶颈集中在应用到数据库的网络往返，先评估应用部署位置和请求交互次数；若主要是大量可容忍短暂滞后的读取，再测算只读副本的收益。
- 小范围验证读写路由、复制延迟、故障时行为和成本。通过一致性要求的测试后，再逐步扩大流量，并保留回退路径。
判断标准可以很直接：读写都慢，优先查链路和查询；只有海外读取慢、读流量占比较高且业务允许短暂滞后，才优先评估副本；写入慢则重点检查写路径、主库负载和跨区提交。面向海外用户的数据库读写延迟优化，核心不是副本数量，而是让观测结果对应到合适的改动。
常见问题
加只读副本会让写入也变快吗？
通常不会。写入若仍由远端主库处理，主要写路径没有改变；同步复制还可能增加提交等待。
副本有复制延迟，还能用于业务读取吗？
可以，但要按业务定义可接受的滞后范围。账务确认、写后立即查看等场景应谨慎，必要时从主库读取。
先优化链路还是先做读写分离？
先测分段耗时。连接或查询问题优先优化链路；确认瓶颈是跨区读取，且读取可容忍滞后，再采用读写分离。
应该比较哪些指标？
至少比较分地区的 p95、p99、错误率、数据库负载和复制延迟，并在相近负载与同一业务路径下评估。