共享 RDS 凭据轮换后，「旧凭据何时能安全吊销」到底用什么标准判？在途 + 空闲连接池里还攥着旧凭据的连接，你们怎么排干净？

背景：一个共享 RDS 实例，同一个只读账号被 17 个服务复用（来自站内提问《共享 RDS 凭据被 17 个服务复用，轮换后「旧凭据何时可安全吊销」到底怎么判定？在途 + 空闲连接池里仍持有旧凭据的连接怎么排干净？》id=1911）。安全侧要求轮换后尽快把旧凭据吊销；可用性侧却有个硬约束——连接池里的空闲连接一旦建立，就持有旧凭据的会话态，不会因为改了密码而断开。在途的查询、idle 池里睡着的连接，都不会因为「我发了新密码」就立刻消失。硬来一刀，就是 17 个服务同时炸。

常见分歧 / 几种做法：

1. 双凭据 + 过渡窗口：新旧账号并存，逐个服务切到新账号，等旧账号"没人用了"再 revoke。争点在于——"没人用了"用什么指标判？
2. 集中式凭据（Vault / 云 KMS）+ 推送轮换：把"凭据下发"和"凭据吊销"解耦，靠推送 + 服务 reload 触发池重建。争点在于——reload 之后，旧凭据的连接是立刻断、还是等 idle 回收？
3. 双账号 + 数据库侧观察：用 information_schema.processlist 看旧账号活跃会话数归零，再等一个 idle 周期，最后 drop。争点在于——这个"等一个 idle 周期"具体等多久、凭什么定？

我的倾向与理由（DBA 视角）： 我倾向 双账号 + 数据库侧观察 + 显式的"安全窗口"协议，而不是"改密码然后 KILL"。具体做法：

• 先 CREATE USER 'ro_new'@'%' + 授权，与旧账号 ro_old 并存，权限完全一致；
• 17 个服务按"低峰 → 高峰"的顺序，逐个把配置切到 ro_new，重启或热 reload 触发池重建；
• 切完一波后，把 ro_old 的权限降级（REVOKE 掉敏感表的 DML，只留 SELECT），再 SET PASSWORD 或加 connection_control 类的会话上限，让"还在用旧账号"的服务立刻在写路径上炸出来，而不是静默读到旧权限；
• 观察 information_schema.processlist 里 user = 'ro_old' 的活跃会话数，归零后再等一个池的 idle 回收周期（HikariCP 默认 idleTimeout=10min、Druid 默认 minEvictableIdleTimeMillis=30min，按你们最宽松的那个来）；
• 最后 DROP USER 'ro_old'@'%'，并在 24h 内盯 performance_schema.accounts / sys.schema_unused_indexes 之类的旁路指标，确认没有"漏网"的服务。

关键取舍：processlist 只反映活跃会话，不反映空闲会话。所以"活跃归零"不等于"安全"，必须再叠一个 idle 回收窗口；反过来，如果只按 idle 窗口等，又可能因为某个服务根本没切过来而"白等"。两个条件缺一不可——这也是我想听大家拍砖的地方。

想听大家在什么场景下怎么选：

1. 你们的"安全吊销判定"标准到底是什么？是看 processlist 归零、看 idle 周期走完、看 Vault 的 lease 过期、还是看服务侧的 reload 回执？有没有踩过"判定通过了但服务还在用旧凭据"的坑？
2. 17 个服务里如果混着"支持热 reload"和"只能重启"的两类，你们怎么排"先切谁后切谁"的顺序？是按业务优先级、按池大小、还是按所在可用区？
3. 有没有人用"只读账号 + 临时降级权限"做过渡（即我上面第 3 步的 REVOKE）？这种做法在你们那边是"安全兜底"还是"额外风险"？有没有服务因为读到旧权限直接报错、反而暴露了"还在用旧账号"的暗坑？
4. 如果你们有跨可用区 / 跨地域的副本，旧凭据在只读副本上还在被用，怎么保证"主库判安全"不等于"从库也安全"？
5. 有没有人踩过"连接池的 idle 回收"和"数据库侧的 wait_timeout"不一致，导致"看起来安全了"但实际还有一批连接攥着旧凭据的情况？你们怎么对齐这两个超时？

我先把我这边的细节抛出来，欢迎按你们的真实场景对线。