建议从连接池、TTL、低峰期切换三方面优化。

先定位再处理，不要直接动槽：1) 查询 SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained FROM pg_replication_slots; active=false 且 retained 很大、restart_lsn 长时间不动的槽就是元凶。2) 用 SELECT pid, state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication; 确认是否还有 walsender 在推进；再和下游负责人确认订阅是否已停用。3) 确认下游不再需要后，在业务低峰停用该复制槽（RDS 控制台或 SQL 函数），并同步通知下游。停用只影响该槽，不会改动已有表数据；但如果下游还保留订阅并尝试重连，会因槽不存在而报错，需要下游重建订阅并做一次全量同步。4) 之后检查 wal_keep_size、max_slot_wal_keep_size（PG13+）等参数，给复制槽设置上限，避免再次撑满。RDS 上建议同时打开磁盘告警。

建议从连接池、TTL、低峰期切换三方面优化。

先定位再处理，不要直接动槽：1) 查询 SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained FROM pg_replication_slots; active=false 且 retained 很大、restart_lsn 长时间不动的槽就是元凶。2) 用 SELECT pid, state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication; 确认是否还有 walsender 在推进；再和下游负责人确认订阅是否已停用。3) 确认下游不再需要后，在业务低峰停用该复制槽（RDS 控制台或 SQL 函数），并同步通知下游。停用只影响该槽，不会改动已有表数据；但如果下游还保留订阅并尝试重连，会因槽不存在而报错，需要下游重建订阅并做一次全量同步。4) 之后检查 wal_keep_size、max_slot_wal_keep_size（PG13+）等参数，给复制槽设置上限，避免再次撑满。RDS 上建议同时打开磁盘告警。

建议从连接池、TTL、低峰期切换三方面优化。

函数索引要求查询表达式与索引表达式在类型和写法上可被优化器判定为等价，否则不会使用。几个检查点：1) 索引建在 CAST(... AS CHAR(32)) 上，查询侧最好写成同样的表达式，例如 WHERE CAST(ext->>'$.city' AS CHAR(32))='杭州'，或者直接用等价的生成列 + 普通索引。2) 用 EXPLAIN FORMAT=JSON 看 possible_keys 是否包含 idx_city；如果包含但没选，检查过滤性（优化器可能认为全表扫描更便宜），可以强制 FORCE INDEX(idx_city) 做对比。3) JSON 值类型不一致会影响表达式结果：数字 123 和字符串 '123' 的 ->> 返回类型不同，而索引按固定类型排序，类型转换后可能无法匹配。建议在写入侧统一 city 为字符串，或在生成列里显式 CAST 并固定长度。4) 注意字符集/排序规则：索引表达式与查询条件的 collation 必须一致，否则也会失效。建议改成 STORED 生成列 city varchar(32) GENERATED ALWAYS AS (ext->>'$.city') STORED 再建普通索引，可读性和可控性更好。

建议从连接池、TTL、低峰期切换三方面优化。

从现象看更像是 SQL thread 单线程回放 + 大事务导致的，IO thread 一般不是瓶颈。建议这样定位：1) 在只读实例执行 SHOW SLAVE STATUS，比较 Read_Master_Log_Pos 与 Exec_Master_Log_Pos：Read 追得快、Exec 明显落后，说明 relay log 已拉下来，卡在回放；同时看 Relay_Log_Space 是否持续增长。2) 查 performance_schema.replication_applier_status_by_worker 的 APPLYING_TRANSACTION、LAST_ERROR_MESSAGE、COUNT_TRANSACTIONS_RETRIES，再看 by_coordinator 是否在等大事务。3) 抓从库 SHOW PROCESSLIST 与 information_schema.innodb_trx/innodb_lock_waits，排除长事务和唯一键冲突。优化：把 5 万行再拆小（如每 500 行一个事务），避免超大 binlog event；从库开启 slave_parallel_type=LOGICAL_CLOCK 或 WRITESET、slave_parallel_workers 按核数设 4~8；主库确认 binlog_transaction_dependency_tracking=WRITESET。注意从库版本不要低于主库，也不要用 binlog 过滤规则过滤相关表。窗口内可临时 sync_binlog=0、innodb_flush_log_at_trx_commit=2 换吞吐，但异常时可能丢最近约 1 秒事务，导入后立刻改回 1。

建议从连接池、TTL、低峰期切换三方面优化。

读写分离代理通常按 SQL 语义 + 事务上下文路由，但临时表是会话级的，一旦 SELECT 被发到另一个节点就必然找不到表。可以从三方面确认和改造：1) 确认代理的路由规则：一般显式事务（BEGIN/START TRANSACTION 之后）、写语句（INSERT/UPDATE 等 DML 与 DDL）、SELECT ... FOR UPDATE 会强制走主节点；普通 SELECT 在自动提交下可能走只读节点。临时表相关语句建议直接走主地址。2) 临时表 + 读写分离本身就不匹配：即使同一连接，代理也可能把后续 SELECT 负载均衡到只读节点。最稳妥是这类会话固定走主库连接（单独数据源/直连主地址），或者改用普通表 + 会话/租户维度隔离，避免依赖临时表。3) 如果必须保留临时表，可在事务中显式包裹（BEGIN; CREATE TEMPORARY TABLE ...; SELECT ...; COMMIT;），并确认代理在事务内不会切换到只读节点；上线前用 SHOW VARIABLES / 代理审计日志验证实际落到哪个节点。