数据库 SLO 与可用性工程

• SLI/SLO 的定义方法（可用性、延迟、持久性）
• 错误预算（error budget）机制
• SLO 与业务目标的联动

SLI 是量化指标，SLO 是目标值。数据库常见 SLI：可用性（探活成功/总探测）、延迟（p50/p99 查询延迟）、数据持久性（无数据丢失时间/总时间）、正确性（对账一致率）。SLO 据此设定目标，如可用性 99.95%、p99 延迟 < 100ms、持久性 99.999%。错误预算 = 1 - SLO，即允许的失败额度（如 99.95% 可用性对应每年约 4.4 小时不可用额度）。运维要点：一是明确定义 SLI 与口径（探活、读延迟、写延迟）；二是设定 SLO 并计算错误预算；三是错误预算耗尽时触发"冻结新功能/只做稳定化"的守则；四是把错误预算与业务 KPI 挂钩（如高可用性支撑业务 SLA），向业务解释 SLO 含义；五是定期复盘错误预算消耗。SLO 要基于业务目标设定，避免拍脑袋。

核心是"用 SLI 量化、SLO 定目标、错误预算管理风险"。错误预算把"允许失败"变成可度量的资源，消耗完就冻结变更，使 SLO 与业务目标联动而非口号。

• 数据正确性的度量难度
• 对账、校验和、影子读方法
• 正确性 SLO 的设定

数据正确性难以量化，因为"错误"往往不报错、需要知道正确值。常用度量方法：一是对账（reconciliation），双写/多写场景下定期比对两套数据（行数、关键字段、总额），发现差异；二是校验和（checksum），对既定范围内的数据计算哈希，定期比对（类似 pt-table-checksum）；三是影子读（shadow read），把生产读请求同时发给主/备或新/旧系统，比对结果是否一致；四是应用层校验，用业务不变量（如总额守恒、计数器）验证。正确性 SLO 可设定为"对账一致率 ≥ 99.99%""校验和相符率 100%""影子读差异率 < 0.01%"。运维要点：对账频率、覆盖率、差异处理（告警、补偿、人工介入）。正确性度量要覆盖静默损坏（主从不一致、存储腐蚀）。

正确性量化靠"参考值 + 比对"。对账/校验和/影子读本质是"用已知正确或另一副本做比对发现差异"，其 SLI 是"一致率/差异率"，需覆盖静默故障场景。

• 静默故障的定义与危害
• 主动发现方法（校验和、对账、延迟检测）
• 修复与预防

静默故障指主从数据不一致但复制不报错，如 binlog 丢失、复制过滤被误配、存储介质损坏、应用绕过主库直接写从库。主动发现方法：一是定期校验和比对（如 pt-table-checksum），对表做 checksum 比对主从；二是对账（业务总额、行数、关键维度）；三是监控复制状态（复制延迟、复制错误、复制线程状态），但注意复制不报错不代表一致；四是影子读比对结果；五是应用层不变量校验。运维要点：一是建立定期全量 checksum + 巡检频率；二是差异自动告警并定位（如哪些表/行不一致）；三是修复流程（从主库重建或定向修复）；四是预防：禁止直写从库、校验复制配置、对存储做完整性校验。静默故障发现的关键是"主动比对而非等待报错"。

核心是"主动对账发现静默不一致"。复制不报错≠数据一致，需定期校验和/对账/影子读比对，发现差异及时修复，并预防直写从库等根因。

• 数据库变更与错误预算联动
• 变更冻结窗口管理
• 变更风险评估

数据库变更是高风险的错误预算消耗来源。纳入错误预算：一是评估变更风险（DDL 锁表、参数导致性能劣化、大事务），把高风险变更定义为"预算消耗事件"；二是变更后监控错误率/延迟，若导致 SLO 违规则计为消耗错误预算；三是变更前做风险分级与审批，高风险变更需要更严格的窗口。变更冻结窗口管理：一是定义变更冻结期（如大促、业务高峰、月度 SLO 关键期），冻结高风险变更；二是紧急变更走例外审批；三是变更窗口与业务低峰对齐，减少影响。运维要点：变更用"灰度 + 回滚 + 监控"，变更后观察错误预算消耗，融入发布节奏。把"变更导致的 SLO 违规次数"作为指标，驱动变更质量改进。

核心是"把变更当作错误预算的消耗源来管控"。通过风险分级、冻结窗口、灰度回滚与变更后监控，降低变更对 SLO 的冲击，并量化变更导致的预算消耗。

• 分层 SLO 与责任边界
• 依赖关系与故障归因
• 责任拆解与协作

数据库可用性依赖底层基础设施（网络、存储、计算、机房）。当数据库 SLO 高于基础设施 SLO 时，需拆解责任边界：一是分层 SLO 模型，定义各层（基础层：存储/网络/机房；数据库层：实例/复制/备份；应用层）的 SLO 与依赖；二是故障归因，页面数据库故障时，用监控与链路定位是底层（存储/网络/机房）还是数据库层（复制/参数/资源）问题；三是责任边界，底层故障由基础设施团队负责，数据库层故障由数据库团队负责，但数据库要设计"在底层故障下仍达 SLO"（冗余、多可用区、故障转移）；四是底层 SLO 不满足时，数据库需通过冗余与容灾弥补，责任边界要明确"数据库需在底层条件下达成自身 SLO"。运维要点：建立分层 SLO 台账、故障归因流程、跨团队协作机制，复盘时按责任归属。

核心是"分层 SLO + 故障归因 + 责任边界"。数据库通过冗余/容灾在底层 SLO 不足时仍达成自身 SLO，同时明确故障归属于哪一层，避免责任模糊。

• MTTR 的拆解（MTTD/MTTA/MTTR/MTTV）
• 各环节优化
• 运维看板

MTTR（平均修复时间）可拆解为：MTTD（检测时间，故障到发现）、MTTA（定位时间，发现到定位根因）、MTTR（恢复时间，定位到恢复）、MTTV（验证时间，恢复到验证正常）。运维要点：一是降低 MTTD，用健康检查、探活、SLI 告警加速发现；二是降低 MTTA，用链路追踪、标准化日志、根因分析工具加速定位；三是降低 MTTR，用自动化切换、预案、回滚快速恢复；四是降低 MTTV，用业务回归、数据校验快速验证。建立看板：把各环节耗时、故障次数、占比、趋势展示在运维大盘，找出瓶颈环节（如定位耗时最长）。看板驱动持续改进：按环节优化，缩短整体 MTTR。复盘时按环节分析。

核心是"把 MTTR 拆成可优化的环节"。检测/定位/恢复/验证各环节的耗时不同，看板暴露瓶颈，针对性优化（自动化切换、根因工具、预案），从而整体缩短 MTTR。

• 连接池参数（max/min/idle/超时）的调优
• 连接风暴与级联雪崩
• 级联雪崩的预防（限流、熔断、退避）

连接池参数治理：max（最大连接，需与数据库连接上限匹配并留余量）、min（最小空闲，保持热连接）、idle（空闲超时回收）、连接获取超时（避免无限等待）。SLO 联动：连接池使用率、连接获取超时、连接等待时长作为 SLI，与 SLO 关联，连接打满视为 SLO 违规。级联雪崩预防：一是连接池 max 限制，防止应用无限申请连接拖垮数据库；二是连接获取超时 + 快速失败（fail fast），避免请求堆积占满连接；三是限流与熔断，数据库连接紧张时熔断非核心请求，保留核心；四是退避重试，避免瞬间重连风暴；五是连接预热与回收，防止连接泄漏；六是有界队列，避免线程池/连接池无限排队。连接打满时先止血（杀风暴连接、扩容、限流），再定位根因（SQL 慢、连接泄漏、流量突增）。

核心是"连接池上限 + 超时 + 限流熔断 + 退避"。连接池设置 max 与超时，连接打满时熔断非核心、快速失败，避免级联雪崩；用 SLI 观测连接健康与 SLO 联动。

• 事务隔离级别与锁机制
• 死锁、长事务、间隙锁的影响
• 测试与治理

事务隔离级别（读未提交/读已提交/可重复读/串行化）决定锁与一致性行为，过高隔离级别（如串行化）增加锁竞争，影响可用性。死锁：多个事务互相持有对方需要的锁，数据库回滚一方，高并发下会引发错误率；长事务：持锁时间过长，阻塞其他事务，导致锁等待与延迟上升；间隙锁（可重复读下避免幻读）：锁住范围，增大锁竞争。治理：一是降低隔离级别到业务可接受的最低（如读已提交），减少锁竞争；二是事务尽量短小，减少持锁时间；三是对大事务拆分，避免长事务；四是设置锁超时（innodb_lock_wait_timeout），避免无限等待；五是死锁检测与重试（捕获死锁后重试）；六是索引优化减少锁范围。测试：用并发压测（高并发事务、锁冲突场景）验证隔离级别与锁行为，观察死锁数、锁等待、延迟。

核心是"隔离级别与锁是可用性权衡"。降低隔离级别、缩短事务、设置锁超时、死锁重试与索引优化，减少锁竞争与阻塞，提升可用性。

• 冷热数据分离与归档
• 分区表生命周期管理
• 容量优化策略

降低在线库容量的策略：一是冷热数据分离，把很少访问的冷数据（历史订单、日志）归档到独立存储/数据仓库，在线库只保留热数据；二是分区表生命周期管理，按时间分区，定期把过期分区"下线/归档/删除"，避免分区无限增长；三是归档策略，用 TTL/定时任务把冷分区导出归档、在线库删除，或移到归档表；四是数据压缩，对历史数据压缩存储；五是容量监控与阈值，分区增长与容量预警。运维要点：一是定义数据保留周期（按业务与合规要求）；二是归档流程自动化（分区下线→导出→删除→校验）；三是归档数据可检索（归档库/数仓）；四是防止误删（归档前校验、双保险）。分区表要定期维护（合并/删除过期分区），控制表大小。

核心是"冷热分离 + 分区生命周期"。按时间分区，定期归档/删除过期分区，把冷数据移出在线库，控制容量增长，同时保证归档可检索与合规。

• 分库分表与跨分片查询
• 热点 key 问题
• 路由与治理

分库分表后：跨分片查询（非 shard key 查询）会广播到所有分片再合并，成本高、延迟大。治理：一是尽量用 shard key 查询，避免跨分片；二是对跨分片查询做缓存/汇总表/二级索引，或限制为低频离线查询；三是限制跨分片 SQL 的并发与超时。热点 key：单个 key 的高并发访问集中在少数分片，导致部分分片热点。治理：一是热点 key 拆分（key 加后缀分片）、热点数据缓存；二是读写分离分散读；三是动态分片/热点转移；四是监控各分片 QPS 与延迟，识别热点分片。运维要点：分片路由监控、热点告警、跨分片查询限流、扩缩容（再分片）预案。治理要持续监控分片均衡与热点。

核心是"就近路由 + 热点分散"。跨分片查询用缓存/汇总表/限流治理，热点 key 用拆分/缓存/读写分离分散，并通过分片监控及时发现失衡。

• TDE/KMS 加密备份
• 密钥轮换与历史数据解密
• 恢复时的密钥衔接

备份加密用 TDE（透明数据加密）与 KMS 管理密钥。恢复时无缝衔接的关键是密钥的生命周期：一是加密密钥与解密密钥分离，KMS 管理主密钥，TDE 用数据加密密钥（DEK）加密文件，DEK 由主密钥（KEK）加密；二是密钥轮换时保留旧密钥版本的解密能力（key versioning），历史备份用旧 KEK 解密 DEK 即可恢复；三是恢复时自动从 KMS 获取对应版本的密钥，无需人工干预；四是密钥元数据（版本、算法、加密信息）随备份记录，恢复时校验。运维要点：一是密钥轮换平滑，新旧并存过渡；二是监测 KMS 可用性（恢复依赖 KMS，KMS 故障时恢复失败）；三是密钥备份与容灾（跨区域 KMS 副本）；四是恢复演练验证密钥版本衔接。密钥轮换要让旧备份仍可解，否则恢复会卡住。

核心是"密钥版本化 + 元数据记录 + KMS 可用性"。轮换密钥时保留旧版本解密能力，恢复自动获取对应版本密钥，并保证 KMS 高可用，实现无缝恢复。

• 多租户 SLO 隔离
• 噪声邻居问题
• 资源隔离与配额

多租户共享实例时，一个租户的高负载会挤占其他租户资源（噪声邻居）。隔离手段：一是资源配额（cgroup/容器），限制每个租户的 CPU/内存/IO；二是连接池隔离，按租户分配连接池，避免一个租户耗尽连接；三是限流与配额，按租户限制 QPS/并发；四是优先级与 QoS，核心租户高优先级；五是监控与告警，按租户监控资源使用与延迟，识别噪声邻居；六是必要时物理隔离（大租户独立实例）。运维要点：按租户建立配额模板、监控矩阵；噪声邻居出现时限流/隔离/迁移；SLO 按租户粒度定义与统计。隔离要保证一个租户的突发不影响其他租户的 SLO。

核心是"资源配额 + 连接隔离 + 限流 + 租户级监控"。用 cgroup/配额、连接池隔离、限流与 QoS 限制噪声邻居，按租户粒度定义 SLO 并监控。

• 业务峰值预测
• 容量规划方法
• 突发余量预留

基于业务峰值做容量规划：一是采集历史峰值，统计业务高峰的 QPS、并发、存储、资源使用；二是峰值预测，结合业务增长（如大促、新功能、用户增长）预测未来峰值，可参考历史同比/环比与业务活动计划；三是容量模型，建立"QPS/并发/存储 → CPU/内存/磁盘/连接"的容量模型，推算所需资源；四是预留突发余量，在预测峰值基础上预留 20%-50% 余量（应对突发流量、数据增长、故障切换），并可做弹性扩容（pico 扩容）应对超预期；五是容量监控与预警，监控资源使用率，接近阈值时预警。运维要点：容量规划要定期更新（结合业务计划），用容量大盘展示预测 vs 实际，避免"拍脑袋扩容"。

核心是"预测 + 模型 + 余量"。用历史峰值与业务增长预测未来峰值，通过容量模型换算资源，预留突发余量并配合弹性扩容，形成数据驱动的容量规划。

• 备份端到端校验
• 静默损坏检测（大小/行数/校验和）
• 备份验证流程

备份链路端到端校验覆盖：一是传输校验，备份文件传输后校验大小与哈希（如 MD5/SHA256），确保传输完整；二是逻辑校验，校验备份内容（行数、关键字段、校验和），与源数据库比对；三是恢复校验，定期把备份恢复到测试环境，验证可恢复且数据一致（restore drill）；四是备份元数据校验，备份记录的完整性。静默损坏检测：备份可能因介质坏道、传输错误、存储腐蚀而静默损坏，需用校验和/恢复验证发现。运维要点：一是备份后立即校验大小与哈希；二是定期（如每周）做恢复演练，校验数据一致性；三是用校验和比对（如 pt-table-checksum）验证备份内容；四是监控备份校验失败并告警。端到端校验防止"备份成功了但恢复不了"。

核心是"备份 + 校验 + 恢复验证"三层兜底。传输校验、内容校验、恢复演练结合，防止静默损坏，确保备份真正可用。

• SLO 驱动的容量规划
• 容量指标与 SLO 关联
• 数据驱动扩容

用 SLO 驱动容量规划：一是定义容量相关 SLI/SLO（如 p99 延迟、可用性、连接可用率），容量不足时这些 SLO 会劣化；二是建立容量阈值与 SLO 的关联，如 CPU/内存/连接使用率超过阈值导致 p99 超 SLO；三是容量预测模型，基于峰值与增长预测达到 SLO 瓶颈的时间点；四是扩容触发基于 SLO 与容量数据，而非拍脑袋：当容量使用率接近阈值且预测将超 SLO 时触发扩容；五是容量余量预留，保证突发下 SLO 仍达标。运维要点：容量大盘与 SLO 联动，展示"当前使用率 + 预测 + SLO 安全线"，扩容决策有数据支撑。避免"凭感觉扩容"或"过度扩容"。

核心是"用 SLO 定义容量安全线"。容量与 SLO 关联，超过阈值预示 SLO 风险，用预测数据支持扩容决策，避免拍脑袋与过度扩容。

• 数据库审计日志
• 异常行为检测（拖库/越权/批量导出）
• 告警与响应

用数据库审计日志做异常行为检测：一是开启审计，记录 SQL、用户、时间、来源、影响行数；二是建立异常检测规则：拖库（短时间内大量 SELECT、全表导出、异常大结果集）、越权（非授权用户访问敏感表/库）、批量导出（大量数据导出、dump 工具）、异常时间（非工作时间操作）、异常来源（异地/异常 IP）；三是检测方法，用规则引擎 + 行为基线（用户/应用的历史行为模式），偏离基线告警；四是对告警分级与响应，高风险（拖库/越权）立即告警并阻断，低风险记录。运维要点：审计日志集中存储，防篡改；检测规则覆盖常见攻击模式；与 SIEM/SOC 联动；告警后定位（用户、来源、SQL）。异常检测是审计的增值，从"记录"到"主动发现"。

核心是"审计 + 规则/基线 + 告警响应"。审计日志记录操作，用规则与行为基线检测拖库/越权/批量导出等异常，分级告警并响应，实现主动安全。

• restore drill（恢复演练）设计
• 可恢复性验证
• 备份有效性

只做备份不验证无法保证可恢复。restore drill 设计：一是定期恢复演练，把备份恢复到测试环境（如每周/每月），验证可恢复；二是演练类型，全量恢复、增量+归档恢复、PITR 到指定时间点；三是校验恢复结果，恢复后校验数据行数、校验和、业务关键表，与源一致；四是记录恢复耗时，验证 RTO 达标；五是自动化，用脚本/平台自动触发恢复演练，避免人工遗漏；六是发现异常，演练失败定位（备份损坏、缺少归档、权限问题）并修复。运维要点：恢复演练纳入例行流程，有报告与告警；随机选取备份样本演练（覆盖不同备份）；演练结果驱动备份策略改进。可恢复性验证是"备份真正可用"的保障。

核心是"定期恢复演练验证可恢复性"。随机选备份做恢复演练，校验数据一致性并记录 RTO，失败则修复，确保备份不是"纸面备份"。

• 慢查询与执行计划调优
• Explain 断言与计划变化告警
• 索引治理

把慢查询与执行计划调优纳入 SLO 回归：一是 Explain 断言，在 CI 中对关键 SQL 做 Explain 断言（如确认走索引、type 为 range/index、无全表扫描），防止计划劣化；二是计划变化告警，监控执行计划变化（如优化器选择不同索引/join 顺序），计划变化导致性能劣化时告警；三是慢查询治理，采集慢查询、定位根因（缺索引、计划差、数据倾斜、锁等待），优化 SQL 或加索引；四是索引治理，监控索引使用率，删除冗余索引（减少写放大），对关键 SQL 建立合适索引；五是 SLO 回归，把关键 SQL 的延迟纳入 SLO，SQL 变更/索引变更后回归验证延迟不劣化。运维要点：Explain 断言纳入 CI，计划监控告警，索引管理平台化。

核心是"在 CI 与运行时双重防止计划劣化"。Explain 断言前置把关，计划变化告警实时发现，索引治理优化成本，最终用关键 SQL 延迟 SLO 回归验证。

• 无指责复盘（blameless postmortem）
• 复盘模板
• 改进项闭环

无指责复盘模板：一是时间线（故障发生、检测、定位、恢复、验证的精确时间）；二是影响（SLO 违规范围、受影响业务、用户影响）；三是根因（detect 根因，区分直接根因与根本原因）；四是缓解与恢复（做了什么止损）；五是教训（流程、监控、架构不足）；六是改进项（action items，明确负责人与期限）。无指责原则：不追责个人，聚焦系统与流程，建立"安全提问"的文化。改进项闭环：一是改进项入库（跟踪工具），明确负责人、优先级、期限；二是定期跟进，验证落地；三是分析改进项是否有效（防止同类 SLO 违规复发）；四是复盘记录归档，供后续借鉴。闭环要防止"复盘完就完"，改进项需真正落地并验证。

核心是"无指责聚焦系统 + 改进项闭环"。复盘记录时间线、根因、影响与教训，改进项明确负责人与期限并跟进验证，防止同类问题复发。

• on-call 轮值机制
• 告警疲劳缓解
• 主从延迟误判

缓解告警疲劳与 on-call 压力：一是告警分级与降噪，只对真正影响 SLO 的事件告警，跳过瞬时/低价值告警（用持续时长、聚合去重、抑制）；二是告警路由，按系统/等级路由到对应 on-call，避免轰炸；三是主从延迟误判，避免把"瞬时延迟尖峰"或"从库例行延迟"当故障告警，需区分正常延迟（大事务、备用共识）与异常延迟（复制坏、网络），用延迟阈值 + 持续时长 + 上下文（是否在维护窗口）判断；四是自动化处理，常见告警自动响应（自动切换、自动扩容），减少人工卷入；五是轮值机制，合理轮值周期、交接文档、升级路径（on-call → 深度专家）。运维要点：告警质量评估（误报率、未命中率），持续优化规则，减少疲劳。

核心是"告警降噪 + 上下文判断 + 自动化"。分级、去重、抑制减少疲劳，主从延迟结合上下文判断避免误报，自动化处理常见告警，配合合理轮值降低 on-call 压力。

• failover game day 演练
• 不丢数据保障（同步复制、一致性检查）
• 应用无感（路由收敛、探活）

主从切换演练确保不丢数据：一是用同步/半同步复制，切换前确认复制延迟为 0，主从数据一致；二是切换前做一致性检查（复制状态、未提交事务、binlog 位置）；三是切换时按流程（否决旧主、提升新主、修改路由），避免双写。应用无感：一是应用侧用连接池/读写分离中间件，自动感知主从切换并收敛路由；二是健康检查/探活，切换后应用探活到新主；三是切换期间快速失败与重试，避免请求长时间阻塞；四是 DNS/配置下发更新主库地址。演练要点：一是定期演练（game day），验证流程与预案；二是演练后校验数据一致性（行数、校验和）与业务可用性；三是记录切换耗时与 RPO/RTO；四是演练发现的问题改进预案。演练要真实模拟故障，验证"不丢数据 + 应用无感"。

核心是"同步复制保证不丢 + 路由收敛保证无感 + 定期演练验证"。同步复制与一致性检查保证 RPO=0，连接池/读写分离自动收敛保证应用无感，game day 演练验证预案。

• 参数模板与基线管理
• 多实例统一管理
• 灰度变更

参数模板（参数基线）统一管理：一是定义参数模板，把实例的关键参数（缓冲池、连接、隔离级别、复制参数）固化为标准模板，按实例类型（OLTP/OLAP/从库）分类；二是参数基线，用模板作为基线，多实例对齐；三是变更管理，参数变更走"模板修改 → 灰度 → 全量"流程；四是灰度变更，先在部分实例（测试/低风险）应用新参数，观察性能与稳定性，再逐步推广到全部；五是参数漂移检测，定期比对实例实际参数与模板，发现漂移告警；六是回滚，参数变更保留旧值，回滚预案。运维要点：参数管理平台化（模板、实例、变更记录），变更用"灰度 + 监控 + 回滚"，参数变更后观察 SLO。统一管理避免多实例参数不一致导致的性能差异。

核心是"模板基线 + 灰度变更 + 漂移检测"。参数模板统一基线，变更走灰度观察，定期检测漂移，保证多实例参数一致且变更可控。

• 防勒索（immutable/WORM）备份
• 备份介质防护
• 恢复验证

防勒索备份策略：一是不可变备份（immutable backup），备份存储设置为只追加、不可删除/不可修改（WORM 对象锁定），即使勒索软件攻破生产也无法删除备份；二是备份隔离，备份存储与生产网络隔离，备份凭据与生产分离，防止勒索软件横向访问备份；三是多副本，备份副本异地/离线存放，至少一份不可变；四是备份权限最小化，备份管理账号独立、权限收紧；五是备份完整性校验，定期校验备份可恢复；六是恢复演练，勒索后能快速恢复（干净的备份）。运维要点：WORM 存储配置（对象存储锁定、磁带 WORM）、备份版本保留周期、勒索检测（检测异常删除/加密）。防勒索核心是"备份不可变 + 隔离 + 可恢复"。

核心是"备份不可变 + 隔离 + 完整可恢复"。WORM/不可变存储防止备份被删改，备份与生产网络隔离，多副本异地存放，确保勒索后能恢复干净备份。

• 多地多活与脑裂
• 冲突合并
• 运维预案

多地多活（active-active）下网络分区或故障会导致脑裂（两个站点都认为自己是主、产生双写）。运维预案：一是脑裂检测，用仲裁/多数派（quorum）判断哪边是合法主，用租约/心跳/分布式锁识别脑裂；二是脑裂恢复，仲裁失败侧降级为只读或停止写入，避免双写；三是冲突合并，脑裂期间两站产生的数据冲突，用冲突解决策略（时间戳、LWW、版本向量、业务规则）合并，或用基于主键的 conflict resolution；四是对账，恢复后做数据对账，发现差异并修复；五是运维过程，脑裂时先隔离再恢复，恢复后对账、补数据、切换确认。运维要点：预案包含仲裁机制、冲突合并规则、对账流程、回切流程，并定期演练。多地多活要防"双写导致数据分叉"。

核心是"仲裁防脑裂 + 冲突合并 + 对账修复"。用 quorum/租约防止双写，用冲突解决策略合并脑裂数据，恢复后对账修复，形成完整预案。

• 大事务的影响（复制延迟、锁表）
• 熔断机制
• 快速止血

大事务会导致复制延迟（从库跟不上）与锁表（阻塞其他事务）。运维熔断：一是监控大事务，监控长事务/大事务时间与大小，设置阈值；二是事务超时，设置事务超时/lock wait 超时，防止大事务无限持锁；三是熔断触发，检测到大事务（持锁超时、复制延迟超阈值）时触发熔断：终止大事务（kill 事务/会话）、限制其资源；四是复制延迟熔断，复制延迟超过阈值时告警并处理（暂缓大事务、扩容从库、跳过收敛）；五是锁表熔断，检测锁等待超阈值时终止导致锁的事务或降级。止血后定位根因（应用在大事务中做过多操作、锁竞争）。运维要点：熔断要分级（告警→终止→隔离），设置安全阈值，避免误伤正常业务。

核心是"监控大事务 + 超时 + 熔断终止"。设置事务超时与延迟/锁等待阈值，检测到大事务或锁表时触发熔断终止，快速止血并定位根因。

• SQL 探活与健康检查
• 读写分离探测
• 故障转移后的路由收敛验证

数据库探活设计：一是 SQL 探活，用轻量 SQL（如 SELECT 1）探测实例可用性，比 TCP ping 更真实（能发现 SQL 层问题）；二是读写分离探测，分别探测主库（写）与从库（读）的可用性，写探活用写/事务，读探活用读 SQL；三是故障转移后的路由收敛验证，切换后验证应用流量收敛到新主，旧主不再被写，验证路由的正确性（连接池/中间件更新）。运维要点：探活频率与超时设置（避免误报与漏报）；探活结果驱动自动切换/路由；切换后验证（读写成功、延迟、路由收敛）再放业务。健康检查要区分"实例存活"与"服务可用"（SQL 探活更全面）。接线：探活用 SQL 探活为主，健康检查配合副本状态。

核心是"SQL 探活更真实 + 读写分离探测 + 切换后路由收敛验证"。SQL 探活发现 SQL 层问题，读写分离分别探测主从，切换后验证路由收敛，保证应用可用。

• 数据质量规则（空值/重复/越界）
• 自动化巡检
• 告警分级

数据质量巡检：一是定义数据质量规则，如关键字段空值率、唯一性（重复）、取值范围（越界）、格式（电话号码/日期）、引用完整性；二是自动化巡检，用定时任务/数据质量工具定期扫描数据，检验规则，输出质量报告；三是告警分级，按影响分级：空值/重复/越界影响核心业务 → 高，影响分析 → 中，一般 → 低；四是告警驱动，越界/重复等影响业务正确性的立即告警，趋势性（空值率上升）持续监控；五是修复，巡检发现的问题定位（规则、字段、数据来源），修复数据或修源头。运维要点：巡检规则库管理、巡检频率、结果入库、告警接入监控。数据质量巡检把"数据正确性"从被动发现转为主动巡检。

核心是"规则 + 巡检 + 分级告警"。定义空值/重复/越界等规则，定期自动化巡检，按影响分级告警，驱动修复，主动保障数据质量。

• 统计信息过期引发的劣化
• 自动巡检与更新
• 性能预防

统计信息过期导致优化器选错执行计划，引发性能劣化。自动巡检：一是监控统计信息时效，检测统计信息生成时间/采样率，超过阈值认为过期；二是监控统计信息相关指标，如行数估算与实际差异、执行计划突变的 SQL；三是自动更新，定期或按需重新收集统计信息（ANALYZE/UPDATE STATISTICS），尤其在大表变更/数据量变化后；四是采样策略，大表用采样统计，平衡成本与准确性；五是巡检计划，对关键表定期收集统计信息，批量/低峰执行。运维要点：统计信息更新纳入例行维护，更新后观察执行计划与性能；用"统计信息过期告警 + 自动更新"防劣化。统计信息是优化器决策的基础，过期会引发隐性劣化。

核心是"监控统计时效 + 自动更新 + 更新后验证"。检测统计信息过期并定期收集，用采样控制成本，更新后观察执行计划防劣化。

• 缓冲池命中率下降
• 容量 vs SQL 问题区分
• 定位与治理

缓冲池命中率下降可能由容量（buffer pool 太小）或 SQL（扫描大量数据、全表扫描）问题引起。区分方法：一是看命中率与访问模式，若命中率下降同时伴随大量逻辑读/全表扫描，多是 SQL 问题；若命中率持续低且数据总量远超 buffer pool，多为容量问题；二是看 SQL 类型，定位 top SQL，若大量 SQL 扫描大范围（全表/大索引），是 SQL 问题（应优化 SQL/索引）；三是看 buffer pool 大小与数据量，若数据总量远超 buffer pool 且无劣化 SQL，是容量不足；四是看是否突发，突发性命中率下降 + 特定 SQL 出现，多为 SQL 问题；五是统计 buffer pool 命中率、逻辑读、物理读、SQL 扫描量。处置：SQL 问题优化 SQL/索引减少扫描；容量问题扩容 buffer pool/减少内存其他占用。运维要点：命中率下降先看 SQL 再判断容量，用监控区分。

核心是"用 SQL 特征与容量数据区分"。命中率下降时先定位 top SQL 与扫描量，若 SQL 扫描大则优化 SQL/索引，若数据总量超 buffer pool 则扩容，避免误判。

• 应用侧 vs 数据库侧连接池打满
• 级联雪崩
• 快速止血

连接池打满会引发级联雪崩：应用侧连接池打满 → 请求堆积 → 线程池打满 → 服务不可用；数据库侧连接数打满 → 新连接失败 → 应用抛错。快速止血：一是确认打满侧，应用侧连接池（看应用监控）还是数据库侧（看数据库连接数）；二是应用侧打满，增大连接池/快速失败（fail fast）、限流、熔断部分请求，释放登录；三是数据库侧打满，杀空闲连接/非核心连接、扩容、限流应用连接申请；四是止损：先快速失败超时请求，限制新请求，避免请求堆积再占连接；五是定位根因：SQL 慢导致连接被占、连接泄漏、流量突增、死锁。运维要点：连接池设置 max 与超时、有界队列；雪崩时用限流熔断快速止血，再恢复连接池。快速止血是"先释放连接，再定位根因"。

核心是"分级确认 + 快速止损 + 根因治理"。先判断打满侧，用快速失败/限流/熔断/杀连接释放压力，再定位 SQL 慢、泄漏等根因，避免级联雪崩。

• 逻辑备份与物理备份的区别
• RPO/RTO 差异
• 混合使用策略

逻辑备份（导出 SQL/数据）与物理备份（复制数据文件）差异：逻辑备份可移植、粒度细、跨版本，但速度慢、恢复慢；物理备份快、体积小、恢复快，但依赖版本/平台。RPO/RTO：逻辑备份通常 RPO 较大（全量导出周期），恢复慢（RTO 大）；物理备份可配合 binlog/归档实现低 RPO，恢复快（RTO 小）。混合使用：一是物理备份做基础（快速恢复、低 RPO），逻辑备份做补充（跨版本迁移、单表恢复、数据导出）；二是用"物理全量 + 归档日志"做主流恢复，逻辑备份用于特定对象恢复；三是按场景选择：容灾/快速恢复用物理，迁移/单表/审计用逻辑。运维要点：明确各备份的 RPO/RTO、恢复场景，混合编排，定期验证两类备份可恢复。混合使用覆盖"快速恢复"与"灵活恢复"两类需求。

核心是"物理备份快速低 RPO + 逻辑备份灵活可移植"。物理备份支撑快速容灾恢复，逻辑备份用于跨版本/单表/导出，按场景混合使用，并分别验证 RPO/RTO。

• 闪回/PITR 原理
• 误操作恢复流程
• 恢复验证

闪回（flashback）与 PITR（时间点恢复）用于误操作（误删数据、误更新、误 drop 表）恢复。流程：一是确认误操作与时间点，记录误操作发生的时间与影响范围；二是选择恢复方式：闪回（利用 undo/闪回日志快速回滚到误操作前、单表/单行恢复）或 PITR（用全量备份 + 归档日志恢复到指定时间点）；三是恢复前备份当前状态（防止恢复失败）；四是恢复操作，闪回直接回滚或 PITR 恢复到新库再导出；五是验证恢复后的数据一致性与完整性（行数、业务校验）；六是切回业务，恢复数据可用后切换。运维要点：开启闪回/归档（保证可恢复）；明确 RPO/RTO 与恢复目标；恢复演练；快速定位误操作（binlog 分析、审计日志）。PITR 恢复要精确到时间点，避免恢复过度/不足。

核心是"定位误操作 + 选恢复方式 + 备份保护 + 验证"。闪回快、PITR 精确，先确认时间点，恢复前备份，恢复后验证并切回，配套演练。

• 慢查询根因定位
• 执行计划/锁等待/IO 抖动
• 标准化流程

慢查询根因定位标准化：一是执行计划分析，用 EXPLAIN 看执行计划，判断是否走索引、扫描范围、join 顺序，是否因统计信息过期/计划退化；二是锁等待分析，用锁监控（innodb status、锁等待表）判断是否锁等待、死锁、长事务阻塞；三是 IO 抖动分析，看 IO 延迟/吞吐/磁盘状态，判断是否磁盘 IO 瓶颈、存储抖动；四是资源分析，看 CPU/内存/网络；五是数据特征，看数据量增长、数据倾斜、热点。标准化流程：慢查询采集 → 关联执行计划/锁/IO/资源指标 → 定位根因（计划差/锁等待/IO 瓶颈）→ 优化（SQL/索引/参数/扩容）→ 回归验证。运维要点：建立标准化的根因定位模板（按执行计划→锁→IO→资源顺序排查），用监控平台关联指标，减少排查时间。

核心是"按执行计划→锁→IO→资源的标准链路排查"。用 EXPLAIN 排除计划问题，锁监控排除锁等待，IO 指标排除存储抖动，逐层定位根因并优化。

• 读写分离与从库延迟
• 一致性路由（读一致性）
• 缓解脏读

读写分离下从库延迟导致读不到刚写入的数据（脏读）。一致性路由方案：一是强制主库读，对一致性要求高的请求（如刚写后立即读）路由到主库；二是会话级一致性，写后一段时间内该会话读主库，或根据会话/请求标记路由；三是延迟感知路由，从库延迟超过阈值时，该读请求路由到主库或延迟从库降级；四是读己之写（read-your-writes），写操作后的读保证命中主库；五是全局一致性，用时间戳/版本把读路由到滞后不超限的从库。运维要点：读写分离中间件/客户端支持一致性路由策略；监控从库延迟，延迟高时降级只读/路由主库；对关键场景强制主库读。缓解脏读是"一致性路由 + 延迟监控"。

核心是"按一致性需求路由 + 延迟感知"。读写分离中间件把敏感读路由主库或按延迟降级，配合从库延迟监控，缓解脏读。

• 逻辑备份窗口过长
• 增量+归档补齐
• 备份策略优化

TB 级库逻辑备份全量导出耗时过长，无法满足 RPO/RTO。优化策略：一是用物理备份（xtrabackup/文件复制）替代逻辑备份，物理备份快；二是全量+增量+归档：定期全量（物理），配合增量（binlog/redo）与归档日志，实现低 RPO 时间点恢复；三是逻辑备份用于特定场景（单表、迁移、审计），不作为主备份；四是并行备份，用并行导出/多线程加速；五是错峰备份，避业务高峰。运维要点：用物理全量 + 归档日志做主流备份（低 RPO、快恢复），逻辑备份用于灵活场景；合并备份调度，验证恢复。混合策略解决"逻辑备份窗口过长"：物理快照做全量，增量+归档补齐恢复点。

核心是"物理快照做全量 + 增量/归档补齐 RPO"。TB 级库用物理备份快速全量，配合增量与归档实现时间点恢复，逻辑备份降级为灵活场景。

• 异步复制 RPO 抖动
• 运维大盘呈现
• 告警设计

跨地域异步复制 RPO 抖动（网络延迟、带宽、主库负载波动导致复制滞后）需呈现与告警：一是 RPO 指标，采集复制延迟/Gap（主从 binlog 位置差、时间差），作为 RPO 指标；二是运维大盘呈现，展示 RPO 随时间变化、复制延迟、带宽、网络抖动，用时序图与告警阈值；三是告警设计，设置 RPO 阈值（如超过 5 秒/分钟告警），区分"瞬时抖动"与"持续劣化"（持续时长判断），避免误报；四是分级告警，RPO 超阈值预警、严重告警、容灾降级；五是根因，抖动时关联网络/带宽/主库负载定位。运维要点：RPO 抖动要与业务 RPO 目标（如允许 5 分钟）对齐，告警阈值与业务容忍匹配；用线程/趋势判断抖动是否需处理。

核心是"RPO 指标化 + 大盘呈现 + 分级告警"。采集复制延迟为 RPO 指标，用持续时长判断抖动，分级告警，并与业务 RPO 目标对齐，防止误报。

• 多类型数据库指标差异
• 指标语义归一化
• 统一监控

多类型数据库（MySQL/PG/Redis/ES）指标名称与语义不同，需归一化：一是定义统一指标模型，把各库的核心指标映射为统一语义（如 QPS、延迟、连接数、资源使用率、错误率），用统一命名；二是采集层归一化，用统一采集器（如 Prometheus exporter / 自定义 agent）把各库指标转成统一格式；三是语义映射，建立映射表（各库原指标 → 统一指标），如 MySQL 的 Threads_connected 与 PG 的 numbackends 都映射为"连接数"；四是单位统一，如内存用 MB、延迟用 ms；五是统一存储与展示，指标入库统一监控大盘。运维要点：维护指标映射表，统一 exporter 与监控，保证归一化后语义准确。归一化让多类型库可统一监控、告警与容量分析。

核心是"统一指标模型 + 采集归一化 + 语义映射"。用统一采集器与映射表把各库指标归一为统一语义与单位，实现统一监控与对比。

• 业务对账（双写校验/总额核对）
• 静默数据错误发现
• 对账机制

业务对账是发现静默数据错误的有效手段：一是双写校验，双写场景下对两套数据做比对（行数、关键字、校验和），发现不一致；二是总额核对，用业务不变量（如订单总额、账户余额、库存总数）做核算，总额不符即发现数据错误；三是业务规则校验，用业务约束（如订单金额=明细之和、余额非负）校验数据；四是维度对账，按时间/维度聚合核验（如日汇总 vs 明细）。运维要点：设计对账任务（频率、范围、不变量），对账结果比对，差异告警并定位；对账要覆盖关键业务数据。业务对账用"业务视角"发现数据库无法自检的静默错误（如应用逻辑错误、部分写入失败）。

核心是"用业务不变量做对账"。双写校验、总额核对、业务规则用业务视角发现静默错误，差异告警并修复，弥补数据库层自检不足。

• 慢日志采集与聚合
• 海量实例采样策略
• 成本与覆盖

海量实例下慢日志采集与聚合需平衡成本与覆盖：一是采样策略，不必全量采集所有实例，可按重要性采样（核心实例全量，边缘实例抽样）；二是聚合工具，用 pt-query-digest 等对慢日志聚合（按模板/指纹分组，输出 top SQL），控制数据量；三是采样率，对高流量实例降低采样率（如 10%），对低流量全量；四是就近预处理，在边缘/实例侧先聚合再回传，减少带宽；五是保留策略，原始慢日志保留短周期，聚合结果长期保留；六是分级，按慢查询影响（执行次数、耗时、影响行数）分级采集与告警。运维要点：配置采样率与聚合规则，监控采样覆盖，避免漏掉关键慢查询。海量实例下"全量采集"不可行，用采样+聚合控制成本。

核心是"采样 + 聚合 + 分级"。按实例重要性采样、用 pt-query-digest 聚合、就近预处理与分级，控制成本同时覆盖关键慢查询。

• schema 漂移（与 ORM 不一致）
• CI 发现（迁移/校验）
• 运行时发现（检查探针）

schema 漂移（实际 schema 与 ORM/期望不一致）会导致应用报错。发现方法：CI 侧一是用 schema 迁移工具（如 Flyway/Liquibase）管理 schema 版本，CI 校验迁移脚本与建模模型一致；二是 schema 对比，用工具（如 schema-diff）比对 ORM 模型与实际 schema，CI 中检查差异；三是迁移测试，CI 中跑迁移到干净的测试库，验证 schema 与 ORM 一致。运行时一是 schema 探针/检查，应用启动时校验 schema 与期望一致（如缺失列/类型不符则告警或阻止启动）；二是监控 schema 相关错误，如"column not found"类错误告警；三是定期 schema 巡检，比对实际 schema 与管理基线。运维要点：CI 与运行时双重校验，schema 变更走迁移流程，漂移告警并修复。schema 漂移要"CI 前置校验 + 运行时探针"双保险。

核心是"CI 前置校验 + 运行时探针双保险"。CI 用迁移与 schema 对比提前发现，运行时用探针/错误监控发现现场漂移，形成闭环。

• 数据库健康检查
• Kubernetes 探针（liveness/readiness）
• 对接方式

数据库健康检查与 Kubernetes 探针对接：一是用 exec 或 TCP 探针，liveness 判断数据库是否存活（如 SQL 探活），readiness 判断是否可服务（SQL + 复制状态）；二是探针类型，livenessProbe 失败则重启容器，readinessProbe 失败则从 Service 摘除流量；三是探针内容，用轻量 SQL（SELECT 1）做 exec 探针，避免过重；四是区分主从，主库探针验证写能力，从库探针验证读与复制延迟；五是探针频率与超时，避免误杀（liveness 失败重启要有容错）；六是配合路由，readiness 失败摘除流量，配合中间件/Service 路由。运维要点：探针脚本纳入容器镜像，探针结果与监控联动；避免探针与数据库故障互相干扰。数据库探针让 K8s 感知数据库健康并自动处理。

核心是"exec/SQL 探针 + liveness/readiness 分层"。liveness 控存活重启，readiness 控流量摘除，用轻量 SQL 探活并按主从区分。

• 数据库关键指标采集
• 统一接入可观测平台
• 指标标准化

数据库关键指标统一接入可观测平台：一是采集，用 exporter（mysqld_exporter、pg_exporter）或 agent 采集 QPS/TPS/连接数/复制延迟/资源等指标；二是标准化，统一指标命名与单位（如 db_qps、db_connections、replication_delay），用标签区分实例/环境；三是接入，指标推送到 Prometheus/国产可观测平台，统一存储；四是展示，统一大盘（按实例/集群展示关键指标）；五是告警，统一告警规则（QPS 突增、连接打满、复制延迟超阈值）；六是关联，与业务指标、日志、链路关联，便于排障。运维要点：采集器统一部署、指标字典管理、告警规则统一。关键指标统一接入便于集中监控、告警与容量分析。

核心是"统一采集 + 标准化 + 统一存储告警"。用 exporter 采集，统一命名与标签，接入可观测平台存储展示，统一告警并关联排障。

• 变更前后指标 diff
• 自动比对告警
• 变更回滚

变更前后指标 diff 自动比对：一是变更基线，变更前采集指标基线（p99 延迟、错误率、QPS、资源）；二是变更后窗口，变更后采集相同时段指标；三是自动比对，用统计方法（均值/分位数变化、突变检测）对比变更前后，识别异常（如 p99 延迟突变）；四是告警，比对差异超过阈值自动告警，提示可能变更导致；五是回滚，若确认变更导致劣化，快速回滚；六是自动化，变更流水线集成比对，变更后自动评估。运维要点：选择可比指标与时段（避免业务波动干扰）、设置合理阈值、变更记录与比对关联。变更后自动比对能把"变更导致的性能劣化"及时暴露。

核心是"变更前后指标自动比对 + 异常告警 + 回滚"。采集基线，变更后比对差异，超阈值告警并关联变更，确认劣化则回滚，自动化集成。

• 锁等待图（deadlock graph）
• 可视化
• 代码层根因定位

锁等待图（deadlock graph）可视化与根因定位：一是采集，捕获死锁/锁等待信息（MySQL 的 SHOW ENGINE INNODB STATUS、PG 的锁等待视图），记录参与事务、锁资源、等待关系；二是可视化，把锁等待关系画成图（节点=事务/SQL，边=等待关系），用工具（如 pt-deadlock-logger + 图可视化）展示死锁环；三是定位代码层根因，从死锁图识别：哪些 SQL/事务参与、加锁顺序、涉及的索引/行、持锁时间，反推到应用代码（事务顺序不一致、长事务、索引缺失导致锁范围大）；四是治理，统一加锁顺序、缩短事务、优化索引、重试。运维要点：监控死锁与锁等待，死锁告警并记录，用图分析根因。锁等待图把"死锁关系"可视化，定位从事务/锁顺序到代码层。

核心是"采集锁等待关系 + 可视化 + 反推代码"。捕获死锁参与方与等待关系，可视化死锁环，识别加锁顺序与锁范围，定位到代码层事务与索引问题。