数据库凭据轮换：先验证新连接，再收回旧凭据凭据轮换的目标是使新凭据成为所有应用和运维任务的唯一可用入口，同时避免服务中断。若先修改单一账号密码或撤销旧凭据，再逐个更新部署，连接池、长时间运行任务和未纳入清单的消费者可能继续使用旧值并集中失败。更安全的过程分为消费者盘点、并行准备、主动连接验证、分批切换、旧凭据撤销和事后观察。具体并行方式取决于数据库和身份模型，不能假设所有引擎都支持相同操作。
列出所有连接数据库的程序和人员：在线服务、后台消费者、定时任务、数据迁移、监控探针、备份恢复工具、BI作业和人工运维。对每个消费者记录负责人、环境、连接池类型、凭据来源、最长运行时间、发布方式和失败重试行为。除主仓库外，还要核查流水线变量、部署平台配置、脚本仓库、容器配置和灾备环境。
观察连接数量、认证失败、连接池等待、事务错误和应用延迟的基线，并确认数据库审计可识别不同主体。如果多个应用共享同一数据库账号，轮换前先明确影响范围；能按服务分离身份时，后续排查和撤销会更精确。准备好经授权的回滚计划，明确什么信号触发暂停扩批，以及恢复旧配置是否仍在其有效期内。
若数据库支持并行账号，可建立新的登录主体，并仅授予应用实际需要的数据库、模式和操作权限。新凭据写入秘密管理系统，限制读取主体并记录版本或更新时间。将一个预发布实例指向新版本，强制建立新连接，测试认证、必要读写、事务提交、连接池回收和重试恢复。只观察旧连接仍然工作，不能证明新凭据有效；必须创建新的认证会话。
如果系统只允许修改同一账号的密码，应先了解连接池和服务端会话的行为，选择可控维护窗口并验证新配置的传播方式。不要把生产口令打印到命令行历史、诊断输出或工单。若新凭据登录成功但关键查询失败，说明连接权限或角色默认设置可能不同，不能以“能连上”作为轮换完成的唯一标准。
数据库认证失败率、新旧主体连接数、连接池等待时间、事务回滚和业务延迟。连接池可能在配置更新后继续复用已经认证的旧会话。应查看新旧身份的活动连接，并确认应用确实重建了连接；同时考虑长事务和批任务的最长运行时间，避免在它们仍使用旧会话时撤销旧凭据。
验收时确认所有登记的消费者均使用新凭据，低频作业、备份恢复和灾备环境也完成验证；目标连接操作成功，越权操作按预期失败；旧凭据已不能建立新会话；连接池等待、认证错误和应用延迟回到基线。检查秘密版本、部署批次、审计主体和回滚记录，但不把真实口令写入证据。
轮换结束后更新凭据责任人、存放位置和下次复核计划。若发现未登记消费者，应先判断业务关键性和暴露范围，再补全切换与验收，不能为了完成进度把未知依赖留在旧凭据上。🔐
