备份对生产有什么影响？I/O、CPU、网络如何受影响？
备份对生产的影响主要是资源消耗：I/O（读取大量数据文件、写入备份文件，抢占磁盘 I/O，影响在线查询与写）、CPU（备份工具计算校验和、压缩、排序，占用 CPU）、网络（备份数据传送到远程存储/异地，占用网络带宽，影响业务流量）。影响程度取决于备份方式（物理全量读盘大、逻辑导出耗 CPU、远程备份耗网络）、数据量、备份窗口。缓解：在业务低峰执行备份、限速（throttling）、使用从库做备份（避免主库 I/O）、压缩减少传输、监控资源水位。备份是有代价的，需要平衡备份完整性与对业务的影响。
备份的资源影响（I/O/CPU/网络）是"备份对生产干扰"的本质。缓解靠低峰窗口、限速、从库备份、压缩。理解这些影响是设计备份计划的基础。
备份窗口（Backup Window）如何估算？为什么要选业务低峰期？
备份窗口（Backup Window）是执行备份的时间段，通常选业务低峰期，因为备份消耗 I/O/CPU/网络，低峰期对业务影响最小。估算备份窗口：根据数据量、备份速度（实测吞吐）、备份方式（全量/增量）估算所需时长，留出余量；同时考虑备份频率（全量/增量间隔）、保留策略、与业务高峰错开。备份窗口要满足：备份能在窗口内完成（不超时）；备份对业务影响可接受（低峰）；备份频率与 RPO 匹配。若备份超窗，需优化（压缩、并行、限速调整、物理备份）或调整窗口。备份窗口是备份计划与业务可用性的平衡点。
备份窗口是"备份完整性"与"业务可用性"的平衡。选低峰减少干扰，估算时长留余量，超窗则优化。合理设定备份窗口是备份运维的基础。
备份限速（Throttling）如何实现？--max-rate、ionice、cgroups 各有什么作用？
备份限速（Throttling）控制备份对 I/O/CPU 的消耗，避免拖垮生产。实现方式：--max-rate（如 XtraBackup 的 --throttle、mydumper 的 --max-rate）限制备份 I/O 速率，限制备份读写速度；ionice 设置 I/O 优先级类（如 idle/best-effort），让备份在空闲时用 I/O、与在线业务竞争时让位；cgroups 用 blkio/cpu 控制器限制备份进程组的资源水位（带宽、CPU 配额）。限速策略：硬件限速（--max-rate）精确控制速率，ionice 控制优先级，cgroups 控制资源额度。三者可组合：cgroups 限制整体资源，ionice 设优先级，--max-rate 控制具体速率。限速在保证备份完成的同时降低对业务影响。
备份限速是对 I/O/CPU 的"水龙头"控制。--max-rate 控制速率，ionice 控制优先级，cgroups 控制资源配额。三者组合实现"备份不干扰业务"。
备份与复制（Replication）如何协同？
备份与复制（Replication）协同提升容灾能力：备份提供"过去某个时间点"的数据（可恢复），复制提供"实时"的备用数据（可切换、可读）。协同方式：用从库做备份（在从库上执行备份，避免主库 I/O 影响，备份数据来自从库）；备份与复制互为补充——复制保证高可用（主库故障切换从库），备份保证数据可恢复（误删、逻辑错误用备份恢复）；复制不能替代备份（复制会传播误删，且从库也可能损坏）。协同还体现在：备份从从库取，减少主库负载；复制延迟监控与备份对照。最佳实践是"主从复制 + 从库备份 + 异地备份"，形成高可用与容灾双层保障。
复制管"可用性"，备份管"可恢复性"，二者互补。从库备份降低主库负载，复制与备份结合形成完整容灾。复制绝不可替代备份。
在备份恢复与 PITR 范畴内，备份限速如何实现？
在备份恢复与 PITR 范畴内，备份限速控制备份/恢复对恢复环境或生产环境的资源消耗。备份限速：限制备份时读取源库与写入备份存储的速率（--max-rate、ionice、cgroups），避免拖垮源库。恢复限速：PITR 恢复时回放日志/还原数据也消耗资源，需控制恢复速率避免影响其他系统（如恢复到从库时避免拖垮）。限速实现分工具层（--max-rate、--throttle）与系统层（ionice、cgroups、nice）。PITR 中限速要注意：恢复限速会延长 RTO（恢复时长），需平衡"限速保护资源"与"快速恢复"。限速参数在恢复演练中实测校准，保证恢复既能受控又不超 RTO。
备份/恢复限速是"资源保护"与"恢复速度"的权衡。工具层与系统层限速组合，PITR 中还需考虑限速对 RTO 的影响。实测校准限速参数是运维关键。
恢复介质（Recovery Media）的准备是什么？应急启动盘、备份挂载如何准备？
恢复介质（Recovery Media）的准备是确保恢复时有可用的介质和工具。包括：应急启动盘（应急 OS/工具盘，含数据库工具、备份恢复工具、驱动，能在系统故障时引导环境执行恢复）；备份挂载（备份存储的挂载点/网络访问，确保恢复时能读取备份，如 NFS、云存储、磁带）；同时准备恢复环境（临时实例、目标机、足够的磁盘空间）。恢复介质准备要"可验证"：定期检查备份介质可读、工具路径可用、挂载正常。恢复介质是恢复预案的基础设施，准备不足会导致恢复时无法启动或无法读取备份。
恢复介质是"恢复的物理前提"。应急启动盘提供恢复环境，备份挂载提供备份访问。恢复介质要可验证、定期演练，避免恢复时缺介质。
恢复剧本（Recovery Runbook）如何编写？步骤、命令、责任人如何组织？
恢复剧本（Recovery Runbook）是恢复流程的文档化预案，包含：故障场景（误删、宕机、数据损坏、勒索等）、恢复步骤（按顺序的详细操作，含具体命令）、恢复命令（备份恢复、PITR、切换等实际命令）、责任人（每个步骤的负责人、值班人）、通知与升级（通知谁、何时升级）、回滚预案（恢复失败怎么办）、验证步骤（恢复后如何确认数据一致）。恢复剧本要"可执行、可验证、定期更新"：命令要经过演练验证，责任人要明确，随环境变化更新。恢复剧本是恢复操作的"地图"，减少恢复时的慌乱与错误。
恢复剧本把"恢复怎么办"文档化、可执行。场景、步骤、命令、责任人、验证、回滚缺一不可。定期演练更新剧本，保证恢复时按图索骥。
MySQL performance_schema.events_statements_summary_by_digest 的作用是什么？
MySQL 的 performance_schema.events_statements_summary_by_digest 表按 SQL 指纹（digest）聚合语句执行统计，用于分析和发现热点/慢 SQL。每条记录对应一个 SQL 指纹（归一化后的 SQL），包含：执行次数（COUNT_STAR）、总耗时/平均耗时（SUM_TIMER_WAIT、AVG_TIMER_WAIT）、扫描行数（SUM_ROWS_EXAMINED）、返回行数（SUM_ROWS_SENT）、锁等待时间（SUM_LOCK_TIME）、错误数（SUM_ERRORS）等。通过查询该表可识别"执行次数多、耗时长、扫描行数高"的高危 SQL，是慢查询治理与容量分析的重要数据源。相比慢日志，它实时聚合、无需解析日志，是 performance_schema 的核心监控表。
该表按 digest 聚合 SQL 统计，是识别热点/慢 SQL 的实时数据源。通过执行次数、耗时、扫描行数排序发现治理优先级。它是 performance_schema 监控体系的核心。
SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT/1e12 AS avg_ms,
SUM_ROWS_EXAMINED, SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
慢查询日志（slow_query_log）如何应用与配置？
MySQL 慢查询日志（slow_query_log）记录执行时间超过阈值的 SQL，用于发现慢查询。配置：slow_query_log=ON（开启）、slow_query_log_file（日志文件）、long_query_time（阈值，如 1 秒）、log_queries_not_using_indexes（记录未用索引的查询）。应用：定期分析慢日志，找出执行慢的 SQL，用 EXPLAIN 分析执行计划、优化索引或改写 SQL。可用工具（pt-query-digest）对慢日志按指纹聚合分析。慢日志是慢查询治理的主要数据源，配合 performance_schema 与 status 变量使用。注意慢日志本身有开销（记录写入），阈值设置合理（不宜过低）。开启慢日志 + 定期分析是数据库性能优化的基础。
慢查询日志是"发现慢 SQL"的入口。配置阈值与文件，定期分析并优化。配合 EXPLAIN 与工具聚合，是 SQL 性能治理的核心。阈值设置要平衡发现能力与开销。
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
活跃连接如何监控？pg_stat_activity 与 INFORMATION_SCHEMA.PROCESSLIST 的作用？
活跃连接监控用于查看当前数据库连接状态，发现连接堆积、慢查询、阻塞。PostgreSQL 用 pg_stat_activity 视图：显示每个连接的后端进程、用户、数据库、状态（active/idle/idle in transaction）、当前执行的 SQL、等待事件、start/query_start 时间等，可定位长事务、活跃查询、idle-in-transaction 连接。MySQL 用 INFORMATION_SCHEMA.PROCESSLIST（或 SHOW PROCESSLIST、performance_schema.threads）：显示连接 ID、用户、host、db、command、time、state、info（当前 SQL），可发现执行很久的查询、锁等待。监控活跃连接是排障与容量管理的基础，可发现连接数耗尽、慢查询、死锁、未提交事务。
pg_stat_activity 与 PROCESSLIST 是"看连接状态"的窗口。它们帮助定位慢查询、长事务、阻塞、连接堆积。监控活跃连接是数据库排障与容量管理的第一步。
-- PostgreSQL
SELECT pid, usename, state, wait_event_type, query
FROM pg_stat_activity WHERE state='active';
-- MySQL
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND<>'Sleep';
pg_locks 的应用是什么？在监控慢查询与容量方面如何使用？
pg_locks 是 PostgreSQL 的锁视图，显示当前所有锁（锁类型、锁定的对象、持锁/等待的进程）。应用：监控慢查询与容量——定位锁等待与阻塞（查询被锁等待，找到持锁进程并处理）；发现死锁与锁竞争；配合 pg_stat_activity 关联"等待者"与"持锁者"，判断哪个查询阻塞了哪个。在容量专项中，pg_locks 可发现锁竞争导致的吞吐下降，识别热点行锁。排障常用查询：找出阻塞其他事务的活跃进程、查看长时间持锁的会话。pg_locks 是 PG 锁与并发排障的核心工具。
pg_locks 揭示"谁持有锁、谁等待锁"，是定位锁等待、阻塞、死锁的入口。配合 pg_stat_activity 定位持锁者与阻塞 SQL。是并发与容量排障的核心。
SELECT blocked.pid AS blocked_pid,
blocking.pid AS blocking_pid,
blocked.query AS blocked_query
FROM pg_locks blocked
JOIN pg_locks blocking ON blocking.locktype=blocked.locktype
AND blocking.database IS NOT DISTINCT FROM blocked.database
AND blocking.relation IS NOT DISTINCT FROM blocked.relation
AND blocking.pid <> blocked.pid
WHERE NOT blocked.granted;
Buffer Pool 的命中率如何监控？pg_stat_get_db_buffer_hit_ratio 与 Innodb_buffer_pool_read_requests 的作用？
Buffer Pool 命中率反映缓存命中数据的比例，是容量与性能的重要指标。PostgreSQL 用 pg_stat_get_db_buffer_hit_ratio(oid) 函数或从 pg_stat_database 计算命中率（blks_hit/(blks_hit+blks_read)），衡量 shared_buffers 命中情况。MySQL InnoDB 用 Innodb_buffer_pool_read_requests（逻辑读请求数）与 Innodb_buffer_pool_reads（物理读次数）counter，命中率 = 1 - reads/read_requests。命中率高说明缓存有效、查询少走磁盘；命中率低说明缓存不足或查询设计差（扫描全表）。监控命中率：定期采样，结合缓存容量调优（shared_buffers/innodb_buffer_pool_size）。命中率是缓存容量与查询效率的反映。
命中率 = 缓存命中的请求比例。PG 用 blks_hit/blks_read，InnoDB 用 read_requests/reads。命中率低提示缓存不足或查询低效，是调优与容量规划的依据。
shared_buffers 与 innodb_buffer_pool_size 如何调优？
shared_buffers（PostgreSQL 共享缓冲区）与 innodb_buffer_pool_size（MySQL InnoDB 缓冲池）是数据库缓存容量的核心参数。调优原则：缓存应尽量容纳工作集（热点数据），提高命中率；但过大浪费内存且 OS 层也有缓存，需平衡。经验值：InnoDB buffer pool 通常设为物理内存的 50%~75%（配合其他内存），shared_buffers 通常设为物理内存的 10%~25%（PG 还有 OS 缓存配合）。调优依据：命中率、内存可用量、工作集大小。若命中率低且内存有余，增大缓存；若命中率已高，不可无序增大。调优后需监控命中率与内存压力，避免过度分配导致 OOM。缓存容量是"内存 vs 磁盘"的权衡，目标是让热点数据常驻内存。
缓存容量调优是"内存 vs 磁盘吞吐"的权衡。目标是让热点数据驻留缓存。shared_buffers 与 buffer pool 的经验比例不同，需结合命中率与内存实测调优。
PostgreSQL 排障时 pg_stat、pg_locks、pg_stat_statements 如何综合使用？
PostgreSQL 排障综合使用多个视图：pg_stat_activity（当前连接状态、活跃 SQL、长事务、idle-in-transaction）；pg_stat_database（数据库级统计：事务数、连接数、命中率、死锁数）；pg_locks（锁等待与阻塞，定位持锁者）；pg_stat_statements（SQL 语句执行统计：累计执行次数、耗时、扫描行数，按指纹识别热点/慢 SQL）。排障流程：先用 pg_stat_activity 看当前活跃与慢查询，用 pg_locks 定位锁阻塞，用 pg_stat_statements 分析历史统计找热点 SQL，用 pg_stat_database 看整体健康。综合使用才能定位"当前问题 + 历史趋势 + 根因"。pg_stat_statements 需启用 pg_stat_statements 扩展。
排障用"实时视图（activity）+ 锁视图（locks）+ 统计视图（stat_statements/stat_database）"组合。activity 看现状，locks 看阻塞，stat_statements 看历史热点。综合定位是 PG 排障的核心。
-- 慢 SQL 排行（pg_stat_statements）
SELECT query, calls, total_exec_time/1000 AS total_ms,
mean_exec_time/1000 AS mean_ms
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20;
Runbook 如何编写？故障分类、排查步骤、恢复命令如何组织？
Runbook（运维手册）是故障处理的可执行文档，包含：故障分类（按影响分级 P0-P3，如宕机、连接耗尽、慢查询、锁等待，每类对应的处理流程）；排查步骤（按顺序的诊断步骤：查看监控、日志、活动连接、慢查询、锁、执行计划，逐步缩小范围）；恢复命令（针对不同故障的具体命令：kill 连接、切换主从、回滚、扩容、重启）；预案与升级（何时升级、通知谁、回滚预案）。Runbook 要"可执行、经过演练、定期更新"，命令要验证过。写 Runbook 的目的是让运维在故障时按图索骥，减少误判与慌乱。故障分类决定响应的优先级与动作。
Runbook 把"故障怎么办"标准化。分类（P0-P3）定优先级，排查步骤定路径，恢复命令定动作。经演练验证的 Runbook 是故障快速恢复的保障。
MySQL 排障时 performance_schema、sys schema、slow_log 如何综合使用？
MySQL 排障综合使用：performance_schema（性能监控，events_statements_summary_by_digest 按指纹聚合 SQL、events_stages/locks 看等待与锁、命中率等）；sys schema（基于 performance_schema 的视图/存储过程，提供易读的排障查询，如 sys.io_global_by_file_by_bytes、sys.innodb_lock_waits、sys.session 等）；slow_log（慢查询日志，找慢 SQL 原文）。排障流程：用 sys schema 查锁等待（sys.innodb_lock_waits）、活跃会话（sys.session）、IO 热点；用 performance_schema 分析 SQL 统计与等待事件；用 slow_log 找慢 SQL 并 EXPLAIN 优化。三者结合：slow_log 看"慢"，performance_schema 看"统计与等待"，sys schema 提供"易用的排障视图"。综合使用定位慢查询、锁、IO 瓶颈。
MySQL 排障用"slow_log（慢）+ performance_schema（统计/等待）+ sys schema（易读视图）"组合。sys schema 封装 performance_schema 提供便捷排障入口。三者结合定位问题根因。
慢查询的优化手段有哪些？索引改写、SQL 改写、参数调优如何应用？
慢查询优化手段分三类：索引优化（加合适的索引、复合索引的顺序、避免索引失效，是最常见手段——慢查询通常因缺索引或索引选择差导致全表扫描）；SQL 改写（改写 WHERE 条件避免函数运算/隐式转换导致索引失效、改写 JOIN 减少驱动表扫描、改写子查询/分页、避免 SELECT *、减少扫描行数）；参数调优（调整优化器相关参数、缓存、内存、I/O 参数，如 join_buffer、work_mem、sort_buffer，让执行更高效）。优化流程：EXPLAIN 分析执行计划（是否全表扫描、索引选择、扫描行数）→ 找根因（缺索引/写不好/参数差）→ 针对性优化（加索引/改写 SQL/调参数）→ 验证效果。慢查询优化是"索引优先、SQL 其次、参数兜底"的层次。
慢查询优化层次：索引（最常用）、SQL 改写（消除低效写法）、参数（辅助）。EXPLAIN 定位根因是前提。优化的目标是减少扫描行数与执行耗时。
慢查询如何分析？EXPLAIN 执行计划解读与统计信息检查如何做？
慢查询分析的核心是 EXPLAIN（执行计划）解读与统计信息检查。EXPLAIN 解读：看访问类型（type，如 const/ref/range/index/full scan，full scan 最差）、使用的索引（key）、扫描行数（rows）、是否需要排序/临时表（Using filesort/Using temporary）、join 方式。通过 EXPLAIN 判断优化器是否选择了合理计划、是否全表扫描、是否索引失效。统计信息检查：优化器基于统计信息（pg_statistic / MySQL 的 index statistics）选择计划，若统计信息过期（ANALYZE 未跑）、数据倾斜、相关列，计划可能错误。分析流程：EXPLAIN 看计划 → 检查统计信息是否过期 → 必要时 ANALYZE/更新统计 → 结合实际行数（EXPLAIN ANALYZE）对比估算与实际 → 定位偏差根因。慢查询分析是"计划 + 统计"的双重检查。
慢查询分析的关键是"执行计划是否合理 + 统计信息是否准确"。EXPLAIN 看计划，统计信息检查看计划依据。两者结合才能定位"计划跳变/退化"的根因。
慢查询如何发现？slow_query_log、pg_stat_statements、performance_schema 如何配合？
慢查询的发现手段：slow_query_log（MySQL 慢查询日志，记录超过阈值的 SQL 原文）；pg_stat_statements（PostgreSQL 语句统计扩展，按指纹聚合 SQL 的执行次数、平均耗时、总耗时，可发现"单次不慢但累计很慢"的 SQL）；performance_schema（MySQL 实时统计，events_statements_summary_by_digest 按指纹聚合，可发现累计耗时高的 SQL）。配合使用：用 pg_stat_statements / performance_schema 按累计耗时排序发现"热点 SQL"（即使单次不慢，累计耗时长也是问题）；用 slow_log 看单次慢的 SQL 原文与执行细节。综合发现：慢日志看"单次慢"，聚合统计看"累计慢"，两者结合覆盖不同视角。发现慢查询后进入分析优化流程。
慢查询发现分"单次慢"（slow_log）与"累计慢"（pg_stat_statements / performance_schema 聚合）。两种视角结合，才能发现所有需要治理的慢查询。
EXPLAIN ANALYZE 如何读取每个节点的实际行数、循环次数与耗时？估算与实际差异巨大说明什么？
EXPLAIN ANALYZE 会实际执行查询并输出每个节点的实际行数（actual rows）、循环次数（loops）与耗时（actual time）。解读：每个节点显示"actual time=xx..xx rows=N loops=M"，其中 actual rows 是节点实际处理的行数，loops 是节点被执行的次数，actual time 中第一个数是返回首行前的耗时、第二个数是返回全部行后的耗时。某节点总耗时约等于"实际耗时 × loops"。估算行数（rows）与实际行数（actual rows）差异巨大，说明优化器基于的统计信息不准确（统计过期、数据倾斜、相关列导致估算偏差），导致优化器选择了错误的执行计划（如本应索引扫描却选了顺序扫描、join 算法选错）。此时需 ANALYZE 更新统计、用扩展统计（相关列）、或调整计划/加优化器提示。
EXPLAIN ANALYZE 用"实际行数 × loops"反映真实执行，是验证执行计划正确性的关键。估算与实际差异大说明统计信息失真或优化器缺陷，是计划跳变的根因。
统计信息失真为何会导致执行计划跳变？如何用 ANALYZE、扩展统计与计划基线稳定计划？
统计信息失真（数据倾斜、统计过期、相关列）会导致优化器估算行数错误，从而选择错误的执行计划。例如：数据倾斜使某值分布不均，统计的 NDV 不准，导致优化器误判该值的选择性，选择顺序扫描或错误索引；统计过期导致表行数变化后优化器仍用旧估算；相关列（如 where city and state 相关）使各列选择性独立估算失真，导致行数严重低估。这些都会使执行计划在索引扫描↔顺序扫描、连接算法（嵌套循环↔哈希连接）之间"跳变"，性能时好时坏。稳定计划手段：定期 ANALYZE 更新统计；用扩展统计（PostgreSQL 的 CREATE STATISTICS 处理相关列）；必要时用计划基线（如 Oracle 的 plan baseline、PG 的 pg_hint_plan 固定计划、MySQL 的索引提示）固定预期计划。优化器是"基于统计的猜测"，统计准确是计划稳定的前提。
计划跳变根因是"统计失真 → 估算错误 → 计划选择错误"。稳定手段：更新统计（ANALYZE）、扩展统计（相关列）、计划基线/提示（固定计划）。理解统计是理解优化器行为的关键。
pt-query-digest 如何按 SQL 指纹聚合慢日志？Query_time、Lock_time、Rows_examined/Rows_sent 如何体现治理优先级？
pt-query-digest 是 Percona 的慢日志分析工具，按 SQL 指纹（归一化 SQL）聚合慢日志，输出每个指纹的统计：总耗时、执行次数、平均/最大 Query_time（语句执行时间）、Lock_time（锁等待时间）、Rows_examined（检查行数）、Rows_sent（返回行数）等。它把"雷同 SQL 的不同参数"归一为一个指纹，聚合出每组 SQL 的整体代价。治理优先级判断：Query_time 高（总耗时/平均耗时大）说明执行慢；Rows_examined/Rows_sent 比值大（检查行数远大于返回行数）说明扫描浪费（缺索引或写法差），是治理重点；Lock_time 高说明锁等待严重。pt-query-digest 按总耗时排序输出排名，帮助确定"先优化哪些 SQL"。它是 MySQL 慢查询治理的标准工具。
pt-query-digest 用指纹聚合，从"总耗时、扫描/返回比值、锁等待"判断治理优先级。扫描行数远大于返回行数是最典型的优化信号。它把慢日志变成可排序的治理清单。
数据增长预测如何做？行数增长、索引膨胀、WAL 堆积如何评估？
数据增长预测用于容量规划，评估行数增长、索引膨胀、WAL 堆积带来的空间与性能压力。行数增长：基于历史增长速率（如日均插入量、月增长率）预测未来行数，评估表空间、查询性能、分库分表需求。索引膨胀：索引随数据增长而增大，且频繁更新/删除导致索引空洞（bloat），占用空间并影响查询性能，需评估膨胀率（pgstattuple、MySQL 碎片）并定期重建/VACUUM。WAL 堆积：高写入、长期未归档、checkpoint 不及时导致 WAL 文件堆积，占用磁盘，需监控归档与清理。预测方法：采集历史数据（表大小、行数、WAL 数量随时间），用趋势外推/线性/指数预测，结合业务增长（活动、用户）设定容量余量。数据增长预测是容量规划与扩容决策的依据。
数据增长预测涵盖行数、索引、WAL 三个维度。行数影响空间与查询，索引膨胀影响性能，WAL 堆积影响磁盘。基于历史趋势预测并预留余量是容量规划的核心。
审计日志（Audit Log）如何实现？pgAudit、MySQL Enterprise Audit 各有什么特点？
审计日志（Audit Log）记录数据库的访问与操作（谁、何时、做了什么、影响多少行），用于安全合规、风险追溯、事后调查。pgAudit 是 PostgreSQL 的审计扩展，通过配置审计哪些语句/对象/角色，把审计记录写入日志（含用户、语句、参数、返回值），支持细粒度审计（按语句类型、对象、角色）。MySQL Enterprise Audit 是 MySQL 企业版功能，通过审计插件记录连接、SQL 执行等审计事件到审计日志文件（JSON/XML），支持按用户、事件、操作过滤。审计日志实现：数据库扩展/插件 + 日志存储 + 定期采集与归档。审计日志有性能开销（记录每操作），需评估粒度与保留。审计满足合规（如等保、SOX）与安全追溯。
审计日志是"谁做了什么"的完整记录。pgAudit 与 MySQL Enterprise Audit 分别提供 PG/MySQL 的细粒度审计。审计日志有开销，需平衡粒度、保留与合规要求。
数据库日志有哪些分类？错误日志、慢日志、审计日志、WAL、binlog 各自的作用？
数据库日志分几类：错误日志（database error log，记录启动、错误、异常、警告，用于排障，如 MySQL error log、PG log）；慢查询日志（slow log，记录超过阈值的 SQL，用于慢查询治理）；审计日志（audit log，记录用户访问与操作，用于合规与追溯）；WAL/binlog（事务日志，记录变更，用于崩溃恢复、复制、PITR、CDC）。它们作用不同：错误日志看"故障"，慢日志看"性能"，审计日志看"安全"，WAL/binlog 看"数据可靠性"。日志管理：配置日志级别、滚动/归档、保留策略、监控告警（错误日志异常、慢日志增多、WAL/binlog 堆积）。分类理解有助于排障时"对症下药"。
数据库日志按用途分：错误（故障）、慢（性能）、审计（安全）、WAL/binlog（可靠性）。分类管理、滚动归档、监控告警是日志运维的核心。
Prometheus + Grafana 数据库监控的指标体系是什么？
Prometheus + Grafana 是主流监控方案：Prometheus 拉取指标（通过 exporter 暴露数据库指标），Grafana 可视化展示与告警。数据库监控指标体系：资源类（CPU、内存、磁盘、网络）；连接类（连接数、活跃连接、连接池）；性能类（QPS、TPS、延迟、执行时间）；缓存类（buffer pool/共享缓冲区命中率、内存使用）；日志类（WAL/binlog 生成与堆积、慢查询数量）；复制类（复制延迟、从库状态）；锁与等待类（锁等待、死锁、阻塞）。采集：MySQL 用 mysqld_exporter、PostgreSQL 用 postgres_exporter，暴露 Prometheus 指标。监控体系用于：实时看板、趋势分析、告警（触发阈值）、容量规划。指标体系要覆盖"可用性、性能、容量、异常"四个维度。
Prometheus+Grafana 用 exporter 采集、Prometheus 存储、Grafana 展示告警。指标体系覆盖连接、性能、缓存、日志、复制、锁等维度。是数据库可观测性的核心方案。
SQL 指纹（Query Fingerprint）的概念是什么？如何归一化 SQL 计算 hash？
SQL 指纹（Query Fingerprint）是把 SQL 归一化为"忽略字面量、保留结构"的形式，然后计算 hash，用于聚合"本质相同、参数不同"的 SQL。归一化：把 SQL 中的字面量（数字、字符串、时间）替换为占位符（如 ?），保留关键字、表名、列名、运算符等结构，使 SELECT * FROM t WHERE id=1 和 SELECT * FROM t WHERE id=2 归一化为同一指纹 SELECT * FROM t WHERE id=?。然后对归一化后的 SQL 计算 hash（如 MD5），得到指纹。用途：pg_stat_statements、performance_schema、pt-query-digest 等都用指纹聚合 SQL 统计，识别热点 SQL、按组治理。归一化要注意：避免误归一化（如把常量 WHEN 也替换）、稳定 hash（同 SQL 恒同指纹）。指纹是性能统计与安全审计的基础。
SQL 指纹 = 归一化（字面量→占位符） + hash。它把"结构相同、参数不同"的 SQL 归为一组，用于聚合统计与治理。归一化规则决定指纹的稳定性与准确性。
-- 归一化：SELECT * FROM t WHERE id=1 → SELECT * FROM t WHERE id=?
-- 指纹：对归一化 SQL 计算 hash（如 MD5）
数据库关键指标（QPS、TPS、延迟、命中率、连接数）如何监控？
数据库关键指标监控：QPS（每秒查询数，反映读负载，通过 status 变量或 performance_schema 统计）；TPS（每秒事务数，反映写/事务负载）；延迟（语句执行时间、连接建立时间，反映性能，从慢日志/统计表/监控探针获取）；命中率（buffer pool/共享缓冲区命中率，反映缓存有效性）；连接数（当前连接、活跃连接，反映连接压力与资源健康）。监控方式：MySQL 用 status 变量（Questions、Com_select、Com_insert）、performance_schema；PostgreSQL 用 pg_stat_database、pg_stat_activity。这些指标用于：实时看板、趋势分析、容量规划、告警（如连接数超阈值、QPS 突增、延迟升高）。指标组合使用才能全面反映健康（单一指标会误导）。关键指标是数据库可观测性的核心。
关键指标（QPS/TPS/延迟/命中率/连接数）从不同维度反映数据库健康。监控这些指标并设定告警，是容量与可用性管理的基础。指标需组合解读。
OpenTelemetry 如何接入数据库的可观测性？
OpenTelemetry（OTel）是开源的可观测性标准框架，统一 metrics、traces、logs 的采集与传输。接入数据库可观测性：用 OTel 采集器（Collector）接收数据库的指标（通过 exporter/receiver，如 MySQL、PostgreSQL 的 OTel receiver）与日志，统一格式输出到后端（Prometheus、Jaeger、Elasticsearch 等）；应用层用 OTel SDK 埋点，把数据库调用（SQL 执行）作为 span 记录，结合 DB 指标形成端到端可观测性（trace 关联 SQL 与耗时）。接入的好处：统一标准、避免厂商锁定、metrics/traces/logs 关联（一次调用从应用到数据库的完整链路）。数据库可观测性集成 OTel 后，可做分布式追踪（SQL 慢的根因定位到应用与 DB）、统一告警。OTel 是未来可观测性的主流方向。
OTel 通过统一标准接入 DB 指标与日志，应用层埋点把 SQL 调用纳入 trace，实现端到端可观测性与关联分析。它是可观测性标准化的方向。
pg_stat_activity 的应用是什么？
pg_stat_activity 是 PostgreSQL 的活动会话视图，显示每个后端进程的状态：PID、用户、数据库、客户端、状态（active/idle/idle in transaction）、当前执行的 SQL（query）、开始时间（query_start、xact_start）、等待事件（wait_event_type/wait_event）、application_name 等。应用：监控活跃查询（查长事务、慢查询）、定位 idle-in-transaction（未提交事务持有锁拖慢其他人）、查看连接来源与数量（容量管理）、配合 pg_locks 定位阻塞、查看等待事件（IO/锁等待）。常见排障查询：找执行最久的活跃查询、找 idle in transaction 超时的会话、按数据库统计连接数。pg_stat_activity 是 PG 排障的第一步，任何"库出问题"都先看它。
pg_stat_activity 是"看当前会话在做什么"的核心视图。长事务、慢查询、idle-in-transaction、连接数、等待事件都能看到。它是 PG 排障的入口。
-- 执行最久的活跃查询
SELECT pid, state, now()-query_start AS dur, query
FROM pg_stat_activity WHERE state='active' ORDER BY dur DESC LIMIT 10;
-- 长事务/未提交事务
SELECT pid, state, now()-xact_start AS dur, query
FROM pg_stat_activity WHERE state IN ('idle in transaction','active');
临时文件（temp file）如何监控与告警？
临时文件（temp file）是数据库执行排序、哈希、临时表等操作时写入磁盘的文件，当内存不足（work_mem/sort_buffer 不够）时溢出到磁盘。监控：PostgreSQL 看 pg_stat_database 的 temp_files 与 temp_bytes（临时文件数量与大小），MySQL 看磁盘临时表（created_tmp_disk_tables）与慢日志中的 Using temporary；监控临时文件大小与数量增长率。临时文件过多说明内存（work_mem、sort_buffer）不足，导致排序/哈希落盘，性能下降。告警：临时文件突增或持续增长触发告警。优化：增大 work_mem/sort_buffer（权衡全局内存）、优化 SQL（减少排序/哈希/临时表）、检查是否索引可避免排序。临时文件监控是"内存不足导致落盘"的重要信号。
临时文件是"内存不足→落盘"的信号。监控 temp_files/temp_bytes 与磁盘临时表，触发告警并优化（调大 work_mem、避免排序）。它是性能与内存容量管理的关键指标。
Little 定律（L = λ × W）在数据库容量规划中如何应用？
Little 定律 L = λ × W 指出系统中平均并发/在途数量 L 等于到达率 λ 乘以平均处理时间 W。在数据库容量规划中：L 可理解为"数据库中的平均并发请求数（in-flight）"，λ 为请求到达率（QPS/TPS），W 为平均请求处理时间（延迟）。应用：由 QPS 与平均延迟估算并发需求，判断是否需要扩容/加连接；若已知并发上限与延迟，可反推最大吞吐；用于判断"延迟升高是否因并发过高"。例如：若 QPS=1000、平均延迟=50ms，则平均并发 L=1000×0.05=50，据此判断连接池/并发设置是否足够。Little 定律帮助把"吞吐、延迟、并发"三者关联，是容量规划与性能分析的理论基础，但注意它假设稳态与线性（实际有排队效应）。
Little 定律把吞吐（λ）、延迟（W）、并发（L）关联，用于估算并发需求与容量。它帮助判断"当前并发是否超过容量"、指导扩容。适用于稳态近似。
压测场景如何设计？OLTP、OLAP、混合负载如何设计？
压测场景设计按负载类型分：OLTP（在线事务，短查询、短事务、高并发读写，如订单、支付操作，模拟高频小事务）；OLAP（分析查询，长查询、复杂聚合、扫描大量数据，如报表、数仓分析）；混合负载（OLTP 与 OLAP 混合，模拟真实业务同时有事务与分析）。设计要点：定义压测数据（与生产规模相当的库）、压测负载（按业务比例生成 SQL 混合）、并发量（逐步加压观察曲线）、指标采集（QPS、TPS、延迟、资源使用、错误率）。压测目的：验证吞吐上限、发现瓶颈（CPU/IO/锁/连接）、评估容量。压测指标用分位数（P99）反映尾部延迟。压测场景要贴近生产，避免"压的不真实"。
压测场景按业务类型设计（OLTP 短事务、OLAP 长查询、混合），用贴近生产的数据与负载，逐步加压测吞吐与延迟，定位瓶颈。分位数延迟是关键指标。
压测工具有哪些？sysbench、pgbench、TPC-C、TPC-H 各有什么特点？
压测工具：sysbench（通用基准测试工具，支持 MySQL 等，可测 OLTP（简化事务）、CPU、内存、磁盘、I/O，灵活配置，用于 MySQL 压测与容量评估）；pgbench（PostgreSQL 内置基准，默认 TPC-B 类事务，可自定义脚本，测 OLTP 简单事务）；TPC-C（标准在线事务处理基准，模拟商品订单/库存混合事务，测 OLTP 吞吐，如 tpc-c 工具、HammerDB）；TPC-H（标准决策支持/分析基准，22 条复杂分析查询，测 OLAP 性能）。选型：多功能通用压测用 sysbench；PG 压测用 pgbench；OLTP 标准基准用 TPC-C；OLAP 分析基准用 TPC-H。它们测不同负载（OLTP 短事务 vs OLAP 长查询），配合业务场景选择。压测工具用于容量评估、性能基准、调优验证。
压测工具分通用（sysbench/pgbench）与标准基准（TPC-C/TPC-H）。sysbench 灵活、pgbench 内置 PG、TPC-C 测 OLTP、TPC-H 测 OLAP。按负载类型选工具。
故障分级（P0-P3）的定义与响应流程是什么？
故障分级（P0-P3）按影响范围与严重程度定义：P0（严重故障，核心业务不可用、数据丢失、资损，需立即响应，全员/最高优先级）；P1（重大故障，部分核心功能不可用、影响大量用户，需快速响应）；P2（一般故障，非核心功能受影响、小范围影响，正常工作时间内处理）；P3（轻微问题，不影响业务，低优先级处理）。响应流程：根据故障等级触发相应响应——P0/P1 立即告警、启动应急小组、迅速止损（回滚/切换/降级）、修复、复盘；P2/P3 按 SLA 处理。分级目的是"按影响分配响应资源"，避免小故障占用过多资源、大故障响应不及时。响应流程包含：发现（监控告警）→ 分级 → 止损 → 定位修复 → 恢复 → 复盘总结。
故障分级把"影响程度"映射为"响应强度"。P0-P3 从紧急到低优先，响应流程按等级触发。分级是故障治理与资源分配的基础。
容量规划（Capacity Planning）的步骤是什么？测量、预测、扩容如何做？
容量规划（Capacity Planning）的步骤：测量（采集当前资源使用：CPU、内存、磁盘、连接数、QPS/TPS、延迟、数据量，建立基线）；预测（基于历史趋势与业务增长预测未来需求，如数据增长、QPS 增长、活动峰值，评估资源何时达到上限）；扩容（在预测到容量瓶颈前执行扩容：加机器/加内存/加磁盘/加连接/分库分表/缓存/只读副本，并验证扩容效果）。容量规划要"预留余量"（如 70% 水位告警），避免到极限才扩容。流程是循环的：测量→预测→扩容→再测量，形成闭环。容量规划的目标是"在业务增长前保障容量，避免性能退化与宕机"。工具：监控库、压测（测定容量）、容量模型。
容量规划是"测量→预测→扩容→再测量"的闭环。测量建基线，预测看趋势，扩容提前执行。预留余量是避免容量瓶颈的关键。
日志采集的链路（Filebeat/Fluentd → Kafka → Elasticsearch）如何工作？
日志采集链路 Filebeat/Fluentd → Kafka → Elasticsearch 是常见日志处理架构：Filebeat/Fluentd（采集器，从服务器/容器收集日志，做轻量解析与过滤，转发到下一级）；Kafka（消息队列，缓冲与解耦，削峰填谷，保证日志不丢失、可扩展，支持多消费者）；Elasticsearch（存储与检索，接收日志、建立索引、支持全文搜索与聚合分析，配合 Kibana 可视化）。链路作用：采集器负责收日志，Kafka 负责缓冲与解耦（应对突发、避免下游堆积），ES 负责存储与查询。数据库日志（错误、慢、审计）也可接入此链路，用于集中监控与排障。优势：高吞吐、可扩展、解耦、可实时检索。采集链路是日志可观测性（ELK/EFK）的基础。
日志链路是"采集→缓冲→存储检索"。Filebeat 采集、Kafka 缓冲解耦、ES 存储检索。该链路支撑日志的集中监控、告警与排障。
基线漂移（Baseline Drift）如何检测与告警？
基线漂移（Baseline Drift）指指标的正常水平在一段时间内逐渐偏离历史基线（如延迟从 50ms 慢慢涨到 200ms、内存使用率逐月上升），是"缓慢恶化"的信号，常被静态阈值漏掉。检测方法：建立动态基线（基于历史数据计算正常范围，如分位数、均值±标准差、时间序列模型），对比当前指标与基线，判断是否显著偏离；用趋势分析（指标的斜率/变化率）检测持续漂移。告警：当指标偏离基线超过阈值（如连续 N 个周期超过基线 P95）触发"基线漂移"告警，区别于静态阈值告警。基线漂移检测能发现"功能没报错但性能在恶化"的隐患（如数据增长、内存泄漏、配置退化）。动态基线比静态阈值更适应拥塞变化。
基线漂移检测用"动态基线 + 趋势分析"发现缓慢恶化。静态阈值漏掉慢漂移，动态基线能捕捉。它是容量与性能预警的重要手段。
基线的采集方法是什么？业务低峰期 vs 高峰期如何采集？
基线（baseline）是数据库各项指标的正常水平，用于比对与告警。采集方法：按时间维度采集，覆盖业务低峰期、高峰期、不同时段，因为不同时段的指标正常值不同（高峰的 QPS/延迟高于低峰）。采集策略：低峰期采集"空闲基线"（连接数、资源使用低）、高峰期采集"峰值基线"（峰值 QPS、峰值延迟、峰值资源），并结合业务周期（工作日/周末、活动）建立分时段基线。全面基线要覆盖：不同时段、不同业务类型、不同负载。基线用于设置动态告警阈值（对比当前与基线）与容量预测。基线的价值是"知道什么算正常"，为异常检测提供参照。采集要持续（定期更新）以反映演化。
基线采集要分时段（低峰/高峰/周期）覆盖，因为不同时段正常值不同。全面基线支撑动态告警与异常检测。基线需持续更新反映系统演化。
性能基线（Performance Baseline）如何建立？关键指标的稳态值如何确定？
性能基线（Performance Baseline）是数据库关键指标（延迟、QPS、连接数、命中率、资源使用）在"正常/稳态"下的参考值，用于异常检测与性能回归判断。建立方法：采集一段正常时段的指标，统计稳态值（如 P50/P95/P99 延迟、均值±标准差、分位数范围），作为基线；排除异常时段（发布、故障、压测）的数据，避免污染；按业务周期（时段/工作日）建立多条基线。稳态值确定：用统计量（分位数、均值、标准差）描述"正常范围"，超过稳态范围视为异常。应用：动态告警（对比当前与基线）、性能回归（发布后对比基线判断是否退化）、容量趋势。性能基线是"判断什么算正常"的依据，是性能管理的基础。
性能基线用稳态统计值（分位数、均值±标准差）描述正常范围。建立需排除异常时段、按周期分基线。它支撑动态告警与性能回归判断。
告警分级（P0-P3）的定义与响应时间是什么？
告警分级（P0-P3）按故障影响定义，并规定响应时间：P0（核心业务不可用/数据丢失/资损，需立即响应，如 5-15 分钟内响应，启动应急）；P1（重大故障，部分核心功能不可用，需快速响应，如 15-30 分钟）；P2（一般故障，非核心影响，正常工作时间内响应，如 4 小时）；P3（轻微问题，低优先级，如 24 小时内处理）。响应时间目标是"从告警到开始处理"的时限，与故障严重度匹配。告警分级与故障分级对应：故障分级定"严重度"，告警分级定"告警强度与响应时限"。分级要避免"所有告警都 P0"（告警疲劳）或"严重故障未高分"（漏报）。响应时间驱动值班与升级机制。分级是告警治理与响应效率的核心。
告警分级把"严重度"映射为"响应时限"。P0 立即响应、P3 低优先。分级需与故障分级、值班、升级机制匹配，避免告警疲劳与漏报。
告警去重（Dedup）与合并（Group）如何实现？
告警去重（Dedup）与合并（Group）用于减少告警风暴（同一故障触发大量重复/相似告警）。去重：对相同/相似告警（如同一主机恢复前反复告警）只保留一条或合并计数，避免重复打扰；实现用告警指纹（按告警内容归一化）去重，配合恢复前抑制。合并：把相关告警聚合为一条（如同一主机多指标异常合并为一条"主机异常"告警），或按告警规则/来源/时间窗口分组，减少告警数量。实现：告警系统（如 Prometheus Alertmanager、Zabbix、自研）配置抑制/分组/静默规则：分组（group by 标签）、抑制（高优先级抑制低优先级）、静默（维护窗口静默）。去重与合并让告警"更少但更准"，避免告警疲劳导致漏报。告警治理是运维可观测性的关键。
告警去重/合并用"指纹去重 + 分组聚合 + 抑制静默"减少告警风暴。目标是"告警少而准"，避免疲劳与漏报。这是告警治理的核心。
告警通道有哪些？邮件、短信、电话、Webhook、IM 如何选择？
告警通道用于把告警推送给值班人员，类型：邮件（成本低、信息全、适合低优先级与通知，但实时性差）；短信（实时性较好，适合中等优先级，但信息有限）；电话（最实时、能打断，适合 P0/P1 紧急告警，但打扰大）；Webhook（接入第三方系统/自研平台，可编程处理、自动化，适合触达工单/API）；IM（如钉钉、企业微信、Slack，实时性好、方便协作，适合团队通知）。选择原则：按告警优先级与接收人配置——P0/P1 用电话/短信/IM 强提醒，P2 用 IM/短信，P3 用邮件/IM；配合值班与升级机制（P0 未响应升级到电话+上级）。通道要"冗余"（主通道失败用备用）与"可验证"（确认送达到）。告警通道是"告警触达"的保障，按优先级分层配置。
告警通道按实时性与打扰程度分层：P0 用电话、P1 用短信/IM、低优先级用邮件。通道需冗余与升级机制，保证告警可靠触达。按优先级选通道是告警治理核心。
告警阈值（Threshold）如何设置？静态阈值 vs 动态阈值有什么区别？
告警阈值（Threshold）定义指标"异常"的边界，分静态与动态。静态阈值：设定固定值（如 CPU 90%、连接数 80%、延迟 500ms），简单直观，但无法适应指标波动（高峰期正常值可能被误报，低峰期异常可能漏报）。动态阈值：基于基线/历史数据动态计算正常范围（如基线 P95 ± 浮动、均值±标准差、时间序列预测），随负载与周期自适应，减少误报漏报，适合负载波动大的指标。设置原则：静态阈值适合稳定、有明确上限的指标（如磁盘、连接数上限）；动态阈值适合波动大的指标（QPS、延迟）；综合用"静态兜底 + 动态基线"。阈值设置要避免过低（误报/疲劳）与过高（漏报），并随系统演化校准。阈值是告警准确性的核心。
阈值分静态（固定值）与动态（基线自适应）。静态适稳定指标，动态适波动指标。二者结合（静态兜底+动态基线）兼顾准确与适应。阈值过高漏报、过低误报。
告警疲劳（Alert Fatigue）如何避免？
告警疲劳（Alert Fatigue）指告警过多/过吵，导致值班人员麻木、忽略真实告警，甚至把告警静默。成因：阈值过低（误报）、重复告警（未去重）、低价值告警多、未分级（全 P0）。避免方法：告警去重与合并（减少重复）；合理分级（P0-P3 分层，低优先级降噪）；阈值调优（动态阈值减少误报）；告警验证（每个告警有可执行动作，无动作的告警删除）；维护静默（维护窗口静默已知告警）；定期告警评审（清理无效规则）；强化"告警可行动"（告警应指向明确动作，不能只是噪音）。目标是"告警少而准"，让每个告警都值得关注，避免"狼来了"效应。告警疲劳是告警治理的核心问题。
告警疲劳是"告警过多→麻木→漏报"的恶性循环。避免靠去重、分级、阈值调优、可行动告警、定期评审。目标是"少而准"的告警。
cgroups 在数据库资源治理中如何应用？如何限制备份或分析任务的资源水位，与 ionice/nice 组合？
cgroups（control groups）在数据库资源治理中用于限制进程组的资源水位，避免备份/分析任务抢占在线业务资源。控制器：cpu（限制 CPU 使用率/配额）、memory（限制内存上限）、blkio（限制块 I/O 带宽/权重）、net（限制网络）。应用：把备份/分析任务放进 cgroup，用 cpu.max 限制 CPU 使用率、blkio 限制 I/O 带宽、memory 限制内存，防止其拖垮在线业务。与任务级优先级组合：cgroups 是"组级资源限制"（按组设定水位），ionice/nice 是"任务级优先级"（进程调度优先级）——ionice 设 I/O 优先级类（idle/best-effort，让备份在空闲时用 I/O）、nice 设 CPU 优先级；两者可组合：cgroups 限制资源上限（硬限制），ionice/nice 调整任务优先级（软调度），实现"备份用尽力但有限、不抢在线资源"。cgroups 适合容器化/系统d 环境，是资源治理的现代手段。
cgroups 做"组级硬限制"（CPU/内存/IO 配额），ionice/nice 做"任务级软优先级"。二者组合：cgroups 设上限防抢占，ionice/nice 调优先级。适合限制备份/分析任务的资源。
ionice 在备份窗口如何应用？I/O 优先级类如何限制备份对在线业务的影响？与 cgroup blkio 如何配合？
ionice 是 Linux 的 I/O 调度器命令，设置进程的 I/O 优先级类：idle（空闲类，仅在无其他 I/O 时使用，完全让位于在线业务）、best-effort（尽力类，按优先级 0-7 竞争，0 最高）、real-time（实时类，优先于所有，慎用）。备份窗口应用：用 ionice -c2 -n7（best-effort 低优先级）或 ionice -c3（idle）启动备份，让备份 I/O 在线业务空闲时使用，减少对生产 I/O 的干扰。与 cgroup blkio 配合：cgroup blkio 是"组级带宽限制"（限制备份组的 I/O 带宽/权重，硬限制），ionice 是"IO 调度优先级"（软调度）；两者配合——cgroup blkio 设置备份 I/O 带宽上限，ionice 设 I/O 优先级，实现"备份 I/O 有上限且让位于在线业务"。组合比单用更精细。注意：CFQ 调度器支持 ionice，现代（deadline/mq）支持有限，需验证。
ionice 用 idle/best-effort 类让备份 I/O 让位于在线业务，cgroup blkio 做带宽硬限制。二者配合实现"备份 I/O 有上限且优先让位"。这是备份限速的精细手段。
备份窗口的 SLA 如何设定？备份时长、I/O 影响与保留策略如何转为 SLO？超时与失败如何告警？
备份窗口的 SLA 通过可度量 SLO 设定。备份时长 SLO：设定备份需在窗口内完成（如"备份在 4 小时内完成"），度量备份时长并对比目标；对业务 I/O 影响 SLO：设定备份期间对业务的影响上限（如备份期间业务 P99 延迟增加不超过 X%、磁盘 I/O 使用率不超过 Y%），度量并监控；保留策略 SLO：设定备份保留天数/版本满足 RPO/RTO（如"备份保留 30 天、可恢复到任意时间点"），验证保留完整性。这些 SLO 需可度量：用监控采集备份时长、I/O 影响、备份可用性。超时与失败告警：备份超时（超过窗口）、备份失败（进程退出、校验失败、归档不连续）触发告警，并配合重试与通知。SLO 把"备份做得好不好"量化，指导备份策略优化。
备份 SLA 转 SLO：时长（窗口内完成）、I/O 影响（业务影响上限）、保留（满足 RPO/RTO）。超时/失败告警保证备份可靠性。SLO 可度量是备份质量治理的关键。
RTO/RPO 的定义与目标设定是什么？
RTO（Recovery Time Objective，恢复时间目标）是故障发生后系统恢复到可用状态的最大可接受时间，衡量"恢复有多快"；RPO（Recovery Point Objective，恢复点目标）是故障时可接受的最大数据丢失量/时间，衡量"能丢多少数据"（如 RPO=0 表示不丢数据、RPO=1 小时表示最多丢 1 小时数据）。目标设定：根据业务重要性与成本权衡——核心业务（支付、库存）设低 RTO/RPO（如 RTO=5 分钟、RPO=0），非核心业务设宽松目标（如 RTO=4 小时、RPO=1 小时）。RTO 影响备份频率、高可用架构、恢复演练；RPO 影响备份频率、日志归档、复制。目标设定后要落实到架构（备份、复制、日志）与演练验证。RTO/RPO 是容灾与备份策略的核心目标。
RTO 管"恢复多快"，RPO 管"丢多少数据"。目标按业务重要性设定，并落实到备份/复制/恢复架构与演练验证。核心业务低 RTO/RPO，次要业务宽松。
恢复演练的 Runbook 如何验证？
恢复演练的 Runbook 验证：在演练中按 Runbook 一步步执行恢复，验证 Runbook 的步骤、命令、责任人是否真实可行、无遗漏。验证要点：步骤是否可执行（命令能否跑通、有没有缺依赖）；命令是否准确（路径、参数、备份介质可用）；责任人是否明确（演练时是否有人执行）；结果是否可验证（恢复后能否确认数据一致）；RTO/RPO 是否达标（实测恢复时间与数据丢失）。验证流程：按 Runbook 全流程演练（含备份恢复、PITR、切换），记录每个步骤的耗时与问题；演练后修订 Runbook（纠正命令、补充步骤、更新责任人）。Runbook 验证是"把预案变成可执行、可靠"的过程，只有演练验证过的 Runbook 才可信。验证发现的问题要整改并复测。
Runbook 验证是在演练中实测其可执行性：步骤、命令、责任人、结果验证、RTO/RPO。演练后修订 Runbook。未验证的 Runbook 在真实故障时不可靠。
SQL 指纹的最佳实践是什么？如何归一化字面量得到稳定指纹？错误归一化对性能统计与安全审计有什么影响？
SQL 指纹最佳实践：归一化字面量——把数字、字符串、时间等字面量替换为占位符（?），保留表名、列名、关键字、运算符等结构，使"结构相同、参数不同"的 SQL 归为同一指纹。得到稳定指纹：统一大小写、统一空白、规范化字面量（区分常量与占位符）、避免误归一化（如不把语义上的常量条件也替换导致该组 SQL 失真）。错误归一化的影响：性能统计层面——归一化过头（把不同结构 SQL 误归一组）会混淆统计（把不同 SQL 的耗时混在一起，平均失真，无法定位真正的热点/慢 SQL）；归一化不足（该归一化的没归一化）会导致同一 SQL 因参数不同而产生多个指纹，统计分散、无法聚合热点。安全审计层面——指纹用于审计分组，错误归一化可能掩盖特定危险 SQL 的变化（如某条带敏感参数的 SQL 被归入大量普通 SQL 中，审计无法识别），或造成审计日志不精确。因此归一化规则要精确、稳定，兼顾聚合与区分。
指纹归一化要"精确稳定"：正确归一化字面量，勿过度或不足。过度归一化混淆统计、不足归一化分散统计，都影响性能定位与安全审计。归一化规则是指纹质量的关键。
WAL 日志的容量与归档策略如何设计？
WAL 日志的容量与归档策略：WAL 容量——WAL 文件（segment）持续产生，需管理避免磁盘满。容量关键：高写入会产生大量 WAL，若归档不及时或 checkpoint 不及时，WAL 堆积。归档策略：开启 WAL 归档（archive_mode + archive_command 或 pg_receivewal），把 WAL 归档到归档存储（满足 PITR 与长期保留）；同时管理在线的 WAL 文件（保留下限由 max_wal_size 与 checkpoint 控制，归档成功的 WAL 可被清理）。保留策略：归档 WAL 按 RPO/RTO 保留（如保留 30 天），满足 PITR 需要；监控 WAL 目录大小与归档进度，避免堆积。若归档失败/中断，WAL 会堆积导致磁盘满，需告警。容量估算：WAL 生成速率 × 保留时间。WAL 容量与归档是 PG 运维与容灾的基础。
WAL 容量管理靠"归档 + 清理 + 监控"。归档满足 PITR，在线 WAL 由 checkpoint 控制，归档失败须告警防止堆积。WAL 容量估算用生成速率×保留时间。
binlog 的容量与清理策略如何设计？
binlog 的容量与清理策略：binlog 持续产生，需管理避免磁盘满。容量关键：高写入产生大量 binlog，若保留过多且未清理，磁盘耗尽。清理策略：MySQL 用 expire_logs_days（或 binlog_expire_logs_seconds）设置自动清理过期 binlog（按保留天数/秒数）；手动用 PURGE BINARY LOGS 清理；配合归档（把 binlog 备份到异地/存储）后清理本地的。保留策略：binlog 保留时间需满足复制（从库未消费的 binlog 不能删）、PITR（恢复需要）、CDC（消费进度）需求，通常保留数天到数周。监控 binlog 目录大小与清理进度，避免堆积。若从库/CDC 落后，binlog 不能删（会断复制）。容量估算：binlog 生成速率 × 保留时间。binlog 容量管理是 MySQL 运维与容灾的基础。
binlog 清理靠自动过期（expire_logs_days）与归档。保留需满足复制/CDC/PITR 需求，落后时不能删。监控 binlog 大小防止磁盘满。binlog 容量是 MySQL 运维关键。
QPS 增长预测如何做？业务增长与活动峰值如何评估？
QPS 增长预测用于容量规划，评估未来负载以决定扩容。预测方法：基于历史 QPS 趋势（日/周/月增长曲线）做趋势外推（线性/指数），结合业务增长（用户增长、业务量增长、新功能带来的流量）预测常规增长；结合活动峰值（大促、秒杀、促销活动的峰值流量）评估峰值需求（峰值 QPS 通常是常态的 5-10 倍或更高）。预测时要考虑：季节性（节假日、工作日）、活动（大促）、功能上线（新入口）。评估结果用于判断"当前容量能否支撑增长与峰值"，规划扩容（加机器、加缓存、分库分表、限流）。QPS 预测要"留余量"（峰值预留 + 安全系数），并配合压测验证容量。QPS 增长预测是容量规划的核心输入。
QPS 预测结合"历史趋势外推 + 业务增长 + 活动峰值"评估负载。峰值预留余量、压测验证容量。预测驱动扩容决策，避免容量瓶颈。