块层、日志与容量治理

• 写回缓存（write-back cache）：设备（盘/SAN 控制器）先确认到缓存即返回成功——断电丢数据
• 电池/电容保护（BBU/超级电容）：断电时缓存数据由电池供电刷入 NAND——使"写回缓存"也能持久（RAID 卡、企业 SSD 的 PLP）
• 持久性边界：软件 fsync 的保证依赖"设备对 flush/FUA 的兑现"与"控制器缓存是否断电保护"

持久性的完整链条：一、写回缓存——设备（企业盘、RAID 控制器、SAN 阵列）为性能把写入先收进 DRAM 缓存、立即返回"完成"（写回模式）：断电时缓存内容丢失（数据"丢失"但已向软件确认）——这是"写回缓存"的固有风险；对应"直写（write-through）"每写都落介质（慢但无缓存丢失面）。二、flush——软件（fsync/fdatasync）最终映射为设备命令 FLUSH CACHE（或带 FUA 的写）：把缓存中的脏数据强制写回非易失介质并等待完成——fsync 的持久保证"以设备兑现 flush 为准"；FUA（Force Unit Access）——写命令本身携带"持久"语义：该条写必须直接落到介质（不缓存或强制穿透），免去单独的 flush 命令（SATA/NVMe/SCSI 的 FUA 位）；软件栈中 O_SYNC/O_DSYNC 与文件系统的"barrier 写"（REQ_FUA/REQ_PREFLUSH）对应使用。三、电池/电容保护（BBU/超级电容/PLP）——企业 RAID 卡与企业 SSD 配备电池或超级电容：断电时控制器有足够电力把写回缓存中的数据刷入 NAND——此时"写回缓存"在断电后不丢数据（缓存是"受保护的暂存"），设备可以在"不牺牲持久性"的前提下用写回缓存提速。四、持久性边界由此分层：无保护的写回缓存（消费级盘默认）——断电丢最近写入（fsync 的语义依赖"flush 时数据已到介质"，若设备在 flush 前就缓存了"确认"则 fsync 也救不了（设备谎报/缓存未刷新——劣质固件））；有 PLP 的设备——flush/FUA 保证可靠，写回缓存仍安全；软件可见的边界：fsync 返回=数据在"设备的持久域"（对 PLP 设备即 NAND，对无保护设备必须是实际落盘后的确认）。

工程影响：一、数据库/存储系统依赖"fsync 后断电不丢"——需确认硬件是"PLP 企业盘"或"RAID 卡 BBU + 写回模式"（否则 fsync 只是安慰）；二、消费级环境（云盘、虚拟机磁盘）的"写缓存"语义由 hypervisor/云厂商定义（如 AWS EBS 的写缓存策略、virtio 的 flush 透传）——云盘的 fsync 保证依赖其持久化承诺；三、FUA vs flush 的吞吐差异：FUA 每写一次穿透（随机小写开销大），flush 是批量化（组提交）；文件系统用"写数据（普通）+ 元数据 barrier（FUA/FLUSH）"组合；四、测试：断电测试（power-fail test）验证实际持久性（写后立即断电、重启检查）；"sync; 断电"与"无 sync 断电"区分缓存保护。排查：hdparm -I 看 Cache 特性、smartctl 看 PLP/电容状态、/sys/block//queue/write_cache（write back/through 显示）；RAID 卡（megacli/storcli 的 cache policy）确认 BBU 状态。结论：持久性边界 = "软件 fsync（flush/FUA）× 设备兑现 × 控制器断电保护"三者的交集——任一层不可信，持久保证即不可信。

以"写回缓存的确认语义、flush/FUA 的持久命令、BBU/PLP 的断电兜底"三层讲清持久链，再落到"fsync 的保证依赖设备兑现"的工程结论。

• SQ/CQ 队列对：提交队列（命令）+完成队列（完成），每队列对可绑核（多队列并行）
• 轮询（polling/IOPOLL）：应用轮询 CQ 而非等待中断——适合低延迟小请求（无中断延迟），代价是 CPU 占用
• 负载匹配：吞吐型（大块、批量）用聚合中断；延迟敏感（高频小请求）用轮询；混合用自适应

NVMe 的命令模型：应用把命令写入提交队列（SQ），设备完成后在完成队列（CQ）放完成条目并（默认）发中断；多个队列对（每 CPU 一对）配合 IRQ affinity 实现并行（每核独立提交/收割）。三种完成通知方式的负载适配：一、中断模式（默认）——每个 CQ 完成触发 MSI-X 中断，驱动在中断里处理：适合"低频大块"负载（中断频率=完成批次频率，可接受）；二、中断聚合（coalescing，NVMe 的 Interrupt Coalescing 特性：聚合时间窗口 + 聚合阈值）——多个完成条目聚合成一次中断：降低中断频率与 CPU 打断次数，适合"高吞吐批处理"（大块顺序读写、备份、批量导入）——代价是引入聚合延迟（单个请求的完成延迟被窗口延迟）；三、轮询（polling，用户态用 io_uring 的 IOPOLL 或 SPDK 的轮询模式，内核的 /sys/block/.../queue/io_poll 与 HIPRI）——应用/驱动不等待中断，直接轮询 CQ 头部：消除中断延迟与上下文切换，适合"高频小请求、延迟敏感"负载（数据库日志、低延迟存储引擎、高频交易）——代价是轮询线程占满 CPU（功耗/核占用），且空闲时仍在轮询（空转）；Linux 的 io_uring IOPOLL 要求 O_DIRECT。

负载匹配矩阵：大块顺序/批处理（吞吐优先）→ 中断聚合（或普通中断）；小块高频（延迟优先）→ 轮询（IOPOLL/HIPRI）；混合负载 → 按队列分流（部分队列中断、部分轮询——NVMe 多队列对天然支持"不同队列不同通知模式"）；延迟与吞吐的折中还可调节：聚合窗口调小（延迟-中断频率平衡）、轮询加退避（空转时 sleep 短时间）；NVMe 的 Adaptive Interrupt Coalescing（部分控制器）按负载动态调窗口。工程实践：SPDK（用户态轮询）在"纯存储转发"场景可达百万 IOPS 级低延迟；内核路径用 io_uring + IOPOLL 获得近似；fio 的 ioengine=io_uring 对比 polling=1/0 实测收益与 CPU 代价；尾延迟敏感（P99）业务用轮询更稳（中断合并制造尾部尖峰），吞吐型业务聚合更省 CPU。注意轮询与 CPU 绑定的配合（轮询核不跑其他任务）、功耗与云计费的考量。

以"完成通知方式（中断/聚合/轮询）与负载特征（吞吐/延迟）"的匹配为主线，给出各模式适用场景与 io_uring IOPOLL/SPDK 的工程落点。

• scrub：读全部数据与元数据块、校验 checksum、发现不一致时从冗余副本重建（自动修复）
• 与 mdadm+LVM（传统 RAID）：mdadm 无 checksum（无法检测静默损坏）、重建/扩容/降级语义不同、BTRFS 无"重建同步"的阵列概念（文件系统级冗余）
• 运维差异：scrub 周期 vs mdadm check、设备替换（replace vs hot-swap）、写放大（COW+RAID5 的写放大是著名问题）

BTRFS 的 RAID 与校验：写入走 COW（新数据写新块、更新树指针），RAID1 把数据写两份（镜像）、RAID5/6 计算奇偶校验块；同时 BTRFS 对所有数据块与元数据块存储 checksum（crc32c/xxhash 等）——读取时校验，不一致（静默损坏、bit rot）即检测出。scrub 的行为由此决定：scrub 全盘读取所有数据与元数据块并校验 checksum；发现"校验失败但副本完好"时，从冗余副本（RAID1 的另一副本、RAID5/6 的校验重建）自动修复损坏副本（错误修复）；发现"无冗余可重建"（如单盘）时报告错误（不可恢复）。因此 scrub 是"在线完整性校验 + 自动修复"，粒度是"块级 + 校验和"，能发现 mdadm 看不到的静默数据损坏（bit rot、固件错误、DMA 错误）。

与传统 mdadm+LVM 的运维差异：一、损坏检测能力——mdadm 的 check 只做"RAID 一致性检查"（比较镜像/校验重建，无内容校验和），无法发现"两副本同样错误"的静默损坏；BTRFS 的 checksum 可发现（两副本都不匹配时报告且不盲目覆盖）；二、修复语义——mdadm 坏块依赖"磁盘错误信号"（介质错误时用镜像/校验重建），对"无声损坏"无感知；BTRFS scrub 主动全盘校验+重建；三、阵列管理——mdadm 有"阵列装配（mdadm --assemble）、重建（resync）、降级"等块层概念，BTRFS 是文件系统级冗余（无独立阵列设备视角），设备替换用 btrfs replace（在线热替换）；四、写放大与性能——BTRFS RAID5/6 的 COW 写放大与"RMW（读-改-写）"开销是著名问题（随机小写性能差、旧内核 RAID5 有稳定性争议），mdadm 的 RAID5 写放大相对可控；五、弹性——BTRFS 冗余与快照/子卷结合（快照不占用完整空间），mdadm+LVM 的 LVM 快照（COW）与之相比功能与一致性语义不同；六、运维命令——scrub 周期（btrfs scrub start/status、systemd timer 定期）、mdadm --check/--monitor；故障场景：BTRFS 缺副本时挂载仍可用（降级）、mdadm 需装配降级阵列。工程选型：追求"静默损坏检测+自动修复+文件级管理"选 BTRFS（或 ZFS）；追求"块层传统 RAID 的成熟与可预测性能"选 mdadm；生产实践中 BTRFS RAID5/6 需新内核+严格测试，RAID1/10 与单盘+scrub 是更稳的起点。

以"COW+checksum 决定 scrub 的校验-修复能力"为主线，对比 mdadm 的"无内容校验"与阵列管理差异，落到运维命令与选型。

• XFS：AG（allocation group，约 1GB 一组，带独立空闲空间 B+树与锁）——多核并发分配天然并行（不同 AG 不同锁）
• Btrfs：chunk（块组，按类型（数据/元数据）+profile 分配）——空间分配经全局空间管理（space_info 的锁与计数器），并发分配存在全局争用（改进：per-cpu 计数器与延迟分配）
• 扩展性差异：XFS 的 AG 粒度锁 vs Btrfs 的全局空间管理在"多核多线程写"下的吞吐/分配延迟；测试（fio 多 job）的收益对比

XFS 的分配架构：文件系统按固定大小划分为 allocation group（AG，默认约 1GB，磁盘上一段连续空间），每个 AG 拥有独立的空闲空间管理结构（free space B+树：bnobt/cntbt）与独立的 AGF/AGI 锁——文件数据分配按"AG 亲和"策略（尽量在同一 AG 或按 inode 的 AG 选择），多核并发写时不同线程/文件在不同 AG 分配块，锁互不干扰：分配路径的并发扩展性好（吞吐随核数近线性增长，尤其大文件多线程写）。Btrfs 的分配架构：空间按 chunk（块组）管理——chunk 是"按用途类型（数据/元数据/系统）与 profile（单/RAID）划分的大块"（通常 1GB 级），chunk 内部的块分配经全局的 space_info（每种类型一个）与块组（block group）的空闲空间树：分配时需在对应 space_info 的锁/计数（total_bytes、bytes_used、bytes_pinned 等）与块组空闲树（free space cache）上操作——多核并发分配存在"全局 space_info 与块组锁"的争用点（早期版本明显，后经"每 cpu 计数、延迟分配、free space tree 优化"改善）。

扩展性差异的体现：一、锁粒度——XFS 的 AG 级锁天然分区（每 AG 独立），Btrfs 的 chunk 分配在"类型级空间账本 + 块组树"上有全局性（同一块组内并发分配串行化）；二、分配策略——XFS 的"AG 选择"配合 inode 亲和减少跨 AG 竞争，Btrfs 的"块组轮转/空闲空间缓存"在写放大与并发间权衡；三、实测——多核（16~64 核）多线程顺序/随机写的吞吐与分配延迟：XFS 通常更平滑（无分配锁瓶颈），Btrfs 在早期内核版本可见分配路径的锁竞争（"空间分配成为瓶颈"的 report），现代版本（free space tree、extent 预分配、per-cpu）已大幅改善但"空间账本集中"的架构差异仍在；四、元数据并发——XFS 的 inode 分配（AGI 锁）与 Btrfs 的元数据 COW（分配+树更新）路径都随并发放大，Btrfs 的元数据写放大（COW）使"分配-写入"耦合更强。工程实践：基准用 fio 多 job（不同文件）对比两种 fs 的扩展性（IOPS 随 job 数增长曲线）、分配延迟（fio 的 clat）；选型：高并发多线程写入（对象存储、日志采集）XFS 的 AG 并行优势明显；Btrfs 适合"功能优先（快照/校验/子卷）且写放大可接受"的场景；调优：XFS 的 agcount（mkfs 时）、Btrfs 的 block group 大小与 profile 选择影响分配行为。结论：扩展性差异的本质是"静态分区锁（AG）vs 动态全局账本（chunk/space_info）"的并发架构选择。

以"AG 静态分区锁 vs chunk 全局空间账本"对比两 fs 的分配并发模型，说明多核吞吐曲线差异与 Btrfs 的演进优化，落到 fio 验证与选型。

• NVMe 健康信息（Get Log SMART/Health 的 critical_warning 位：温度、可靠性、介质、备用空间等）
• 内核侧动作：thermal framework（devfreq/thermal zone 的 cooling）与驱动回调（nvme 的温度管理策略：nvme_core 的温度读取与"暂停 IO/降速"选项）
• 可调性：控制器内部 throttle 策略（固件），内核侧可调的是监控与响应（如 nvme 的 thermal 采样、系统 thermal 的 cooling device、用户态兜底：io 限速/关机）

NVMe 的 critical warning：SMART/Health 日志（Get Log Page 02h）的 critical_warning 字段有多个位（温度超阈值、可靠性下降、介质降级、备用空间不足、持久内存只读等）；温度还有 Composite Temperature 与温度阈值（Temperature Threshold 特性）。Linux 内核的处理链：一、驱动监控——nvme 驱动周期性（或按事件）读取 SMART/Health 日志与温度；二、thermal 集成——nvme 控制器暴露为 hwmon/thermal 设备（/sys/class/thermal/thermal_zoneN、/sys/class/hwmon）：内核 thermal 框架（thermal zone + governor）可把温度作为输入，与 cooling device（如风扇、CPU 降频）联动；三、驱动响应——温度超"临界"（critical_warning 置位）时驱动记录/上报（dev_warn、健康状态标记）；部分控制器固件自带"热节流"（thermal throttling：控制器自动降低性能/关闭部分通道保护自身——这是固件策略，内核只能观测（SMART 的 Throttle Status））；四、用户态/系统兜底——nvme-cli（nvme smart-log 查看 critical warning）、监控系统（温度阈值告警）、必要时停机/降载。内核侧的"可调"空间：一、thermal 框架参数（thermal zone 的 trip points、governor 策略）——系统级可配；二、nvme 驱动的温度管理参数：nvme_core 模块的"temperature polling 间隔"与部分平台的热策略参数；三、IO 层面的应用/内核限速（如通过设备 QoS、nvme 的 io 队列暂停）——可调但属于"外围响应"；控制器固件内部的 throttle 曲线通常不可调（固件决定），但部分控制器暴露"性能管理模式"（如通过 NVMe 的 Set Features 的温度阈值配置，让控制器按阈值切换性能档）。

工程实践：一、监控——部署 smartctl -a / nvme smart-log 轮询 + 温度告警（critical_warning 非零即处理：若温度位置位需立即散热/降载）；二、thermal 联动——确认 /sys/class/thermal 中 nvme 的 zone 存在并与风扇/降频 cooling 关联（服务器 BMC 与内核 thermal 的配合）；三、预期管理——理解"控制器自节流"（固件保护：过热时吞吐骤降是保护性行为，不是故障）；四、可调项——trip point 温度（用户可设）、nvme_core 参数、QoS（io 权重）；五、测试——用 fio 高负载加热 + 观察 SMART 温度与 throttle 状态（nvme smart-log 的 percentage used 与 throttle 计数），验证散热设计。注意：温度类 warning 的"自动降速"由固件执行时，软件看到的延迟/吞吐退化是正常保护；云环境（托管磁盘）由厂商热管理。

以"驱动监控→thermal 框架→固件节流→用户态兜底"的链路讲清处理机制，再区分"固件策略不可调、内核/系统层可调"的边界。

• metadata_csum：为所有元数据块（inode、位图、目录、扩展树等）加校验和（crc32c），检测静默元数据损坏
• 权衡：性能开销（每次元数据读写计算校验）、兼容性（旧内核/工具无法挂载带 metadata_csum 的 fs）、覆盖范围（journal_checksum 只管日志、metadata_csum 覆盖全部元数据但不覆盖数据）
• 崩溃一致性验证：journal 的"提交点"与校验和配合（先写日志再应用），checksum 增加"检测损坏而非仅依赖顺序"的可靠性

两个选项都服务于"崩溃/静默损坏的检测"，但层次不同：一、journal_checksum（挂载选项 journal_checksum）——给 journal 中的记录（描述符块、数据块、提交块）加 crc 校验：崩溃或硬件错误导致"日志区本身被部分写/损坏"时，重放日志前先验校验和，损坏的日志记录被丢弃（不盲目重放），防止"把垃圾当作元数据应用"；权衡：日志写多一次 crc 计算（小额开销）、保护范围限于日志区（日志之外的数据/元数据不受保护）。二、metadata_csum（mkfs 特性，modern ext4 默认）——给所有元数据块（超级块、块/ inode 位图、inode 表、目录项、扩展树块等）持久化存储 crc32c 校验和：任何原因（bit rot、固件错误、错误写入、部分写）造成的元数据损坏在读取时被检测（报错/进入只读模式），是对"静默元数据损坏"的全局防护；权衡：元数据读写都需计算/验证校验和（元数据密集负载有可测开销）、向后不兼容（旧内核/工具链无法挂载/操作该文件系统，需 e2fsprogs 新版本）、校验和本身需随元数据更新（写路径增加工作）。

工程权衡对比：一、性能——metadata_csum 的 crc32c 有硬件加速（SSE4.2 的 crc32 指令）时开销很小，但"每元数据块读写算校验"在元数据密集（大量小文件创建/删除）时可见；journal_checksum 的日志 crc 在每次事务提交时计算（与日志写带宽耦合）；二、可靠性——journal_checksum 防"日志区损坏导致的重放错误"（torn log 检测），metadata_csum 防"一切元数据静默损坏"（含日志应用后的位图/inode 损坏）；两者互补（日志的"提交点+校验"保证重放正确性，元数据校验保证盘上结构正确）；三、崩溃一致性验证的完整图景——ext4 的崩溃一致性 = "顺序（先日志后应用）+ 提交点（commit 块）+ 校验和（防损坏日志/元数据）"：校验和不能替代顺序（防止"错误但完整的写入"），但把"损坏检测"从"靠运气"变为"确定性"；四、兼容与迁移——metadata_csum 是"不可逆特性"（升级后旧工具不可用），大分区迁移需规划；五、数据路径——两者都不覆盖文件数据（数据损坏由应用/上层校验（如数据库 checksum、btrfs 式数据校验不在 ext4 范围）——这是 ext4 与 COW 文件系统的能力差异。实践：新部署默认开启 metadata_csum（内核 4.4+/e2fsprogs 1.43+），journal_checksum 建议开启（低开销）；监控 e2fsck 的校验报告与"Read-only" 状态；压测对比开启前后的元数据吞吐）。

以"日志区校验 vs 全元数据校验"分层讲清两个选项的机制与覆盖范围，从性能/兼容/崩溃验证三方面权衡，并指出数据路径不在保护内。

• flush 行为：guest fsync → virtio-blk flush 请求 → 宿主缓存刷盘（writeback 下 flush 是关键语义）
• hypervisor 透传策略：virtio-blk 的 cache 属性（none/writeback/writethrough）、scsi 直通（lun passthrough）与云厂商的存储层（网络盘：EBS 类）——"确认成功"的持久性由存储后端决定
• 陈旧读：writeback 下写确认后读（经宿主缓存）应一致（页缓存一致），但"存储后端多副本/延迟复制"或"缓存未失效"会造成读旧数据（如 qemu 的缓存与 guest 页缓存不同步、NFS 类后端）

云盘场景"写成功但读旧"的根因链：一、cache mode 决定"写确认的时机"——QEMU 的 virtio-blk writeback 模式：guest 的写被接收进宿主机的页缓存（host cache）即返回成功（guest 以为已持久）；writethrough/none：写穿透到宿主盘（或后端存储）才确认。writeback 下"成功≠持久"（断电/宿主崩溃丢缓存），"成功=写入宿主缓存"——若读路径与写路径的缓存视图不一致（如 guest 内页缓存与 qemu 缓存、或后端存储的缓存/副本），读可能看到旧版本。二、flush 行为——guest 的 fsync/fdatasync 经 virtio 的 flush 请求（VIRTIO_BLK_T_FLUSH）通知 qemu 把宿主缓存刷到后端存储（落盘）——flush 的语义由 qemu 的 cache 模式映射：writeback 下 flush="刷宿主页缓存到后端"（若后端也有缓存（网络存储的服务器缓存）则再透传 flush）；若 hypervisor 或后端"吞掉 flush"（配置不当/存储层的 write-through 假象），fsync 也不可靠。三、hypervisor 透传策略——a) virtio-blk 直传（cache=none 时 guest 用 O_DIRECT 语义直写宿主块设备）——成功=写入设备（设备写缓存语义）；b) scsi 直通/设备透传（virtio-scsi + lun passthrough）——guest 的 SCSI 命令直达物理盘/SAN（控制器缓存语义由后端决定）；c) 网络盘后端（qemu 的 rbd/iscsi/nfs 驱动）——写确认与 flush 由后端协议实现（如 RBD 的写确认=副本写入、flush=全部副本持久），后端多副本"异步复制"（primary 确认、secondary 延迟）会出现"读旧副本"窗口。四、"陈旧读"的具体机制——guest 写成功（进入宿主/后端缓存）后立即读：若读路径命中"更旧的缓存/副本"（如 qemu 缓存未按写入失效、后端读走旧副本、guest 页缓存与块缓存不一致（绕过页缓存的怪异组合））则读到旧数据；正常情况下同缓存内读写一致（写后读新），"陈旧"多来自"跨缓存/跨副本"或"flush 未执行"。

工程应对：一、确认 cache mode——qemu 的 -drive cache= 与云厂商的磁盘类型（EBS 的 gp3/io2 的持久性承诺、阿里云 ESSD 的写缓存策略）；二、guest 内正确 fsync（应用依赖持久性时必须 flush，writeback 下不 flush 断电即丢）；三、"写后读旧"排查顺序——guest 页缓存（文件缓存 vs O_DIRECT 路径）、qemu/后端缓存失效、后端多副本延迟（读走旧副本——云厂商的"最终一致"读策略）、flush 是否透传（qemu 的 cache=none 时 flush 直发设备；网络后端需确认 flush 支持）；四、验证——写后读一致性测试（含断电测试）、dd conv=fsync 与 O_DIRECT 对比、smartctl/nvme flush 观测；五、选型——延迟敏感且强持久需求用 writethrough/none + 后端持久保证（或 io_uring 的 FUA 路径）；吞吐优先可 writeback + 依赖 flush 纪律。结论：写成功与读新鲜的语义边界 = "缓存确认点 × flush 透传 × 后端复制策略"三者决定，云环境的"持久性 SLA"以厂商文档为准。

以"写确认时机（cache mode）→ flush 语义链 → 后端复制/缓存策略"三层还原"写成功读旧"的成因，并给排查顺序与选型。

• 顺序要求：日志落盘先于"对应的数据页修改落盘"（否则崩溃后数据页新、日志无记录，恢复时丢更新/不一致）
• page LSN（页上记录"最后一次修改该页的日志 LSN"）：恢复重放时，若日志记录的 LSN ≤ 页的 page LSN，说明该修改已在该页上（已持久），跳过（避免重复应用）
• 配合检查点（checkpoint）截断日志：page LSN 也是"脏页判定"（flush list 按 LSN 排序）基础

WAL 的核心纪律："日志先于数据"（write-ahead）——对任一修改，其 redo 日志记录必须先持久化到日志（WAL 文件），数据页才允许落盘。原因：崩溃恢复只能"重放日志"（redo）重建丢失的更新；若数据页先落盘而日志记录未持久（崩溃发生在窗口），恢复时该修改"无日志可重放"——但数据页上已是新值：如果恢复逻辑按"日志截断点之前的都重放"，已落盘页被再次应用相同修改（若日志里根本没有，则该更新静默丢失/不一致）——违反"日志先于数据"会导致"页面已更新但日志缺失"，恢复无法确定一致性。因此 WAL 顺序强制：事务提交=日志持久（组提交优化仍保证"日志先于数据"的相对顺序），数据页写回是"后台异步+受 LSN 排序约束"的。

page LSN（页面上的日志序号，如 InnoDB 的 FIL_PAGE_LSN、PostgreSQL 没有 page LSN 但有 LSN 检查（PG 用"页版本号+检查点"）——以 InnoDB 为例）：每个数据页头部记录"最后一次修改该页的 redo 记录的 LSN"。恢复时的价值：重放日志时，若某条 redo 记录的 LSN ≤ 该页的 page LSN，说明"这个修改已经体现在该页上"（页已持久过该修改或更新），跳过不重放（避免重复应用/幂等问题）；若 redo LSN > page LSN，则该修改尚未应用到页，执行重放。由此：一、避免"重放已持久化修改"——恢复只对"日志比页新"的部分操作（不重复、不乱序）；二、支持"模糊检查点/提前截断"——脏页写回后其 page LSN 更新，检查点可以安全地推进日志截断（页已包含该 LSN 前所有修改）；三、并发写回排序——flush list 按 page LSN 排序，写回保证"旧 LSN 页先落盘"（脏页顺序与日志顺序一致，崩溃时页上 LSN 单调）。PostgreSQL 的对应：页上有 pd_lsn（页面版本），恢复时"如果记录 LSN 已反映在页上则跳过"（其恢复用"重放日志直到每页的 LSN 匹配"）；这与 InnoDB 的 page LSN 是同一思想。工程影响：page LSN 使"数据页延迟写回 + 日志先落盘"两件事解耦安全；数据库的 fsync 策略（日志每次提交 fsync、数据页批量写回）依赖此机制；监控"恢复时重放量"（redo log 大小/checkpoint 间隔）可评估恢复时间。

以"日志先于数据"的动机（崩溃可重放、不丢更新）讲清 WAL 顺序纪律，再以"redo LSN vs page LSN 比较"解释跳过已应用修改的幂等恢复。

• 事务锁（lock）：保护数据（行级锁的并发控制语义）
• 页分裂（page split）：B+树结构调整——需要"页级 latch + 父页 latch + 分配新页"的原子性；锁顺序（加锁层次）避免死锁
• 防死锁：latch 采用"无死锁协议"（如 lock coupling/crabbing：先父后子按序加锁、冲突时释放重来；或不等待的 try-latch + 重试）；树结构调整的"结构修改操作（SMO）"用专用机制（如 InnoDB 的 page 级 x-latch 提升）

B+树并发中的两类同步：一、latch（闩锁，短期、内存内）——保护"页结构"的并发访问：读/写同一页的物理一致性（页内存不被并发修改撕裂），粒度=页（buffer pool 中的页 frame），类型有 S-latch（读共享）/X-latch（写独占）；latch 的生命周期=操作执行期间（微秒级），不由事务控制（无回滚语义）。二、事务锁（lock，长期、逻辑语义）——保护"数据行"的并发控制（MVCC 下的读写冲突、两阶段锁），粒度=行/表/间隙，由事务管理（提交/回滚释放），与页结构无关。两者分层：访问数据先取页 latch（拿页的一致视图），行级冲突由锁判定。

页分裂（split）与结构修改（SMO）：插入导致页满时，B+树分裂：分配新页、把一半记录移到新页、更新父页指针（必要时父页也分裂，递归到根）——这需要"原子地"修改多个页，即持有相关页的 X-latch（子页、父页、祖父页……）直到结构更新完成。死锁风险：两个并发插入可能分别持有 A 的子页与 B 的子页、都要父页的 latch（锁顺序颠倒）——形成循环等待。避免方法：一、lock coupling（锁耦合/爬行协议，B-link 树/经典 B+树）：按"根→叶"固定方向逐层获取/释放——先锁父、再锁子，子锁住后释放父（除非父需要修改）；方向唯一（无反向加锁）则无环；二、无等待+重试：SMO 相关 latch 用 try-latch（拿不到就释放已持有的并重试——"不等待"消除等待环）；三、InnoDB 的实践——插入路径先持有"叶页 SX/ X latch"，发现需要分裂时"提升"为修改模式并重新评估（其 SMO 有"上层页锁"的层次化获取：从根到叶锁定向），配合"无等待的索引页锁升级"；四、btrfs（B-tree 文件系统）与数据库实现的"加锁顺序总是一致的（父→子）"这一不变式防环；五、死锁检测兜底（数据库的锁管理器检测 latch 循环？latch 通常不参与锁检测——靠协议防）。此外"分裂与合并"的并发还依赖"页间指针的一致性"（右兄弟指针、父指针更新顺序），崩溃时由 redo 日志保证（SMO 是原子日志记录）。工程要点：区分 latch 与锁是数据库面试高频考点（"latch 保护结构、lock 保护数据"）；排查"索引页竞争"看 latch 等待统计（InnoDB 的 buf_pool 与 page latch 等待）、"行锁竞争"看 lock 等待（information_schema 的 innodb_trx 与 lock 表）。

以"latch=页结构短期锁 vs lock=数据长期锁"的分层开题，再用"分裂需父-子页原子修改"引出死锁面与"lock coupling/try-latch"两类防死锁协议。

• 缺一不可：redo 保证"已提交事务的修改不丢失"（前滚）；undo 保证"未提交事务的修改被撤销"（后滚）；analysis 确定"从哪开始重放（redo 起点=最老脏页 LSN）与哪些事务需 undo"
• 模糊检查点（fuzzy checkpoint）：检查点不停止事务（不要求干净快照），记录"检查点 LSN + 当时脏页表（Dirty Page Table，DPT）与活动事务表（ATT）"——恢复时从检查点记录的 redo 起点（DPT 最小 LSN）开始重放，而非从头（或从上一个干净检查点）
• 崩溃恢复的正确性："redo 从最老脏页 LSN 重放所有修改（幂等，即使已落盘）→ undo 回滚未提交事务"

ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）的恢复三阶段各有不可替代的作用：一、analysis——正向扫描日志（从检查点/最老日志开始）：重建崩溃时刻的"脏页表（DPT：哪些页在缓冲池被改过、各自的 recovery LSN）"与"活动事务表（ATT：哪些事务未提交）"，由此确定 redo 的起点（DPT 中最小的 recovery LSN）与 undo 的事务集合；没有 analysis，不知道"从哪重放"（从头重放代价大）与"哪些要回滚"。二、redo——从 analysis 确定的起点开始正向重放所有日志记录（无论事务提交与否）：把"已写日志但可能未落盘"的修改重新应用到页（若页已落盘且 LSN 已含该记录则跳过（page LSN 判定））——保证"已提交事务的修改必然在盘上"（前滚）；没有 redo，已提交事务可能丢更新。三、undo——反向扫描日志，回滚"analysis 识别出的未提交事务"的修改（逆操作，或记录补偿日志 CLR 保证幂等）——恢复后"未提交事务的修改被撤销"（后滚）；没有 undo，崩溃时未完成事务的部分修改残留在盘上（违反原子性）。缺一不可：redo 管"不丢已提交"、undo 管"撤销未提交"、analysis 管"确定边界（起点与集合）"，三者构成完整的"崩溃一致性"。

模糊检查点（fuzzy checkpoint）：传统"干净检查点"要求所有脏页写回后才能记录检查点（停止事务/阻塞写入）；模糊检查点允许"检查点记录时刻事务仍在进行、部分脏页仍未落盘"：检查点日志记录包含——检查点 LSN、当时的 DPT 快照（各脏页及其 recovery LSN）、ATT 快照（活动事务）。恢复时支持：一、analysis 从"最后一个模糊检查点"开始扫描（而非从头）——DPT/ATT 给出恢复起点；二、redo 起点=DPT 中最小 recovery LSN（该 LSN 之前的修改要么已落盘（页 LSN 已含）要么不需要重放）——避免从头重放全部日志；三、检查点后的新日志继续扫描（脏页集合增量更新）。模糊检查点的价值：检查点不阻塞业务（无 STW 式停顿）、检查点频率可高（恢复时间短——redo 起点更接近崩溃点）而代价仅是一次日志写（DPT/ATT 记录）；数据库的"恢复时间目标"（RTO）由检查点间隔与日志量决定。工程：InnoDB 的 fuzzy checkpoint（doublewrite 配合）、PostgreSQL 的 checkpoint（其"脏页写回+pg_control 更新"也是模糊语义：checkpoint 后仍有脏页）；调优"检查点间隔"平衡正常性能与恢复时间；崩溃恢复观测：日志"redo 阶段重放多少记录"（redo LSN 进度）与 undo 事务数。

以"analysis 定边界、redo 前滚、undo 后滚"讲清三阶段不可替代性，再以"检查点记录 DPT/ATT、redo 起点=最小 recovery LSN"说明模糊检查点如何缩短恢复。

• 逻辑 undo：按"语义操作"回滚（如"删除插入的记录"）——不依赖物理位置，能处理"页已分裂/重组/迁移"后的回滚
• 索引结构修改（SMO：页分裂/合并）后物理位置变化：原页的槽位可能已不在原处（分裂搬移）——物理 undo 无法定位，需逻辑 undo（按键值定位删除/恢复）
• 权衡：逻辑 undo 需要"索引查找"（可能再分裂）、幂等设计（补偿日志 CLR）

ARIES 的 undo 粒度分两类：一、物理 undo（physiological/physical）——回滚"页上的具体修改"：日志记录描述"页 P 的偏移 X 处从旧值改到新值"，undo 时把该位置还原为旧值（如恢复被修改的槽位、位图位、页头字段）；前提是"该页仍保持日志记录时的物理布局"——若页结构未被重组，物理 undo 简单精确、可重复（幂等：重复 undo 同一位置无副作用）。二、逻辑 undo——回滚"记录级语义操作"而非物理位置：如插入操作的回滚是"删除该键值对应的记录"（按索引键查找后删除，而非按"插入时的页偏移"删除）。两者选择：简单数据修改（行内字段更新）用物理 undo（快、精确）；结构敏感的操作用逻辑 undo。

索引结构修改（SMO：页分裂、页合并、记录迁移）为何常需逻辑 undo：分裂会把记录从原页搬到新页（原页槽位结构变化、记录物理位置迁移）；若回滚"插入记录"按"原页+原偏移"物理还原，该位置可能已被后续操作占用（分裂搬移后空出的槽被复用、页已重组）——物理 undo 定位失效（还原错位数据或找不到原位置）；逻辑 undo 按"记录键值"定位（在分裂后的树中按键查找该记录并删除/恢复），不受页布局变化影响——因此"插入/删除记录+可能引发分裂"的操作用逻辑 undo（日志记录含键值而非仅偏移）。代价与配套：逻辑 undo 执行时需访问索引（查找路径可能再分裂——undo 本身触发 SMO，需避免级联复杂化：补偿日志（CLR：补偿"undo 动作"本身的日志，保证"undo 的 undo"可恢复且不回滚已提交修改）与"逻辑 undo 只回滚本事务自己的修改"（通过记录中保存的"本事务插入的键"或回滚指针）。工程：InnoDB 的 undo log 对"索引记录删除"（delete-mark→purge）与"插入回滚"（按主键定位删除）即逻辑 undo 实践；PostgreSQL 的 heap 级物理 undo+索引的"标记删除"（VACUUM 清理）语义类似；理解"物理 vs 逻辑 undo"是恢复机制设计（ARIES 论文核心）与数据库调优（undo 量与回滚时间）的基础）。

以"按页偏移还原 vs 按键值语义还原"对比两种 undo 粒度，再以"分裂迁移记录使物理位置失效"论证 SMO 需逻辑 undo，并补 CLR 幂等设计。

• 事务 ID（txid）：每事务唯一、递增（分配顺序），记录在行版本（记录头）中
• 可见性快照：事务开始时/语句开始时生成"活跃事务集合"（如 InnoDB 的 read view：低水位+高水位+活跃列表）——判断版本可见性：创建事务已提交且不在活跃集、删除事务未提交/不可见
• 判定：按版本链从新到旧遍历，首个"对当前快照可见"的版本即结果

MVCC（多版本并发控制）让读不阻塞写：每行数据保留多个历史版本，读事务看到"快照时刻的版本"。三个要素：一、事务 ID（txid）——系统为每事务分配递增 ID（如 InnoDB 的 trx_id），行版本记录"创建它的事务 ID"（与"删除它的事务 ID"）；递增性使"版本新旧"可按 ID 比较。二、版本链——行修改不覆盖旧值：新版本写入聚簇索引行（记录头含创建事务 ID），旧版本经回滚指针（DB_ROLL_PTR）指向 undo log 中的前一版本（undo 记录含旧值与该版本的事务 ID）；删除也是"版本操作"（打删除标记的版本），未被 purge 前旧版本链存在。三、可见性快照（read view）——读操作建立一致性快照：记录当前"活跃事务集合"（低水位 min_trx_id（活跃事务最小 ID）、高水位 max_trx_id（下个将分配的 ID）、活跃事务列表）；对某版本的可见性判定规则（InnoDB）：a) 版本创建事务 ID < 低水位 → 已提交且早于快照 → 可见；b) 创建事务 ID ≥ 高水位 → 快照后开始的事务 → 不可见（版本太新）；c) 创建事务 ID 在 [低水位,高水位) 之间 → 查活跃列表：不在活跃列表（已提交）→ 可见；在活跃列表（未提交）→ 不可见（转看更旧版本）；d) 删除事务同理（删除事务 ID 对快照可见则行已删除，隐藏该版本）。读取过程：沿版本链从新到旧遍历，用快照判定每个版本，返回首个"可见"版本（若无则行不存在）。一致性级别：REPEATABLE READ 用"事务开始快照"（整个事务一个 read view），READ COMMITTED 用"语句开始快照"（每语句新视图）——"一致性读"即"按快照读版本链"。

工程要点：一、版本链长度=并发写历史（长时间未 purge 时链长，读遍历开销大——监控 undo 增长与 purge lag）；二、快照与锁的配合（当前读（SELECT FOR UPDATE/UPDATE）走最新版本+行锁，快照读走版本链）；三、事务 ID 的回绕（40 位 trx_id 的旧版本回绕问题已解决）；四、HotSpot 的"读视图创建"成本（每事务一次）与"长事务保持旧版本存活"（undo 无法 purge——影响回滚段空间）；五、PostgreSQL 的对应实现（xmin/xmax + hint bits + snapshot 的 xip 数组）与 InnoDB 异同（PG 版本在堆中、InnoDB 旧版本在 undo）。调优与排查：长事务导致 undo 膨胀（回滚段/undo tablespace 增长）、一致性读的"读旧版本"行为（时间点查询/备份）、information_schema 的 trx 视图与 undo 监控。

以"txid 标识版本、版本链承载历史、快照判定可见"三要素讲清 MVCC 读取判定，给出 InnoDB 的可见性规则与 REPEATABLE READ/READ COMMITTED 的快照差异。

• PG 的 HOT（Heap-Only Tuple）：更新时若被更新的列不含索引列且页内有空间——新版本留在同页并直接链接到旧版本（无索引指针更新），索引仍指向旧版本（经 HOT 链跳转）
• InnoDB 的"secondary index 延迟写回"：二级索引记录不随行立即更新（insert buffer/change buffer 合并），更新时二级索引"标记延迟"（可能产生"半新半旧"的索引条目，由后台合并）
• vacuum：PG 依赖 vacuum 清理 HOT 链上的死元组与索引死条目；InnoDB 用 purge（回滚段清理）——两者的清理时机与代价不同

PostgreSQL 的 HOT（Heap-Only Tuple）更新：更新满足两个条件——被更新的列不涉及任何索引列、目标页内有空闲空间——则新版本元组直接放在旧版本"同一页"并形成 HOT 链（新元组指向旧元组，旧元组的 t_ctid 指向新元组）：索引（包括二级索引）仍指向"旧元组"（索引项不更新），读取时沿 HOT 链跳到最新版本。收益：索引更新完全省略（避免索引写与随机 I/O）、索引不膨胀（该更新不产生新索引条目）、vacuum 压力小（死元组同页可快速清理）；代价：HOT 链使索引指向"可能较旧"的元组（需链跳转）、页满后无法 HOT（退化为普通更新）、频繁更新同页可能页内碎片。非 HOT 更新（列涉及索引或页满）：产生新元组（可能在别的页）+ 更新所有相关索引条目——旧索引条目保留（死版本）直至 vacuum 清理，索引膨胀。

InnoDB 的二级索引延迟写回（change buffer，原 insert buffer）：更新/插入二级索引记录时，若目标索引页不在缓冲池，把变更记录"缓存"（change buffer，磁盘结构），后台或读取该页时批量合并（merge）——本质是"延迟索引写"：减少随机索引页 I/O（避免每次更新都读索引页），提高更新吞吐；代价：一、索引页合并时的批量写（合并风暴）、崩溃恢复需重放 change buffer（日志关联）、二、二级索引的"索引条目与实际行版本"之间存在延迟窗口（purge 与 merge 的时序）；对膨胀的影响：InnoDB 的索引"删除标记"由 purge 清理，change buffer 合并不产生重复条目（按主键定位更新/插入），膨胀主要来自"删除+插入"的页分裂与碎片（页重组），与 PG 的"死索引条目"机制不同。膨胀与清理对比：PG——索引死条目由 vacuum（或 autovacuum）清理（vacuum 扫描堆与索引删除死版本），HOT 减少死条目产生；膨胀明显时用 REINDEX/重建；InnoDB——purge 清理删除标记版本，索引页碎片靠页合并（optimize table 重建）——膨胀控制依赖"更新是否走 change buffer"与随机插入模式。

工程对比：一、频繁更新"非索引列"（如状态字段）PG 的 HOT 让索引零更新（极高效），InnoDB 靠 change buffer 减少索引 I/O（但更新需写 undo+版本链）；二、索引膨胀治理：PG 的 autovacuum（含 HOT 清理与 vacuum 阈值）、InnoDB 的 purge 线程与页合并；三、监控：PG 的 pg_stat_user_tables（n_dead_tup、n_tup_hot_upd）、InnoDB 的 change buffer 大小（information_schema.innodb_metrics 或 SHOW ENGINE INNODB STATUS 的 IBUF）、索引膨胀评估（pgstattuple / innodb 的 stats）；四、选型影响：高更新负载（状态机类）配 PG 的 HOT 条件设计（索引列少、行小）、InnoDB 配"二级索引精简 + change buffer 容量调优"。结论：两者都是"减少更新路径索引开销"的优化，PG 用"同页链+不更新索引"（空间换跳转），InnoDB 用"延迟合并"（时间换批量），膨胀与清理机制相应不同。

以"HOT 同页链接免索引更新 vs change buffer 延迟合并"对比两库更新路径，再分别说明死条目/vacuum 与碎片/purge 的膨胀治理差异。

• 意向锁（IS/IX）与表锁的兼容矩阵：升级（如 S→X）时需重新评估与已有锁的兼容
• 死锁场景：两个事务分别持有"对方的间隙/记录"所需的锁，升级/插入时互相等待；如 T1 锁 record A + gap B，T2 锁 record B + gap A，T1 再插 A 范围记录（需 gap 锁）与 T2 冲突
• 防死锁：InnoDB 的死锁检测（等待图）+ 锁顺序设计（索引顺序加锁）+ 减少 gap 范围（RC 隔离级别无 gap 锁）

锁体系（InnoDB REPEATABLE READ 默认）：一、record lock——锁定具体索引记录（X/S）；二、gap lock——锁定"记录之间/记录前后"的间隙（区间），阻止其他事务在该间隙插入（防幻读），gap 锁之间兼容（都只防插入）；三、next-key lock——"记录+其前向间隙"的复合锁（左开右闭区间），是行锁与 gap 锁的组合（防"读到记录又被插入"）；四、意向锁（IS/IX）——表级"意图"标记（事务要锁行/间隙），与表锁（S/X）的兼容矩阵决定"整表锁"能否授予（IX 与 S 表锁冲突等）。意向锁升级场景：事务先持 IX（准备改行），后需表级 S/X（如 DDL 或 ALTER 触发的表锁升级）：升级需检查"意向锁与新表锁的兼容"（IX 升级 X 需无其他事务持有 S 表锁/IX 冲突），可能与持有表锁的事务互等。行级死锁的经典相互作用：T1 执行 UPDATE 锁定记录 A（next-key：A 及其前间隙）；T2 执行 UPDATE 锁定记录 B（next-key：B 及其前间隙）；T1 再插入"落在 B 前间隙"的新记录（需获取该间隙的插入意向/gap 锁）→ 与 T2 的 next-key（覆盖该间隙）冲突，T1 等 T2；T2 插入"落在 A 前间隙"的记录 → 等 T1——循环等待，死锁检测器发现后回滚牺牲者。升级路径的参与：若 T1 需把行的 S 锁升级为 X（如 SELECT FOR SHARE 后 UPDATE），升级时需等待持有该行 X 锁的事务；配合 gap 的"升级不改间隙所有权"（gap 锁兼容），死锁多出现在"插入需要 gap 锁而对方持有 next-key"的交叉。

防死锁工程手段：一、锁顺序一致——多行更新按主键/索引顺序加锁（避免交叉）；二、隔离级别——RC（READ COMMITTED）下 InnoDB 不用 gap 锁（仅外键/唯一检查需要）→ 幻读死锁面显著缩小（"gap 死锁"只在 RR 常见）；三、缩小事务——短事务减少持锁窗口；四、死锁检测与重试——InnoDB 的 innodb_deadlock_detect（等待图，等待超时 innodb_lock_wait_timeout 兜底）；应用捕获死锁错误重试；五、避免"先查后插"的 TOCTOU（用 INSERT ... ON DUPLICATE 或唯一索引让冲突可见）；六、监控——SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK（显示锁等待链与记录）、performance_schema 的 lock 等待表；七、RR 下对高频插入路径用"间隙锁定最小化"（索引设计：区分度高的索引减少 gap 覆盖范围）。本质：死锁=多资源（记录+间隙）的循环等待，"间隙"是"不存在的资源"，其锁交互（gap 兼容、next-key 组合）扩大了等待图——理解 lock 与 gap 的兼容矩阵是分析死锁报告的前提。

以"record/gap/next-key 的区间语义 + 意向锁升级的兼容检查"讲清锁相互作用，再用双事务交叉插入的等待链演示死锁形成与 RR/RC 的差异。

• 密集检查点：频繁"全量脏页刷写"——同一脏页在多个检查点周期被重复写回（写放大）与 I/O 带宽占用、与业务写争抢
• 稀疏检查点：redo 日志积累长，崩溃恢复需重放大量日志（redo 阶段长）、undo 范围大（回滚长事务）——恢复时间（RTO）拉长
• 平衡：检查点频率由"恢复时间目标 × 写放大预算"决定（如 InnoDB 的 adaptive flushing、PG 的 checkpoint 参数）

检查点的作用：把缓冲池中的脏页写回磁盘、推进日志截断（redo 不再需要从头重放）——崩溃恢复时只需从"检查点后的最老脏页 LSN"重放（模糊检查点）。写放大面（密集检查点的代价）：一、每次检查点把"所有脏页"写回——两次检查点之间"被多次修改的页"会被写回多次（检查点 n 写回一次、检查点 n+1 又写回——页内容可能没变多少）——与"脏页写回只写一次（writeback）"相比是重复写（放大）；二、检查点刷写与业务写入争抢 I/O 带宽与磁盘队列（检查点期间延迟上升）；三、日志量：检查点本身要写检查点记录（DPT/ATT），频率高则日志元数据增加。因此"过于密集"=频繁全量刷脏页+日志开销，表现为写放大与 I/O 尖峰（尤其大缓冲池：检查点刷写量=脏页总量）。过于稀疏的代价：一、恢复重放范围大——崩溃点距离上次检查点越远，redo 需重放的日志越多（从最老脏页 LSN 到崩溃点），恢复时间（RTO）线性增长；二、undo 范围大——长事务的 undo 段长（回滚时间长）；三、日志文件累积（InnoDB 的 redo 文件不足时被迫"日志切换检查点"——在日志空间压力下强制做检查点，表现为周期性性能毛刺）。

平衡机制：数据库用"自适应/参数化"策略：一、InnoDB 的 adaptive flushing——根据"redo 生成速率与日志空间"动态调整脏页刷写速率（在"日志逼近满"前渐进刷写，避免突发全量检查点；innodb_max_dirty_pages_pct、innodb_io_capacity 控制）；二、PostgreSQL——checkpoint_timeout（默认 5 分钟）+ max_wal_size（触发式检查点）：在"时间"与"日志量"双维度触发，checkpoint_completion_target 把刷写摊开到周期内（避免 I/O 尖峰）；三、调优取向：RTO 敏感（快速恢复）→ 高频检查点（接受写放大）；写放大敏感（SSD 寿命/带宽）→ 低频+自适应（接受较长恢复）；四、观测：redo/WAL 生成速率、检查点间隔（pg_stat_bgwriter 的 checkpoint 计数、InnoDB 的 log 状态）、恢复时间实测。工程结论：检查点频率是"恢复时间（RTO）× 写放大（性能/寿命）"的旋钮，正确姿势是"按 RTO 预算反推 + 摊平 I/O + 自适应兜底"，而非"越频繁越好"。

以"检查点=脏页写回+日志截断"讲清机制，从重复写回与 I/O 争抢论证密集代价、从重放范围论证稀疏代价，并给 InnoDB/PG 的平衡机制。

• 关键：只读副本的 undo 需求来自"复制来的写入产生的版本链"与"副本上的长事务/备份快照"——若副本完全只读且无复制流量，undo 基本不动；但复制流量产生新版本，undo 用于服务"副本上的长查询"
• MVCC 代价转移：把"多版本"从 undo 转移到"复制/共享存储"（如 Aurora 的存储层多版本、PG 的 hot standby 用 xmin/xmax + 快照）
• 代价转移视角：undo 大小=写频率×版本存活时间；优化方向=减少版本（及时 purge）、减少读旧版本需求（快照管理）、把 undo 移到"副本不需要"的地方（如 Aurora 的存储层日志即多版本）

只读副本（如 PostgreSQL hot standby、MySQL 只读实例、Aurora 副本）上的读操作也遵循 MVCC：读快照需要"一致性视图"——若副本上没有本地写入，其"最新版本"就是"复制应用的最新版本"，而版本链由"复制流中的写入"产生（主库写入→副本应用→副本页面上形成新版本/或只记录最新？物理复制应用后旧版本在副本上如何保留？）。关键点：一、物理复制（redo 应用）的副本：页被重放为最新状态，旧版本不保留在页上——副本的"快照读旧版本"能力依赖"副本自身的 undo/快照机制"（PG 的 hot standby：其 MVCC 用 xmin/xmax 与快照（副本身份由复制过来的事务状态决定），undo 不在副本上重建——PG 的 undo 不存在（PG 用"多版本堆+vacuum"，无独立 undo log！）——注意：PostgreSQL 无 undo 日志（用"旧版本留在堆中+vacuum"），MySQL InnoDB 有 undo。二、InnoDB 只读副本：若副本是"物理复制（redo 应用）"，undo 页也随 redo 复制（undo 在共享表空间/独立 undo 表空间，redo 应用会更新 undo 页）——副本上的长查询需要"undo 版本链"时，undo 必须存在（来自复制）——所以"只读副本仍需要 undo"：副本上的长事务/一致性读（如报表、备份、CDC 快照）会访问旧版本，undo 提供这些版本；若主库把 undo 过早 purge（副本消费滞后），副本上的查询会报"快照太旧"错误。三、MVCC 代价的转移：MVCC 的实现代价（空间与清理）与"版本生产速率 × 版本存活时间"成正比——转移手段：a） 把"旧版本存储"从"行所在页"移到"独立 undo 区"（InnoDB 已做：页上只留最新+回滚指针，旧版本在 undo——读旧版本=页+undo 的随机访问，代价从"页膨胀"转移为"undo I/O"）；b) 把"多版本"下沉到存储层（Aurora：存储引擎保留多版本/日志即数据，计算节点无 undo 负担，副本从存储读版本——代价从"计算节点 undo"转移到"存储层多版本"）；c) 用快照隔离（WOS/Snapshot）替代行级版本（部分系统）；d) 优化版本存活：及时 purge（purge 线程）、限制长事务（undo 膨胀与"快照太旧"的根因）。

工程要点：一、副本上的"长查询+复制延迟"组合是 undo/purge 压力源（主库 purge 推进依赖最旧快照——副本的复制位点会推迟主库 purge：InnoDB 的 purge 由"最旧活跃视图"（含复制消费）决定——副本滞后会拖住主库 undo 清理）；二、PG 的等价物是 vacuum 的"最旧快照/复制槽"（复制槽未消费→WAL 不清理→磁盘膨胀）；三、监控：undo 表空间增长、pg 的 replication slot 延迟、MVCC 版本长度（information_schema.innodb_metrics 的 history list length）；四、设计取舍：需求"副本长查询稳定"的架构应保证"副本的读快照不落后"（避免超长事务与延迟）。结论：undo（或等价的多版本机制）是"读旧版本"的必需品，只读副本同样消费它；代价转移的方向是"把版本存储/清理从计算节点推向存储层或后台"。

以"副本读快照也需旧版本"论证只读副本仍需 undo（复制应用+副本长查询），再从"页→undo 区→存储层"讲 MVCC 代价转移路径与 purge/复制槽的联动。

• LSM 写入快（memtable）、后台 compaction 消化——若 compaction 跟不上写入，memtable 满→write stall（阻塞写入）
• 调度：compaction 线程数、触发阈值（L0 文件数/字节）、pending bytes、弹性并发（dynamic level）
• universal（tiered）compaction：同层文件合并成更大文件（tier 化），写放大小、吞吐平滑（增量合并），但空间放大与读放大权衡不同

RocksDB（LSM-tree）的写入路径：写先入 memtable（WAL 持久），memtable 满后转为不可变 memtable（flush 成 L0 SST）；后台 compaction 把 SST 合并下沉（减少重叠、控制读放大）——compaction 是"后台消化能力"：若写入速率持续高于"compaction+flush"速率，不可变 memtable 堆积、L0 文件数超阈值，写路径触发 write stall（RocksDB 的 stall 机制：暂停/限速写入直到后台追平）——因此 compaction 调度直接决定"写吞吐天花板与抖动"：调度策略（compaction 线程数、触发阈值（level0_file_num_compaction_trigger、max_write_buffer_number）、pending_compaction_bytes、软/硬限速（write_rate_limiter）、dynamic level 与弹性触发（level_compaction_dynamic_level_bytes））决定"后台何时、以多大力气消化"，配置不当（阈值过小/线程不足）导致高频 stall（吞吐锯齿）或 L0 失控（读放大暴涨）。写放大与后台吞吐曲线的形状：一、level compaction——每次合并把 L 层文件下沉到 L+1 层（重叠范围合并）：后台吞吐呈"周期脉冲"（一个 level 的合并集中爆发（compaction burst），期间 IOPS/带宽高、合并完成回落到低）——曲线"锯齿/脉冲"；代价：写放大（每次下沉重写数据，约 10~30 倍取决于配置）与合并风暴对前台写的干扰（与业务争 I/O，可配 rate limiter 限速）；收益：空间放大小（每层数据总量受 size 比例约束）、读放大受控（层内有序）。二、universal（tiered）compaction——把"同层（同大小档）的多个文件"合并成一个更大的文件（tier 化：文件按大小分层）：每次合并涉及的文件少、合并是"追加式"（新文件并入大文件），后台吞吐更平滑（持续低量合并而非脉冲）；写放大显著更小（尤其"最后层合并"策略）；代价：空间放大更大（旧文件与新区间并存，tier 间重叠多）、读放大更高（需查多个 tier 文件）、删除/去重的空间回收延迟（标记-压缩）。

工程取舍：一、写放大敏感（SSD 寿命、高写入负载）→ universal（或 level 的优化参数：增大每层倍数、dynamic level）；二、读放大/空间敏感 → level（默认）；三、stall 治理：监控 stall 计数（rocksdb.stall 统计）与后台吞吐（rocksdb.compaction 统计、compaction IO）、按"写速率×数据规模"估算所需后台带宽、用 write rate limiter 平滑（避免脉冲与前台争抢）、多实例场景按盘分隔离；四、"后台吞吐曲线"的实际观测：rocksdb 的 compaction 耗时与并发、L0 文件数随时间曲线——曲线陡升（compaction 滞后）预示 stall。结论：compaction 是 LSM 的"呼吸"——调度的本质是"用后台 I/O 换前台稳定"，level 与 universal 的曲线差异（脉冲 vs 平滑）决定了它们在"写放大-空间-后台带宽"三角上的落点。

以"写入-后台消化失衡→write stall"讲清调度重要性，再对比 level（脉冲式合并、写放大高、空间小）与 universal（平滑增量、写放大低、空间大）的吞吐曲线。

• 逻辑解码：从 WAL 中的物理变更（heap 页修改）解析出"逻辑变更"（INSERT/UPDATE/DELETE 的行级操作）——由 output plugin（如 pgoutput、test_decoding）输出格式（pgoutput 供 PG 逻辑复制）
• 一致性起点：创建 slot 时建立"快照"（exported snapshot）——CDC 消费者从"快照+其后变更流"拼接出完整数据视图（初始装载=快照，增量=变更）
• 保证：slot 的 LSN 与快照的 xmin 对齐（快照对应"解码起始点之前"的一致性状态）；主库不会回收 slot 需要的 WAL

逻辑解码（logical decoding）是 PostgreSQL 的 CDC（变更数据捕获）基础：WAL 记录的是"物理变更"（页级修改、redo 语义），逻辑解码器（pg_logical_slot_get_changes 或复制协议）将其解析为"逻辑变更"（关系/行级的 INSERT/UPDATE/DELETE，含旧值/新值可选（REPLICA IDENTITY）），再经 output plugin 格式化为目标格式：pgoutput（逻辑复制订阅用）、test_decoding（调试）、wal2json 等第三方插件。复制槽（replication slot）的角色：一、记录解码进度（confirmed_flush_lsn：消费者确认消费到的 LSN）与解码状态（起始点）；二、防止 WAL 回收——slot 未消费的 WAL 不会被清理（即使 checkpoint 推进）——保证"解码不会因日志被删而断流"；三、hot standby 上也可创建（逻辑复制从只读副本消费）。CDC 的一致性起点：创建 slot 时（pg_create_logical_replication_slot 带 EXPORT_SNAPSHOT / 或逻辑复制订阅的 initial sync）导出"快照"（snapshot：一致的数据库视图，对应 slot 创建时刻）：消费流程=先用快照做"初始装载"（全量数据），再应用"从快照点开始的逻辑变更流"（slot 的 start_lsn/confirmed_flush_lsn 对齐快照的一致性点）——快照+LSN 的双重锚定保证：初始装载与增量变更之间无缝隙、无重叠（快照看到的状态与变更流从该状态继续）；若快照与变更流起点不对齐（如快照过旧），会出现"漏变更"或"重复应用"。实现细节：slot 创建时的 xmin 与 WAL 起点（pg_create_logical_replication_slot 返回的 consistent_point）；消费端（订阅端 apply）记录接收到的 LSN，重启后从 confirmed_flush_lsn 继续（at-least-once 语义：重复的变更由订阅端幂等处理或接受）；slot 未消费导致 WAL 膨胀。

工程实践：一、CDC 工具（Debezium）的 PG 连接器即用逻辑复制槽+pgoutput（快照模式 initial/initial_only/never）；二、运维要点——监控 slot 的 lag（pg_replication_slots 的 wal_status、restart_lsn 与 current WAL 差）、防止"slot 遗忘"（丢弃 slot 后 WAL 才可回收）、逻辑复制与物理复制的 slot 区别（逻辑 slot 也防 WAL 清理）；三、一致性保证：需要"快照+变更流"对齐时用 EXPORT_SNAPSHOT 在同一会话完成快照导出与 slot 创建（事务语义）；四、DDL 与类型变更对解码的影响（逻辑复制要求表结构兼容、DDL 不复制（需手动处理））；五、性能：解码的 CPU 与 WAL 读取开销（解码需要读 WAL 与系统目录），大事务解码的内存峰值（流式解码选项）。结论：slot（LSN 锚点+WAL 保留）+ 快照（一致性视图）是 CDC 起点正确的双保险。

以"WAL→解码器→output plugin 格式"讲清逻辑解码链，再以"slot 锚定 LSN 保 WAL、快照锚定一致性点、初始装载+增量拼接"说明 CDC 起点保证。

• 向量化（vectorized/block-at-a-time）：按批（如 1024 行）处理，批量循环内无虚调用、数据按列存储（列式）连续→SIMD（AVX2 等）与 cache 友好
• 量化：每行指令数（IPC）、分支预测失败率、cache miss 率（每行内存访问/每批缓存行数）、吞吐（行/秒）
• 数据格式：行存 vs 列存（列式存储使单列连续=向量化基础）

Volcano（迭代模型，如 PostgreSQL 的执行器）：每个算子（scan/filter/join/agg）实现 next() 迭代器，父算子对"单行"调用子算子——每行经历一次虚函数调用链与上下文切换、每行独立分支（谓词判断、类型分发）、数据按行存储（tuple 内字段分散）→ 一行处理含多次缓存行访问（行中字段散布）与大量解释开销：量化指标——每行几百~上千条指令（TSC 测量）、IPC 低（0.5~1.5）、分支预测失败率高（多分支多态）、cache 命中差（随机访问行内字段）；吞吐受"每行固定解释成本"限制（单核每秒数百万~千万行级）。向量化执行（如 ClickHouse、DuckDB、Vectorized 的 SQLite 变体、Greenplum 的 ORCA 部分）：算子处理"一批"（block/vector，如 1024 行的列数组）：一、SIMD——列数据连续存放，谓词/算术可用 SIMD（AVX2 一次 8 个 int32/16 个 int8）：单条 SIMD 指令处理 8~16 行（吞吐放大 8~16×）；二、cache——批处理时单列连续读（每批 1024×4B=4KB 顺序访问，cache 行利用充分，无行内散布）；三、解释开销——批量循环内无虚调用（循环体为同一运算的连续执行）、分支少（批量谓词可做分支预测优化（如"无匹配"快速路径））；量化：每行指令数降到几十条、IPC 提升（2~4）、cache miss 率显著下降（每行缓存行访问从"多行散布"变为"列式顺序"）、吞吐提升一到两个数量级（单核亿行/s 级）。

量化方法：一、perf stat——指令数（每行）、cache-misses、branch-misses、IPC：对比同一查询在 Volcano 与向量化实现（或 PG 与 DuckDB/ClickHouse）上的计数；二、微基准——固定数据量的"全表扫描+谓词过滤"吞吐（行/s）与"每行指令"（perf 的 instructions/rows）；三、SIMD 利用——编译后反汇编/性能计数器看向量指令占比（AVX 指令数）、加速比随数据宽度（int8/16/32）变化；四、cache 行为——perf stat 的 L1/L2 miss、内存带宽利用率（MEM_LOAD_RETIRED 类事件）；五、扩展性——核数 vs 吞吐（向量化+多核近线性）。工程启示：列式+批量+SIMD 是"分析型查询"（大范围扫描/聚合）的吞吐关键；行式+迭代适合"点查/OLTP"（单行延迟）；向量化引擎的代价：内存占用（批量缓冲）、算子实现复杂度、小结果集时批处理收益有限（批量阈值选择）。结论：量化的核心变量是"每行指令数、IPC、cache miss、SIMD 向量宽度"——Volcano 与向量化的差距在分析负载下可达 10~100 倍。

以"每行虚调用与行存散布 vs 批量循环与列存连续"对比两种模型的执行特征，再给出 perf 级量化指标（指令/IPC/cache miss/吞吐）与典型量级。

• 统计与估算漂移：基数估计错误（列相关、倾斜值）、成本常量与现实（SSD 的 random_page_cost 应调低）——PG 提供参数校正
• GEQO（genetic query optimizer）：连接顺序（join order）的遗传算法搜索——不改变代价模型，只在大连接数（geqo_threshold 默认 12 表）时用启发式搜索替代穷举
• 校正方式：参数调优（cost 常量、effective_cache_size）、统计增强（extended statistics、autovacuum analyze）、并行代价（parallel setup/parallel tuple cost）

PG 的代价模型（cost model）：以"代价单位"估算计划——seq_page_cost（顺序页 1.0）、random_page_cost（随机页 4.0，SSD 应调低至 1.0~1.5）、cpu_tuple_cost（0.01）、cpu_operator_cost（0.0025）、cpu_index_tuple_cost、以及并行（parallel_setup_cost/parallel_tuple_cost）与 effective_cache_size（影响 seq vs index 的判断）。"权重漂移"：一、数据倾斜——统计信息基于采样（default_statistics_target），倾斜列（少数值占多数）导致基数估计失真（如"1% 的值占 99% 行"），join 行数估算偏差放大计划错误（nestloop vs hashjoin 选错）；二、硬件漂移——机械盘 vs SSD vs 云盘（local SSD 的随机读与顺序读接近，random_page_cost 应下调）、缓存命中（effective_cache_size 应反映系统缓存——估低了高估顺序扫描）；三、并行与缓存效应——并行查询的启动/元组代价、buffer 命中后的代价（代价模型对 buffer 命中计入折扣）。校正手段：一、参数——random_page_cost 按存储介质调、effective_cache_size 按可用内存调、cpu_* 按机器调（较少动）；二、统计——提高 default_statistics_target 或列级 statistics（ALTER TABLE ALTER COLUMN SET STATISTICS）、扩展统计（CREATE STATISTICS 的 dependencies/ndistinct/mcv 修正列相关与多列基数）、autovacuum 的 analyze 频率（保证统计新鲜）；三、倾斜治理——MCV 列表（most common values）与直方图边界处理倾斜、参数化计划与 custom plan 的切换（PREPARE 的 generic vs custom）。

GEQO（genetic query optimizer）的定位与校正：GEQO 不改变代价模型，而是改变"搜索策略"——当 FROM 子句表数 ≥ geqo_threshold（默认 12）时，穷举连接顺序的组合爆炸（N! 级）不可行，GEQO 用遗传算法（种群、交叉、变异，随机搜索）在有限时间内给出"近似最优"的连接顺序——"校正"的是"搜索空间过大时的可用性"（在穷举超时前给出计划），而非代价精度；其代价评估仍用同一 cost model。GEQO 的代价：结果可能是局部最优（非全局最优）——大连接查询可显式调 geqo_effort/geqo_generations 或对关键查询手工改写（拆 join、加 hint（pg_hint_plan））；对"代价漂移"的真正校正组合是"参数+统计+并行参数"——GEQO 只是搜索层的兜底。工程实践：一、先校正统计（analyze 频率、统计目标、扩展统计）——统计准是计划准的前提；二、再按存储调 cost 常量（SSD 场景 random_page_cost=1.1、effective_cache_size=内存 70%）；三、大连接/复杂查询检查 plan（EXPLAIN ANALYZE 对比估算 vs 实际），必要时 hint 或拆分；四、监控"估算偏差"（pg_stat_statements 的 rows 差、auto_explain 的 plan 分析）。结论：代价权重漂移的校正 = 参数（介质/缓存）+ 统计（倾斜/相关）+ 并行代价，GEQO 解决的是"表数多时的搜索可行性"，两者互补。

先讲 cost 常量与统计漂移的根源（倾斜/介质/缓存），再给参数、统计、扩展统计的校正手段，最后澄清 GEQO 是搜索策略而非代价模型修正。

• 乐观版本（version/CAS 重试）：冲突时重试——适合冲突率低或读多写少（吞吐优先）
• 业务分片（分桶/打散）：把热点行拆成多行（计数器分片、队列分桶）——本质"消除热点"
• 选择矩阵：冲突率、一致性要求、更新语义（计数/状态机/金额）、延迟与重试成本

热点行（如订单计数、库存、点赞数、余额）高频更新的冲突治理三方案：一、悲观锁——UPDATE 前 SELECT ... FOR UPDATE（或直接 UPDATE 的隐式行锁）：并发事务排队串行执行：冲突率高时"排队等待"是确定性的（无重试成本、无活锁），适合"更新必须严格串行"（金额变动、状态机流转）且冲突率高的场景；代价：等待延迟（队列长度×临界区时间）、死锁风险（锁顺序）、吞吐受"临界区串行"上限。二、乐观版本——读取时带版本号（或 CAS 语义），更新时校验版本（UPDATE ... WHERE version=? 影响行数为 0 则冲突）：冲突时事务重试（重新读+改+提交）：冲突率低时零等待开销（吞吐高、无锁排队），适合"读多写少、冲突偶发"（如点赞、配置更新、标签）；代价：冲突率高时重试放大（重试风暴、活锁）、长事务重试成本高、需要应用层处理重试（含副作用控制）。三、业务分片——把逻辑上的热点拆成多个物理键：计数器分片（count%N 分桶，读时聚合）、库存分片（多个库存桶）、队列分桶（多个子队列）：把"单行争用"变为"多行并行"（每个分片独立更新，冲突率除以 N）：适合"计数/聚合类、语义可拆分"（点赞数、访问量、库存水位）；代价：读时需要聚合（一致性弱化：近似值或聚合读）、分片数与业务语义绑定（跨分片事务复杂化）、容量规划。

选择矩阵：一、更新语义——"强一致串行"（金额、状态）用悲观锁（或"单写者"架构）；"可拆分聚合"（计数）用分片；"偶发冲突"（配置/轻量状态）用乐观。二、冲突率——高且不可分：悲观锁（吞吐-延迟权衡）或"队列化写（单消费者）"；低：乐观。三、延迟与重试预算——重试成本高（长事务、外部副作用）慎用乐观（用"条件更新一次"或悲观）；四、混合——热点行"先分片消热点、再在桶内用乐观/悲观"；库存场景的"超卖保护"常是"乐观版本+库存足够校验"或"悲观锁+短临界区"。工程实践：一、量化冲突率（压测/监控死锁与更新重试数）；二、悲观锁注意死锁检测与锁等待超时（innodb_lock_wait_timeout）；三、乐观重试加"退避+上限"；四、分片的聚合缓存（Redis 聚合计数）与一致性说明（"近似计数"是否可接受）；五、Rust/Go 服务端的高频计数器常用"内存原子分片+定期落库"。结论：没有银弹——"语义可拆分优先分片、串行语义用悲观、低冲突用乐观、组合使用"是工程常态。

以"串行等待/重试/消除热点"三种机制对比三方案，按更新语义、冲突率、重试预算给出选择矩阵与混合策略。

• plan cache：PREPARE/扩展协议（prepare 语句）缓存执行计划——避免重复 parse/plan
• 失效策略：DDL 变化（表结构、索引删除）、统计变化（analyze 导致计划重算？PG 对 custom plan 会重估）、参数变化（generic vs custom plan 选择）
• PG 的应对：缓存计划按"解析对象"绑定，并记录解析时依赖的 search_path/对象 OID（若对象被替换（DROP+CREATE 同名）→ invalidation）；search_path 的坑：PREPARE 的计划已绑定 OID，执行时不再重新解析——若 search_path 变化但 OID 未变，计划仍指向原对象（行为按"解析时对象"）；避免策略：执行时验证或重新 PREPARE、应用层管理 search_path 一致性

prepared statement（PREPARE 与扩展协议）的计划缓存：执行流程"解析（parse）→ 计划（plan）→ 执行"，缓存把 plan 保存复用（省 parse/plan 开销）。失效策略（invalidation）：一、DDL 失效——对象被修改/删除（表、索引、函数、类型变更）时，依赖该对象的缓存计划被标记失效（下次执行重新计划）：PG 通过"计划记录的依赖对象 OID"与系统目录的 invalidation 消息（syscache 回调）实现——ALTER TABLE/新增索引/DROP 均触发；二、统计更新（ANALYZE）——PG 对"参数化计划"的 custom plan 会在"预估代价漂移"时重新计划（generic plan 的启用阈值：custom 计划估算优于 generic 时用 custom 并周期性重估）——统计变化不直接失效，而是通过"generic/custom 计划选择"（plan_cache_mode、自定义参数）影响；三、GUC 变化——影响计划语义的 GUC（enable_seqscan、work_mem 等）在会话级计划重新生成时生效：计划缓存按"生成时 GUC 上下文"绑定，GUC 变化时 PG 会重新计划（如 search_path、enable_* 开关变化会 invalidate）；四、临时表/会话对象——按会话隔离。

search_path 的过期计划问题：PREPARE 时的解析把表名解析为"当时的 OID"（如 public.t vs 其他 schema 的 t）：计划绑定的是"解析时的对象"——若后续 search_path 改变（应用切换 schema、迁移脚本 SET search_path），同名字符串不再解析到同一对象：a) 若对象被 DROP+CREATE（OID 变化）→ 目录失效机制使旧计划失效（安全）；b) 若对象未变（仅 search_path 语义变化）→ 缓存计划仍按"原 OID"执行（行为正确但可能"不符合用户新意图"——用户期望新 search_path 下的对象）。PG 的应对：一、search_path 变化本身触发"计划失效"（PG 把 search_path 列入"计划依赖的 GUC"——9.3+ 的实现：若计划生成后 search_path 改变，执行时重新解析（PG 会 invalidate 并重新 plan，因为计划记录了生成时的 search_path 快照，执行时发现不一致则重新计划）——实际 PG 的行为：search_path 改变会导致"下次执行重新解析"（这是官方文档建议"修改 search_path 后重新 PREPARE"的原因，实现上通过"计划依赖记录"处理）；二、应用层纪律——在一致且明确的 search_path 下 PREPARE（如 schema 限定名）、修改 search_path 的会话重新 prepare、避免跨 schema 复用计划；三、限定名（schema.table）消除歧义。工程实践：连接池复用会话时注意 search_path 漂移（池化会话被不同应用设置）、ORM 的 prepared statement 缓存与迁移（schema 切换后重启/刷新）、监控"计划重算率"（plan_cache 统计）。结论：失效策略=对象 DDL 失效+计划依赖记录（含 search_path/GUC）+generic/custom 重估；防"过期计划"的核心是"对象级失效可靠 + search_path 纪律"）。

以"DDL 依赖失效、GUC/search_path 依赖记录、generic/custom 重估"讲清失效策略，再针对 search_path 变化的两个场景（OID 变/语义变）说明防过期做法。

• 连接池耗尽（获取连接超时/拒绝）但 DB CPU 低——瓶颈不在"计算"而在"连接被占用"
• 工具：DB 侧（information_schema/performance_schema 的连接与事务视图、pg_stat_activity、show processlist）、应用侧（线程栈/池状态）、网络（抓包/RTT）
• 治理：事务边界纪律、锁等待超时、池配置（最大连接、等待超时）、连接租约与泄漏检测

"池耗尽+DB CPU 低"的诊断逻辑：连接数到顶（应用拿不到连接）而数据库空闲（CPU 低）→ 连接被"占用但不干活"——四类成因与检查：一、长事务——未提交事务长时间持有连接（sleep/慢业务/忘记 commit）：PG 查 pg_stat_activity（state='idle in transaction'、xact_start 久远）；MySQL 查 information_schema.innodb_trx（trx_started 久远）与 processlist（Sleep 状态）；此类连接占住池位置且可能持锁——治理：事务边界纪律（短事务、统一提交）、idle_in_transaction_session_timeout（PG）/innodb_lock_wait_timeout 与事务超时。二、锁等待——事务阻塞在锁上（互相等锁）：PG 的 pg_locks 与 pg_stat_activity 的 wait_event（Lock）、MySQL 的 performance_schema.data_lock_waits（或 SHOW ENGINE INNODB STATUS 的锁等待链）：阻塞者不释放（长事务）→ 等待者占住连接空转——治理：锁等待超时、死锁检测、短临界区、阻塞者 kill。三、网络阻塞——客户端与数据库之间的链路慢/半开（TCP 窗口、代理、防火墙、客户端处理慢）：连接"建立但业务往返慢"（应用发 SQL 后长时间无响应）：查应用侧等待（线程栈显示 socket read 等待）、数据库侧"连接活跃但无 SQL 到达"（无当前查询、客户端仍 connected）、网络层（tcpdump 的往返、netstat 的 ESTABLISHED 堆积）——治理：网络诊断、连接健康检查（keepalive/探测）、应用侧超时。四、池内泄漏——应用拿连接未归还（忘记 close、事务未 finally 释放、异常路径跳过归还）：池被"僵尸连接"占满：查池统计（活跃/空闲/泄漏计数、getConnection 超时）、应用线程栈（持有连接但不操作的位置）、DB 侧"长 idle 连接"（sleep/idle 超过阈值且无事务）——治理：连接租约（maxLifetime/validationQuery）、泄漏检测（HikariCP 的 leakDetectionThreshold）、统一 try-with-resources/finally。

诊断顺序：一、DB 侧先看"连接分布"（多少 idle/active、多少 in transaction、多少等锁）——长事务/锁等待直接可见；二、应用侧看"拿不到连接时线程在哪"（jstack/线程 dump：等 pool 信号量、还是等 DB 响应）——区分"池内占用"与"网络慢"；三、网络验证（对 DB 端口 RTT、抓包、proxy 链路）；四、池配置与泄漏检测（max 值、timeout、leak 日志）。治理组合：事务超时+锁超时兜底、连接健康检查（剔除半开）、池参数（最大连接与等待队列、按 CPU 核数合理设置——连接过多本身是争用源）、监控（活跃连接曲线、事务时长分布、锁等待事件）。结论："CPU 低+池耗尽"= 连接未归还或事务未结束或网络慢，先按"事务/锁→池泄漏→网络"的顺序排查，用 DB 侧视图+应用线程栈+网络三层证据定位。

以"连接被占用但不消耗 CPU"为起点，分长事务、锁等待、网络阻塞、池泄漏四类给检查点与工具，再给"DB 视图→线程栈→网络"的排查顺序。

• 复制槽语义：保留"slot 未消费的 WAL"（即使 checkpoint 推进、即使被删除的日志）——消费端 lag → WAL 无法回收 → 磁盘膨胀
• 关键指标：slot 的 restart_lsn/confirmed_flush_lsn 与当前 WAL 插入位置的差距（pg_replication_slots 的 restart_lsn、pg_wal_lsn_diff）、pg_wal 目录大小、消费端状态（是否存活/卡住）
• 治理：监控告警（lag 阈值）、清理（丢弃/重建 slot）、消费端健康（CDC 任务恢复）

逻辑复制槽（replication slot）的核心契约："消费者确认消费到的位置之前的所有 WAL 不得被回收"——即使该 WAL 已被 checkpoint 覆盖（正常情况 WAL 可删除，被 slot 引用则保留）。因此：一、消费端（CDC 工具/订阅）停止消费或 lag（网络、故障、重启卡住）→ slot 的 restart_lsn 不再推进 → 新 WAL 继续生成而旧 WAL 无法删除 → pg_wal 目录无限增长（磁盘膨胀）；二、膨胀速度 = WAL 生成速率（写入负载）× lag 时长；长时间不消费可撑满磁盘（数据库只读/宕机——PG 在 WAL 空间不足时可能 PANIC）。MySQL 侧的对应：传统复制无 slot（relay log 由 IO 线程消费、可自动清理），组复制/克隆的 applier 通道与"binlog 保留策略"（binlog_expire_logs_seconds）类似——"未消费日志被保留"是复制协议共性；云数据库（托管 PG/RDS）的 slot 由用户创建（如 Debezium），云厂商不会自动清理用户 slot（可能提供"未消费 slot 告警"）。

关键监控指标：一、slot lag——pg_replication_slots 的 restart_lsn（解码起点）与 confirmed_flush_lsn（已确认消费点）和"当前 WAL 写入位置"（pg_current_wal_lsn）之差（pg_wal_lsn_diff()）——lag 持续增长即消费停滞；二、wal_status——pg_replication_slots 的 wal_status 字段（reserved/extended/unreserved/lost）：reserved=slot 保留 WAL、lost=WAL 已被回收（slot 已不可用——最坏情形）；三、pg_wal 目录大小与文件数（df 磁盘、ls pg_wal | wc 与总字节）；四、消费端健康——CDC 任务状态（连接、poll 间隔、错误重试）、slot 的 active 状态（active=false 且不消费=隐患）；五、最旧 WAL 与 checkpoint 位置（redo 截断点）的差距（WAL 保留原因）。治理：一、监控告警——slot lag（如 >1GB 或 >30 分钟）与 pg_wal 增长速率告警；二、消费端恢复——CDC 任务重连/重试、消费端版本兼容（解码冲突会导致消费端持续失败）；三、清理——确认不再需要时 DROP_REPLICATION_SLOT（释放 WAL 保留）；"重建 slot"流程（新 slot+新快照）用于"不可恢复的 lag"（重新全量+增量）；四、配额兜底——云厂商磁盘自动扩容（如 RDS 的存储自动扩展）或 WAL 保留上限设置（如 RDS 的 wal 保留参数）；五、防止误用——临时验证不要创建 slot、用完即删、消费端部署监控。工程启示：任何"逻辑复制/CDC"架构的运维基线：slot 监控（lag+wal 状态）+ 磁盘监控 + 消费端健康，缺一不可；"slot 未消费导致磁盘满"是 CDC 上线的第一大事故源。

以"slot 语义=未消费 WAL 不可回收"解释磁盘膨胀机制（lag×写速率），再列 restart_lsn/confirmed_flush_lsn/wal_status/pg_wal 大小等指标与治理流程。

• 分库分表（sharding）：数据按分片键分布到多实例——查询要么"下推"（单分片完成）要么"汇聚"（跨分片合并）
• 下推策略：分片键过滤下推（WHERE 含分片键→只查相关分片）、聚合下推（各分片先局部聚合，再全局聚合（两阶段聚合））、排序下推（分片局部有序，全局归并（merge sort））、join 下推（同键 join 在分片内完成（同库 join），不同键 join 需"搬运"（broadcast/repartition））
• 分布式优化器：代价模型含网络代价（数据搬运量）、执行计划"下推算子树 vs 汇聚算子树"的划分（如 ShardingSphere、Vitess、TiDB 的 coprocessor 下推）

分库分表架构中，数据按分片键（shard key）水平分布；查询优化器的核心决策是"哪些算子下推到分片执行、哪些在汇聚层（proxy/协调节点）执行"：一、过滤下推——WHERE 条件含分片键（等值/范围）→ 路由到精确分片（单分片查询，无跨片）；不含分片键 → 广播到全部分片（全片扫描后合并）。二、聚合下推（两阶段聚合）——各分片先做"局部聚合"（GROUP BY 的局部结果），汇聚层做"全局聚合"（合并同组）：下推的局部聚合大幅减少跨片传输量（传输的是聚合结果而非明细）；典型：COUNT/SUM 全局=局部和相加、AVG 需"和+计数"、MIN/MAX 直接取最值、COUNT(DISTINCT) 需全局去重（分片局部 distinct + 汇聚层再 distinct）。三、排序下推（归并排序）——各分片按排序键"局部有序"（每片返回有序流），汇聚层做"K 路归并"（多路合并，O(总行数) 而非全量重排）；LIMIT 可下推为"每片取 topN"再全局取 topN（分片局部 topN + 汇聚 topN——正确性：全局 topN 包含在每片 topN 的并集中）。四、join 下推——a) 同分片键 join（两表分片键相同且 join 条件含分片键）→ 分片内完成 join（无跨片数据移动，最优）；b) 不同键 join → 需数据搬运：小表广播（broadcast：小表复制到各分片后本地 join）或大表重分布（repartition：按 join 键重新打散（Shuffle join）——对应分布式引擎的 hash shuffle）；c) 分片键无关但能"同库 join"（同实例内多表 join 由分片内完成——Vitess/MyCat 的"同库表 join"支持）。五、子查询/窗口函数——窗口函数大多需要全局重排（无法纯下推），汇聚层执行；部分可下推（分区内窗口）。六、事务与一致性的下推边界——跨分片事务（XA/分布式事务）与"全局唯一约束"无法下推。

执行计划形态：优化器生成"下推树（pushdown plan）"，如 Vitess 的 Plan（Route/Join/Union 混合）、ShardingSphere 的 SQL 改写（把逻辑 SQL 改写为分片 SQL：聚合改两段式、分页改归并）、TiDB 的 Coprocessor 下推（把表达式/聚合下推到 TiKV 的 coprocessor）。工程取舍：一、下推越深，网络传输越少（性能越好），但分片 SQL 的复杂度（改写正确性：去重、排序语义、函数副作用）越高；二、"无分片键条件"的查询（全片扫描）要避免（设计上保证核心查询带分片键或提供"全局索引/汇总表"）；三、聚合/排序下推的典型收益量化（跨片传输量对比：明细 vs 聚合结果）；四、数据倾斜：分片键选择决定"热点分片"（join/聚合的倾斜使单分片成为瓶颈）；五、广播 join 的成本（小表多大、网络带宽）与缓存（广播表的本地缓存）。结论：分布式查询优化=算子下推决策（过滤/聚合/排序/join 的"分片内可完成性"）+ 数据搬运策略（广播/重分布）+ 汇聚层合并算法（归并/两阶段聚合），核心原则"能下推就下推、传输最小化"。

按"过滤路由、两阶段聚合、归并排序、同键/广播/重分布 join"四类下推策略展开，再讲执行计划形态（Route/改写/Coprocessor）与工程取舍。

• 无直方图/MCV 的列（如均匀分布假设）：估算依赖"表的行数×均匀分布假设"（准确性差）；MCV 覆盖"倾斜值"——MCV 是否准确依赖最近一次 ANALYZE 时的数据分布
• analyze 频率决定统计新鲜度：数据变更（插入/删除/更新）后统计过时 → 基数估计偏差 → 计划错误（如等值条件用均匀假设估算）
• 自动 analyze 触发：autovacuum 的 analyze 阈值——"变更行数 > analyze 基数阈值（autovacuum_analyze_threshold）+ 比例阈值（autovacuum_analyze_scale_factor × 当前行数）"触发（autovacuum 守护进程）

PG 的每列统计：ANALYZE 采样后计算 null_frac、n_distinct、MCV（most common values：出现频率最高的值及其占比，默认最多 100 项）、直方图边界（非 MCV 值的分布近似）、相关性等。对"等值查询（WHERE col = v）"的选择性估算：若 v 命中 MCV 列表 → 用 MCV 中的频率（准确）；未命中 MCV（或该列无 MCV/直方图）→ 回退"均匀分布假设"（1/n_distinct 或按直方图桶估计）——当数据倾斜（少数值占多数）且 MCV 未捕获/过时时，均匀假设严重低估/高估行数（如"status='active' 占 90%"但 MCV 显示均匀 → 估算 10% 实际 90%，join/索引选择错误）。因此 MCV 的准确性完全依赖"最近一次 ANALYZE 时的数据分布"：analyze 频率低 → 统计滞后于实际数据（新出现的倾斜值不在 MCV、已消失的 MCV 值仍被高估）→ 计划错误——"统计新鲜度=计划质量"的直接对应。

自动 analyze 的触发（autovacuum）：autovacuum 守护进程周期性检查各表：统计"自上次 analyze 以来的变更行数"（插入+删除+更新）——当"变更行数 > autovacuum_analyze_threshold（默认 50）+ autovacuum_analyze_scale_factor（默认 0.1）× 当前行数"时触发 ANALYZE：即小表（行数少）靠"绝对阈值"（50 行变更即触发）、大表靠"比例阈值"（10% 行变更触发）；还有强制触发条件（如"新表"或"统计缺失"）；vacuum 与 analyze 可以独立触发（autovacuum 分 vacuum 与 analyze 两套计数：autovacuum_vacuum_scale_factor=0.2、analyze=0.1，绝对阈值均为 50）。工程调优：一、高频更新表——调低 scale_factor（如 0.01）或设表级参数（ALTER TABLE SET (autovacuum_analyze_scale_factor=...)）保统计新鲜；二、大表——比例阈值使"低频更新也触发"，可能过度（调高或使用"按列 STATISTICS"）；三、倾斜场景——提高 default_statistics_target（MCV 数量与直方图桶数）、列级 statistics、扩展统计（MCV 列表在多列上）；四、监控——pg_stat_user_tables 的 last_analyze、n_mod_since_analyze（与阈值的距离）、autovacuum 日志；五、手动 ANALYZE（批量导入后、schema 变更后）。结论：MCV/直方图是"过去时"的采样，analyze 频率=统计保鲜，自动 analyze 阈值=变更量的启发式触发器。

以"MCV 命中 vs 均匀假设"讲清估算对统计新鲜度的依赖，再给 autovacuum 的"绝对阈值+比例阈值"触发公式与表级调优。

• 内存库的持久化本质：内存数据是权威，落盘是"备份/恢复介质"——写入内存即成功，落盘异步；断电丢"未落盘部分"
• COW（RDB/bgsave 快照）：fork 后子进程写快照文件——COW 使"父进程后续写"复制页（写放大：快照期间修改的页复制一份）——内存放大（copy-on-write 页）+ 快照 I/O
• 对比：AOF 写放大低但恢复慢、RDB 恢复快但快照开销与 COW 放大、混合方案

内存数据库（Redis/VoltDB/MemSQL 类）的性能模型是"内存即真相"，持久化只是"断电/崩溃后的重建介质"：写操作确认=写入内存（+日志缓冲），落盘是后台/周期行为。为何仍需 fsync：write() 只把数据写入 OS 页缓存——断电（或内核崩溃）时页缓存内容丢失：数据"在内存库中已确认"但"盘上没有"——fsync 强制把页缓存刷入磁盘（持久）；不 fsync 的后果：断电丢失窗口=自上次 fsync 以来的全部写入；"定期 fsync"=控制丢失窗口（每秒、每次、或按策略）与吞吐的权衡（fsync 是持久屏障，高频 fsync 直接拖垮吞吐——所以"定期"而非"每次"）。AOF（Redis 的追加日志）：每次写追加一条命令记录：写放大≈1（顺序追加、无重写旧数据），fsync 策略（appendfsync always：每次 fsync——最安全最慢；everysec：每秒——默认，丢≤1s；no：交给 OS——丢窗口最大）；代价：一、重放恢复慢（逐条执行命令，大 AOF 恢复时间长）；二、文件膨胀（积累所有写操作，需 BGREWRITEAOF 压缩——重写是"读当前内存状态生成最小命令集"）；三、追加的"日志写"是写路径固定开销（每次写多一次文件 I/O，即使 no fsync 也有页缓存写入）。COW 快照（RDB/bgsave）：fork 出子进程，子进程把内存状态写为快照文件——fork 后父进程继续写：被修改的页触发 COW（复制原页给子进程的地址空间）——写放大：快照期间"父进程修改的每个页"额外复制一份（内存带宽+内存占用翻倍风险（快照期间写密集时 COW 页激增，可用内存紧张→可能 swap/淘汰））；快照 I/O：全量内存写出（数据量大时 I/O 时间长）；但恢复快（直接加载二进制快照）；丢失窗口=快照间隔（save 策略：N 秒 M 次变更触发）。对比结论：AOF——写放大低（≈1）、丢失窗口细（fsync 策略可控）、恢复慢（重放）；RDB——写放大高（全量快照+COW 复制）、丢失窗口粗（快照间隔）、恢复快；混合（Redis 4.0+ 的 AOF+RDB 混合：AOF 头用 RDB 快照、后接增量命令——恢复快且丢失窗口小）。MemSQL/SingleStore 类：行存+列存的内存引擎用"WAL+定期 checkpoint（快照）"——同样"WAL 写放大低、checkpoint 全量写"的组合。工程调优：Redis 的 save 与 appendfsync 组合按"丢失容忍×吞吐"配置；监控 rdb_bgsave_in_progress/copy-on-write 内存（info memory 的 used_memory 与 COW 峰值）、AOF 文件大小与重写频率；云内存库（托管 Redis）的持久化策略由厂商实现（AOF/快照混合）。

以"内存为真相、落盘为备份"的模型解释 fsync 的丢失窗口控制，再对比 AOF（追加≈1 写放大、重放慢）与 RDB/COW（全量+COW 页复制、恢复快）的代价。

• 尾延迟（tail latency）来源：队列深度（过深排队）、中断聚合/丢失、热节流（固件降速）、介质错误/重试（命令重试与错误恢复）
• 关联方法：时间对齐（同一时间窗内的延迟尖峰与事件）、分段（把延迟按"队列等待/设备处理/中断延迟"拆解）
• 工具：blktrace/iostat/perf + nvme smart-log/error-log、fio 的 latency 直方图（clat 分布）

NVMe 尾延迟（P99.9 以上尖峰）的排查按"延迟构成"拆解：一次 I/O 的完成延迟 = 提交队列排队时间（SQ 深度/调度）+ 设备执行时间（固件处理、介质访问）+ 完成通知延迟（中断聚合/中断丢失）+ 错误重试（命令重试、介质错误恢复）。关联方法：一、队列深度——iostat 的 avgqu-sz/await（设备队列平均深度：深度大=排队）、fio 的 clat 直方图（latency 分布形状：长尾=排队/重试）；队列深度高时延迟尖峰多为"排队延迟"（提交侧拥塞：iodepth 过大、并发写饱和）——对照"降低 iodepth/并发后 P99 是否改善"。二、完成中断——/proc/interrupts 对应 MSI-X 向量（每队列一个）的中断计数与"合并配置"（ethtool 不适用 NVMe，用 nvme 的 interrupt coalescing 参数（IRQ 聚合时间）与驱动的 irq 统计）：中断延迟尖峰（中断处理被延迟：CPU 繁忙/软中断预算耗尽/中断聚合窗口）→ 延迟尖峰与"中断批处理"对齐；观测"完成通知延迟"可用 blktrace 的 C 事件（complete）时间戳与内核 nvme 驱动的完成处理（perf 的 irq/softirq 栈）。三、热节流——nvme smart-log 的温度、critical_warning（温度位）与"throttle 状态"（部分控制器的 Performance Degradation 计数）：温度高/节流时设备自降速（命令执行时间变长）——延迟尖峰与"高负载升温周期"时间对齐（对照温度曲线）；治理：散热、降低负载、控制器热策略。四、介质错误——nvme error-log（Get Log Page 01h：错误条目含命令、状态、LBA）与 SMART 的 media_errors/read/write 错误计数、内核 dmesg 的"nvme 命令超时/重试"日志：介质错误触发重试（命令重试、内部 LBA 重映射）→ 单命令延迟放大为几十 ms~秒级——延迟尖峰与"错误日志时间戳"对齐；治理：更换介质/盘、监控错误计数趋势。

工程流程：一、先建立"延迟尖峰时间线"（fio/业务的 P99 时间序列 + 系统时间）；二、叠加观测——队列深度（iostat）、中断计数/软中断延迟（/proc/interrupts+perf）、温度与 throttle（nvme smart-log 周期采样）、错误日志（nvme error-log 与 dmesg）；三、时间窗对齐找"尖峰伴随因素"（同窗内队列深？温度升？错误条目？）——逐项排除；四、分段验证——用 nvme 的"命令完成时间"（fio 的 slat/clat 分解：submission latency（提交到设备接收）与 completion latency）区分"提交侧排队"与"设备侧慢"；五、专项实验——固定负载变 iodepth（队列深度影响）、关中断聚合（延迟-吞吐交换）、降负载看温度节流消失。结论：尾延迟=排队+执行+通知+重试四段之和，关联排查=时间对齐+分段拆解+对照实验。

以"队列排队/设备执行/完成通知/错误重试"四段延迟构成讲排查框架，按段给出观测手段与时间窗对齐方法。

• direct=1（O_DIRECT）：绕过页缓存——测"真实设备路径"；buffered（direct=0）走页缓存——测的是"缓存命中/写回"而非设备
• 掩盖问题：buffered IO 的"写成功"=进入页缓存（未落盘），延迟=缓存写入（低）；读=缓存命中（极快）——设备延迟、写回延迟、断电丢失都被掩盖；尾延迟（设备队列、GC、介质重试）在 buffered 下不可见
• 结论：性能与延迟测试必须 direct=1 + 正确 iodepth/numjobs 组合

fio 的三个参数语义：一、iodepth——每个 job 的异步队列深度（libaio/io_uring 的 in-flight 请求数）：决定"设备面前排多少队"——iodepth=1 测单请求延迟（随机读 P99 反映设备固有延迟），iodepth=32~256 测"队列饱和吞吐"（高深度下延迟上升=排队延迟）；二、numjobs——并发 job（进程/线程）数：总并发=iodepth×numjobs（多 job 模拟多应用并发）；两者的区分：固定总深度下"单 job 深队列 vs 多 job 浅队列"的调度与设备行为不同（多 job 引入调度器/锁竞争、io 公平性），测试矩阵必须显式声明两者。三、direct（O_DIRECT）：direct=1 绕过页缓存直接提交设备（真实设备路径：队列、固件、介质）；direct=0（buffered）：写只进页缓存（立即返回成功——"成功"未落盘）、读命中页缓存（已缓存部分零设备访问）——测的是"缓存路径"而非设备能力。

误用 buffered IO 掩盖的问题：一、设备尾延迟——写回（writeback）延迟、设备队列等待、GC/磨损均衡停顿、介质重试（错误恢复）在 buffered 下"看不见"（写确认早于落盘，读命中缓存）；二、持久性语义——buffered 的"完成"不代表持久（fsync 才落盘）——测出的延迟不含 fsync 成本；三、缓存命中率掩盖读延迟——重复读同一文件全命中（延迟=内存拷贝）——"读性能好"是假象；四、写放大/断电丢失无法暴露。因此：延迟与设备性能测试必须 direct=1（或 sync=1+fsync 语义明确）；"尾延迟问题"（设备层尖峰）只有在"真实设备路径"（O_DIRECT + 正确深度 + 长时间/大样本）下才显现——典型的"生产慢但 fio buffered 测不出"事故正源于此。工程实践：一、测试矩阵——"iodepth × numjobs × direct"全组合（如 direct=1/0、iodepth=1/16/64、numjobs=1/8）；二、尾延迟样本——percentile_list=99:99.9:99.99 + 大 runtime（长时间暴露低频尖峰（GC、热节流））；三、混合读写（rw=randrw 的读写比例）与"预填充"（写放大与 GC 需预热）；四、对照实验——direct=1 vs 0 的延迟差=缓存贡献；生产复现——按生产的队列深度与并发参数跑。结论：iodepth/numjobs 定义"负载形状"、direct 定义"被测路径"，缺一不可；buffered 只能测缓存语义。

以"iodepth=单 job 深度、numjobs=并发数、direct=是否绕缓存"三参数语义开题，再列举 buffered 掩盖的尾延迟类别（写回/队列/GC/重试）与正确测试矩阵。

• 页断裂（partial/torn page write）：崩溃/断电时"16KB 页只写了一半"——页既非旧也非新（半新半旧），redo 无法重放（redo 记录假设页是"旧版本"可重放；页损坏则重放结果错误）
• 恢复机制：崩溃后扫描 doublewrite buffer 中"完整写入的页副本"，与数据页校验和比较——数据页损坏且副本完整→用副本覆盖
• 性能影响：每次写多一次"顺序写 doublewrite 区"（写放大：额外 1 次顺序写，随机写场景影响小（顺序写快），SSD 上约 10~20% 开销；可关闭（innodb_doublewrite=0）或"跳过 doublewrite 的 fs 用原子写"（如支持 4KB 原子写的设备（部分 NVMe/PMEM）可关闭））

页断裂问题：InnoDB 的页是 16KB，而磁盘的最小写单位（扇区）是 512B/4KB——断电或系统崩溃时，一次 16KB 写可能"只完成部分扇区"（torn page/partial write）：页内容变成"新旧混合"（校验和与内容不匹配）：崩溃恢复时 redo 重放假设"页是崩溃前的完整旧版本"（redo 记录只包含修改前后的增量语义），页已损坏则重放无法得到正确结果（可能写出错误数据/损坏蔓延）。doublewrite buffer 的机制：脏页写回前，先"整页顺序写入"doublewrite buffer（位于共享表空间的专用区域，按 1MB 批次（每次最多 64 页，分两次批量写）顺序写——顺序写效率高），再写回实际数据页位置。崩溃恢复：启动时检查 doublewrite buffer 中的页副本：若对应数据页"校验和失败"（写回中断导致 torn），且 doublewrite 中的副本完整（其批次写入是"先整批写 doublewrite、成功后才开始写数据页"——doublewrite 写成功表示页内容完整）→ 用 doublewrite 副本恢复数据页，再进行 redo。即"doublewrite 提供'页的完整旧版本/新版本副本'，防 torn 页导致的恢复不可靠"——解决了"页断裂使 redo 无法安全重放"的根本问题。

性能影响：一、写放大——每次页写回额外"写一次 doublewrite 区"（逻辑写量近似 2×，但 doublewrite 是顺序批量写（1MB 批次），相对随机写回是高效顺序 I/O；机械盘上顺序写快，SSD 上写放大消耗 NAND 寿命/带宽）；二、实际开销——随机写负载下通常 10~20% 左右（大页随机写场景），顺序写/大批量场景影响小；三、关闭条件——innodb_doublewrite=0 或 DETECT_ONLY（只检测不恢复）：a) 存储层保证"原子写"（如支持 4KB 原子写的最小写单位设备（部分企业 SSD/PMEM/NVMe 的 atomic write）——InnoDB 页 16KB 仍可能 torn（除非设备支持 16KB 原子写）；b） 允许"损坏检测+从备份恢复"（DETECT_ONLY：崩溃时检测 torn 页但依赖备份/复制恢复）；四、监控——doublewrite 的写次数与等待（SHOW ENGINE INNODB STATUS 的 dblwr 统计、performance_schema）、SSD 的写放大观测（smart 的 NAND 写入）。工程权衡：默认开启（可靠第一）；高写入吞吐且存储保证原子写时关闭（如云盘/PMEM 的 atomic write 支持、或接受"极低概率 torn 页+检测兜底"）；对"页大小=设备原子写单位"的场景（如 4KB 页配置+4KB 扇区设备）理论可关但官方仍建议保留（校验和检测兜底）。结论：doublewrite 用"2× 逻辑写"换"torn 页可恢复"，是"随机写场景可接受、原子写设备可关闭"的可靠性-性能权衡。

以"torn page 使 redo 无法安全重放"讲清问题本质，再以"整页先写 doublewrite 区、崩溃时校验和比对恢复"讲机制，最后量化 2× 写放大与关闭条件。

• 数据模式（data= 挂载选项）决定"文件数据"何时写盘与是否进日志：
• journal（全日志）：数据也进日志（写放大最大），崩溃后数据与元数据都"事务一致"（数据也重放）
• 权衡：ordered 默认（可靠性-性能平衡）、writeback 快（数据一致性弱）、journal 最可靠最慢

ext4 的 data= 模式决定"文件数据"与日志的关系：一、ordered（默认）——元数据走日志（journal 记录元数据变更），数据不写日志但保证"数据块先于元数据提交落盘"（提交元数据事务前先把相关数据页写回）：崩溃恢复时重放元数据日志——文件的大小/块映射（元数据）正确，且数据要么是"旧完整版"（数据未写回，元数据也未提交）要么"新完整版"（数据已写回）——不会出现"元数据已提交但指向未写的数据块"（无 torn 的"数据空洞"——虽然数据内容可能不是最新（数据写回与崩溃的时序），但"元数据与数据的版本对齐"保证文件结构一致）。二、writeback——只把元数据写日志，数据写回时机任意（可晚于元数据提交）：崩溃后元数据重放得到"新文件大小/映射"，但数据块可能未写回（内容为旧/垃圾）——出现"元数据指向未写入的数据"（读出新大小但内容旧/零）——数据一致性最弱（元数据一致、数据可能错位）；性能最好（数据写回自由、无"先数据后元数据"的顺序约束）。三、journal（data=journal）——文件数据也写入日志（数据随事务记录在日志中，提交后数据实际写入）：崩溃恢复时数据和元数据都从日志重放——"数据与元数据事务一致"（不会出现任何数据-元数据错位，连"写一半"也被日志保证（数据进日志时完整记录））；代价：数据写两次（日志+实际位置）——写放大最大、性能最差。

崩溃语义对比：一、ordered——"结构一致、数据版本对齐"（最常见需求，默认选择）；二、writeback——"结构一致、数据可能错位"（适合"数据可由上层重建/校验"的场景（如临时数据、可重算缓存），性能优先）；三、journal——"完全事务一致"（适合"数据和元数据都必须原子"且写放大可接受（小文件/元数据密集、对崩溃后"数据必须是旧版或新版"有硬要求））。工程实践：一、数据库/关键数据文件用默认 ordered（或配合应用 fsync 纪律）；二、日志/临时文件（重建成本低）可 data=writeback 提性能；三、data=journal 用于"小文件系统、崩溃一致性要求极致"（嵌入式/只读镜像场景）；四、监控与验证——崩溃测试（断电注入）检查三种模式的恢复结果（文件内容与大小的组合）、dumpe2fs 看 default_mount_opts；五、注意"ordered 的保证范围"：只保证"元数据提交前数据已写回"——不保证"数据一定是最新"（应用需要 fsync 落最新数据）。结论：三模式的本质是"数据写回与元数据日志的时序契约"——ordered 对齐版本、writeback 允许错位、journal 全量重放。

以"数据与元数据日志的时序"为轴对比三模式：ordered 先数据后元数据（版本对齐）、writeback 数据自由（可能错位）、journal 数据进日志（全一致但写放大）。

• 传统单队列（legacy block layer）：全局 request_queue + 电梯调度器（排序/合并）——锁竞争（单队列锁）与寻道优化
• ctx 合并：软件队列内的 bio 合并（相邻/同页）在 per-cpu 无锁路径做；调度器（none/mq-deadline/bfq）挂在 hw queue 上
• IOPS 隔离：多 hw queue 使不同 CPU/应用的 IO 走不同队列（并行提交、互不阻塞）；bfq 提供 per-cgroup/per-process 带宽公平（隔离）

传统单队列模型（2.6 时代）：所有请求进入一个全局 request_queue，电梯调度器（CFQ/deadline/noop）在单队列上做排序、合并与寻道优化——多核并发提交全部争用"单队列锁"（锁竞争成为高 IOPS 瓶颈）、调度器单点处理（吞吐受单队列串行限制）。blk-mq（3.13+，现代默认）的多队列架构：一、硬件队列（hw queue）——对应设备的多队列能力（NVMe 的每队列对、多核网卡的 RSS 式）：每个 hw queue 有独立的完成机制（中断/轮询）与深度控制，IO 按 CPU 映射到不同 hw queue（每核一个/多个）——并发提交走各自队列，无全局锁（锁粒度降到 per-queue）；二、软件队列（ctx，per-cpu 软件队列）——设备驱动接收 bio 时先在"当前 CPU 的软件队列"做合并（ctx 合并：相邻扇区、同页 bio 合并为 request）与排队（无锁/轻锁的 per-cpu 路径），再由调度器（可选）分派到 hw queue——"合并"从"全局电梯"变为"per-cpu 快速合并"（减少锁与缓存争用）；三、IO 调度器在 blk-mq 的形态——none（无调度器：bio 直接入 hw queue，SSD/NVMe 推荐）、mq-deadline（按截止时间+扇区排序，旋转盘）、bfq（按进程/cgroup 公平）——调度器挂载在"hw queue 层"（per-hw-queue 实例），保留"电梯"的排序/合并语义但粒度与并发性更好；四、IOPS 隔离——多 hw queue + per-cpu 提交使"不同 CPU 的 IO 互不阻塞"（一个队列的拥塞不影响其他队列）；bfq 的 per-process/per-cgroup 带宽公平提供"多租户 IO 隔离"（每个进程/cgroup 独立带宽预算，互不饿死——传统单队列的 CFQ 也有类似但全局单点）；硬件层（NVMe）的队列深度独立也提供"队列级隔离"（一个队列满不阻塞其他队列）。

工程影响：一、SSD/NVMe 用 none（设备内部调度足够，块层调度反而加延迟）；旋转盘用 mq-deadline/bfq；二、队列数配置——blk-mq 的 hw queue 数=设备能力（NVMe 每核一对），软件队列数=CPU 数（nr_cpu_ids），可调（queue_depth、poll 模式）；三、IOPS 扩展性——多核并发随机 IOPS 随核数近线性（对比单队列的锁瓶颈）；四、隔离场景（多租户/容器）——bfq（或 cgroup io.weight/io.max）做 IO 带宽隔离（v2 的 io 控制器基于 bfq 的接口）；五、观测——/sys/block//mq/ 下的每队列统计（nr_ctx、调度器状态）、iostat 的 per-device 与 blktrace 的队列事件、/sys/block/.../queue/nr_requests 与 iosched 参数。结论：blk-mq 把"单队列电梯"拆为"per-cpu 合并 + per-hw-queue 调度 + 多队列并行"，锁竞争消除、合并局部化、隔离按队列/按 cgroup 实现。

以"单队列全局锁 vs 多队列并行"开题，分别讲 hw queue 映射与并行、ctx 的 per-cpu 合并、调度器挂载形态与 IOPS 隔离（队列级+bfq/cgroup 级）。

• 多路径（DM Multipath）：多个路径（HBA/链路）到同一存储，故障时路径切换
• 挂住机制：路径长时间不恢复 + 排队 IO 无限累积（应用阻塞在 IO 上永不返回）——"永久挂住"（除非恢复或超时）
• 治理：no_path_retry 超时（N 次重试后失败返回）、queue_if_no_path 与 fail_if_no_path 切换、路径检测（checker）、监控与告警

DM Multipath（device-mapper 多路径）把多条物理路径（多个 HBA/端口/交换机链路）聚合成一个虚拟设备：IO 按负载均衡/故障转移策略选择路径；某条路径失效时切换到其他路径。queue_if_no_path 是 multipath 的"行为策略"：当"所有路径都失效"时，新 IO 不是立即返回错误（EIO），而是"排队等待"——期望路径恢复后继续处理（对应用透明，避免"存储短暂抖动导致应用批量报错"）。挂住的机制：若路径长时间不恢复（链路彻底断、存储故障、配置错误）——排队 IO 无限累积：应用发起的每个 IO（read/write）都阻塞在"等待路径恢复"上（ioctl/系统调用不返回）；数据库/文件系统的写路径被卡死（日志写不回、checkpoint 停滞），应用表现为"永久挂住"（无超时、无错误、无进展）——直到：a) 路径恢复（IO 继续）；b) 配置的 no_path_retry 超时（重试 N 次后把 IO 以错误返回——默认 no_path_retry 有限（如 5 次）还是无限？multipath 的 no_path_retry 参数：默认"queue"（无限排队）或指定次数（重试 N 次后 fail）——若配置为 queue（无限）且无人干预，就是"永久挂住"）；c) 管理员干预（multipathd 的 fail_if_no_path 切换）。

工程治理：一、配置超时兜底——no_path_retry 设为有限次数（如 5~10）或"fail_if_no_path"（无路径立即失败返回 EIO——应用可感知并处理（重试/切换/告警）），避免无限排队；二、路径检测与恢复——multipathd 的 checker（tur/rdac 等）周期检测路径状态，路径恢复后自动重新加入（queue 的 IO 继续）；三、监控——multipath -ll 看路径状态（active/failed）、dmesg 的路径切换日志、IO 排队时长（iostat 的 await 异常高）、内核 dm 的"queue_if_no_path"计数；四、应用层——数据库/存储应用对"IO 长时间无响应"应配 IO 超时（如 io_uring 的 timeout、DB 的 write 超时）与"只读降级/切换"；五、运维预案——链路抖动演练（断链路观察挂起行为与恢复时间）、配置"路径失效告警"（多路径事件 → 通知）。本质：queue_if_no_path 是"可用性优先"的策略（路径抖动时不让应用失败），其风险是"不可用持续时无限等待"——必须配合"有限重试/超时"把"无限排队"转为"有界等待"，否则就是"可用性策略变成可用性事故"（所有 IO 静止=系统假死）。结论：queue_if_no_path 的"永久挂住"=无限排队+路径不恢复；治理=no_path_retry 限次+路径检测+IO 层超时+告警。

以"所有路径失效→IO 排队等待→无恢复则无限累积"讲清挂住机制，再给 no_path_retry/fail_if_no_path/checker/监控等治理手段。

• page checksum：每页头部存校验和（页内容+页号）；读页/启动时校验——检测"页内容损坏"（torn write、bit rot、介质错误）
• 恢复路径：启动恢复（崩溃后）——先校验各页（checksum 失败=torn 候选）→ 用 doublewrite 副本覆盖 → redo；运行期读页校验失败→报错/从副本/从备份（无副本时只能检测告警）
• 独立价值：checksum 也能发现"doublewrite 之外的损坏"（介质错误、内存错误写坏页）——检测面更广；doublewrite 只防"写回中断的 torn"

页校验和（page checksum，InnoDB 的页头校验和：旧式 crc/新式 crc32c 或 lsn 校验）：每页持久化时计算校验和存入页头（含页号防错位），读取/启动时重新计算比对——不一致即"页损坏"（torn write、bit rot、介质错误、控制器错误）。检测机制：一、启动扫描（崩溃恢复前）——buffer pool 加载页前校验；二、运行期读页——每次从磁盘读入缓冲池校验（校验失败→报"page corruption"错误）。检测到损坏后需要"修复"——这就是 doublewrite 的分工：doublewrite buffer 保存"最近写回批次的完整页副本"：恢复路径——a) 崩溃恢复：启动时校验数据页，校验和失败（torn 候选）且 doublewrite 中有该页的完整副本（doublewrite 批次写入成功才继续写数据页）→ 用副本覆盖数据页（恢复为"完整的新版本"）→ 再执行 redo（把事务修改重放到已恢复的页上）；b) 运行期读页失败：有 doublewrite 副本也可恢复（回读副本），无副本则报错（应用层处理：从备份/复制恢复）。分工总结：checksum=检测器（发现"哪页坏了"），doublewrite=修复源（提供"该页的完整拷贝"）——"检测+修复"成对完成 torn write 的恢复；checksum 的检测面大于 doublewrite 的修复面（checksum 还能发现介质错误/内存写坏——这类损坏 doublewrite 未必有副本（不是"写回中断"），此时只能"检测告警+外部恢复（备份/复制）"——这是"检测面广、修复面窄"的不对称）。

工程细节：一、校验算法——InnoDB 的 innodb_checksum_algorithm（crc32/full_crc32/strict）与"页号绑定"（防"页内容对但写错位置"）；PG 的 page_checksum（其全页校验+WAL 的块校验）——不同实现但思想一致；二、torn write 的"部分校验"——校验和是"整页"的：页写一半（部分扇区新部分旧）必然校验失败（哪怕 4KB 扇区完整、16KB 页撕裂）——校验粒度=页，撕裂检测粒度=扇区（页级校验覆盖）；三、监控——校验失败事件（错误日志、performance_schema）、"页损坏"告警与修复流程（从副本/备份/主备切换）；四、禁用校验的代价——innodb_checksum 关闭后 torn write 无法检测（依赖 doublewrite 盲恢复？无检测则"坏页未被发现"直接使用——绝不建议）。结论：torn write 的完整防御 = "checksum 检测（发现坏页）→ doublewrite 副本修复（恢复完整页）→ redo 重放（应用已提交修改）"的三段流水；checksum 同时覆盖"非 torn"损坏的检测（检测面更广）。

以"checksum=检测、doublewrite=修复源"讲清二者分工（检测面广 vs 修复面窄），再展开恢复路径（启动校验→副本覆盖→redo）与运行期读页失败的处理。

• 三大指标：写放大（每次写入实际落盘次数）、读放大（一次点查读取的块/文件数）、空间放大（磁盘占用/逻辑数据）
• leveled（LevelDB/RocksDB 默认）：每层大小指数增长（T 倍），层内有序无重叠——读放大 O(L)（L 层数）、写放大 O(T)（每层合并重写）、空间放大 O(1+1/T)
• 三角表达：三者互相制约——低写放大（tiered）牺牲空间与读；低读放大（leveled 高层）靠更多合并（写放大）与紧凑空间

LSM-tree（RocksDB/LevelDB/Cassandra 等）的三大成本指标：写放大（WA：一次逻辑写实际触发的磁盘写次数——compaction 重写）、读放大（RA：一次点查/范围查需要读取的文件/块数量——每层查找）、空间放大（SA：磁盘占用/逻辑数据量——重叠与未合并数据）。leveled compaction（分层）：每层容量按放大因子 T（如 10）递增（L0 例外，L1 为 T×L0...），层内文件有序且范围不重叠（除 L0）——指标：读放大 ≈ 层数 L（每层一次二分查找（bloom 过滤后））、写放大 ≈ O(T)（每层数据平均被下层合并重写 T 次？精确：WA≈T×L（每层重写）、空间放大 ≈ 1+1/T（顶层未合并的冗余）；调参：增大 T → 层数减少（RA 降）但 WA 升、SA 降。tiered（universal/tiered compaction）：不立即与相邻层合并——同"大小档"的多个文件（tier）并存，周期性把同档文件合并成一个更大文件（tier 晋升）——指标：写放大低（每次合并文件少、合并频率低（增量式））、空间放大高（多个 tier 的旧版本并存（文件被替换前需保留空间））、读放大高（点查需检查多个 tier 文件（每个 tier 一次查找，层级多时文件数多）））。

三角取舍的表达：三者构成"不可能三角"的权衡面——一、低写放大（SSD 寿命/写入带宽敏感）→ tiered：代价是读放大与空间放大（文件多、需更大磁盘）；二、低读放大（读多场景）→ leveled 的高层数/大 T：代价是写放大（合并频繁）——或依赖 bloom filter 把点查的"文件访问"降为"大概率一次"（bloom 是"读放大的软缓解"：不减少合并但减少实际 IO）；三、低空间放大（磁盘受限）→ leveled（层内无重叠、紧凑）或 tiered 的"最后层合并"（把 tier 合并推进到单层（final merge）降低重叠——代价是写放大回到 leveled 水平）；四、工程落点——RocksDB 的 default（leveled）与 universal 选择由"写入/读取/空间"哪个最稀缺决定：写入量巨大且读少（日志、时序）→ universal（或 leveled 的加大 T）；读多且空间紧 → leveled+bloom；混合 → 分列族/按热度分区（hot 用 leveled、cold 用 tiered）；五、测量——写放大（rocksdb 统计的 compaction 写量/写入量）、读放大（每查询的 SST 访问数（bloom 命中率）、perf 的 IO 次数）、空间（SST 总大小/逻辑大小）；调参的"三角滑动"：T（放大因子）、level_compaction_dynamic_level_bytes、universal 的 size_ratio/max_size_amplification_percent。结论：leveled 站在"低空间+低读（配 bloom）"侧，tiered 站在"低写"侧；工程上"先量化三放大、再选策略与参数"。

以"写/读/空间三放大"定义入手，分别推导 leveled（层指数、RA≈L、WA≈T）与 tiered（tier 重叠、WA 低、RA/SA 高）的指标，再给三角权衡与调参方向。

• 物理日志（redo/WAL 的页级变更）：崩溃恢复的必需品（页级重放），但不适合对外发布（页布局内部细节、无行级语义）
• 偏好：崩溃恢复→物理（redo）；CDC/订阅→逻辑（binlog/row 格式、WAL 解码）；混合系统（PG 的 WAL 物理+逻辑解码、MySQL 的 redo+binlog）两套并存
• 取舍：物理日志可恢复不可发布、逻辑日志可发布不可（独立）恢复——"混用"即各司其职

两类日志的本质：物理日志（page/block 级：描述"哪个页的哪个偏移被改成什么"——如 InnoDB redo、PG WAL 的页级记录）——粒度是"存储布局"，与数据库版本/引擎内部结构强绑定；逻辑日志（行级语义：描述"哪张表的哪一行被插入/更新/删除"——如 MySQL binlog 的 row 格式、PG 逻辑解码输出、Oracle 的 logminer 输出）——粒度是"业务语义"，跨版本/跨引擎可理解。偏好矩阵：一、崩溃恢复——必须用物理日志（redo/WAL）：崩溃后按"页级变更"重放恢复数据库到一致状态（页状态、LSN 对齐）；逻辑日志无法单独恢复（它描述"操作"但不知页布局/索引结构当前状态——恢复需要"操作+页状态"的重放，物理日志直接给"页"）。二、CDC（变更数据捕获）——偏好逻辑日志：消费者（数据仓库、流处理、事件驱动）需要"行级语义"（主键、字段新值/旧值），物理日志（页偏移、压缩格式）不可用；逻辑日志格式稳定（如 binlog row、pgoutput）可被异构系统消费。三、订阅复制（逻辑复制/跨库复制）——偏好逻辑日志：目标库执行"同样的逻辑操作"（INSERT/UPDATE/DELETE 语句语义）即可同步（无需了解源库的页布局），且支持异构（PG→PG 的不同版本、PG→其他引擎）；物理日志只能"页级同步"（物理复制：同版本同引擎、不能跨版本/跨引擎）。

混用架构（主流数据库）：一、MySQL——InnoDB 的 redo（物理，恢复用）+ binlog（逻辑（row/statement 格式），复制/CDC 用）：两套日志独立（两阶段提交保证 redo 与 binlog 一致性）；崩溃恢复用 redo、复制/CDC 用 binlog。二、PostgreSQL——WAL 是物理日志（恢复+物理复制），逻辑解码从 WAL 解析出逻辑流（逻辑复制/CDC 用）——"同一份 WAL、两种视图"。三、取舍原则：物理日志=数据库自身的"底稿"（内部、精确、恢复必需），逻辑日志=对外发布的"报表"（语义、稳定、可消费）——混用即"各司其职"，需要"物理日志支持逻辑解析"（PG 的解码器从 WAL 重建行语义（依赖 catalog 与 REPLICA IDENTITY））或"双写"（MySQL 的 redo+binlog 两套）。工程注意：一、CDC 的日志源选择（binlog row 格式 vs redo 解析）影响"旧值/新值、DDL、事务边界"的可得性；二、逻辑日志的"语义保持"依赖表结构（REPLICA IDENTITY 全键/主键）与 DDL 策略（DDL 不自动进逻辑流（PG）/或需专门处理（MySQL 的 DDL 记录））；三、恢复与复制的分工决定了"备份/恢复方案"（物理备份+物理恢复 vs 逻辑备份+逻辑回放）。结论：恢复要物理（页级精确）、对外要逻辑（语义可消费），现代数据库"物理为底、逻辑为上"。

以"页级布局 vs 行级语义"区分两类日志，按恢复（物理必需）、CDC/订阅（逻辑必需）给出偏好与理由，再以 MySQL redo+binlog、PG WAL+解码说明混用架构。

• 错误放大：估计偏差沿执行树传播（过滤→join→聚合），一个错误估计导致"错误 join 顺序/错误连接方法"（如把 hash join 当 nested loop、大表驱动小表）
• 相关性错误源：列间相关（WHERE a=1 AND b=1 的联合选择性≠独立乘积）、多列 group by、函数依赖
• 扩展统计（extended statistics）：functional dependencies（函数依赖）、ndistinct（多列基数）、MCV（多列最常用值）——修正"独立假设"的偏差

基数估计（cardinality estimation）是优化器的"输入质量"：估算每个操作的输出行数，用于选择——连接顺序（小表驱动大表/最优 join 树）、连接方法（nested loop（小结果集）vs hash join（大结果集）vs merge join（有序））、访问路径（index scan vs seq scan（选择性决定））、聚合/排序策略。错误后果链：一、过滤估计错（WHERE 选择性高估/低估）→ 中间结果行数错；二、join 基数错（两表 join 输出估算错）→ join 顺序错（大表先 join、应该 hash 的用 nested loop）、join 方法错（nested loop 对"实际巨大结果"爆炸（每行索引查找×百万行）——灾难性计划）；三、错误传播——基数沿树相乘/相加放大，"一个错误估计=整棵树错误"（EXPLAIN ANALYZE 的 rows 与 actual 对比可定位）。估计错误的经典来源："独立假设"（independence assumption）——多列条件（WHERE a AND b）的联合选择性按"各列选择性乘积"估算：若 a、b 相关（如"城市=北京 AND 省份=北京"——两条件强相关），乘积严重低估/高估实际行数（"北京"独立概率小、联合概率仍小？相关时联合选择性≈单列而非乘积——低估？方向依相关性（正相关：联合≈较大者（乘积低估）；反相关：联合更小））；函数依赖（a 决定 b）也使联合估计失真；多列 GROUP BY 的组数估计、多列等值 join 的基数同理。

扩展统计（extended statistics，PG 10+ 的 CREATE STATISTICS）修正三类相关性：一、函数依赖（functional dependencies）——检测"列集合 A 的函数依赖 B"（如 a 值唯一决定 b）：优化器对"WHERE a=.. AND b=.."使用"条件数=满足 a 的行数（不再乘 b 的独立选择性）"——修正"相关列联合条件"的低估/高估；二、多列 n_distinct（ndistinct）——估算"多列组合的去重数"（GROUP BY a,b 的组数、多列 join 的基数）：独立假设下"组数=各列 distinct 乘积"失真（相关时组数远小于乘积）；三、多列 MCV（most common values）——统计多列值组合的出现频率（前 N 个组合），用于"高倾斜多列等值"的精确估算（对"组合列命中 MCV"的条件直接用频率）。工程实践：一、先"EXPLAIN ANALYZE"找估计偏差（rows 差大）、pg_stats 看单列统计；二、对"业务上强相关的列组合"（如地理层级、状态+类型）建 CREATE STATISTICS（dependencies/ndistinct/mcv）；三、更新统计（analyze）后重测；四、其他修正——default_statistics_target、分区裁剪、参数化计划；五、错误后验证（auto_explain 采集慢查询计划与实际行数）。结论：基数错误→join 树/访问路径错（可放大为数量级性能差）；扩展统计把"独立假设"替换为"相关性感知"（函数依赖、组合去重、组合 MCV）。

以"基数→join 顺序/方法/访问路径"的决策链讲错误后果与放大机制，再以函数依赖/多列 ndistinct/多列 MCV 三类扩展统计说明相关性修正。

• 写入路径：memtable（内存有序表，批量落盘成 SSTable）——写入先内存后追加式落盘（写放大低：顺序写）
• SSTable：不可变有序文件（分层存储）——读需逐层查找（读放大）；多层间键重叠（空间放大与合并需求）
• 各组件贡献：memtable 影响写路径缓冲（写放大 1 的批量）；SSTable 布局决定读放大；compaction 策略是三角的调节器

LSM-tree 的三组件与三放大：一、memtable——内存中的有序结构（跳表/红黑树）：写入先入 memtable（顺序内存写+WAL 持久），满后 flush 成 SSTable：写放大贡献——批量顺序落盘（每次写≈1 次落盘（WAL 1 次+flush 摊销），写放大低（≈1+compaction 部分））；memtable 大小决定 flush 频率（大 memtable=少 flush=低写放大，但内存占用与恢复时间↑）。二、SSTable——不可变有序文件（块压缩、bloom filter）：分层组织（L0 直接来自 flush（重叠大），L1+ 层内有序不重叠）：读放大贡献——点查需从 L0 到最底层逐层查找（每层一次（bloom 过滤后实际 IO≈1~2 次），层数越多读放大越大）；范围查需跨层合并；空间放大贡献——多层间键重叠（同一键的旧版本分布在多层）需 compaction 消除。三、compaction——后台合并：把重叠的 SSTable 合并成有序的新文件（下沉/晋升）：写放大贡献——合并重写数据（每层数据被下层合并重写，写放大=重写次数）；读放大贡献——合并消除重叠（键在更少文件中）、层内有序（范围查高效）——compaction 越积极，读放大越低；空间放大贡献——合并期间新旧文件并存（临时双份）、未合并的重叠（旧版本占空间）——compaction 完成后回收。

三角联动：一、写放大 = 1（memtable flush）+ 合并重写（每层 T 倍合并约 T×L（leveled）或按 tier 合并频率）；二、读放大 = 层数 ×（每层查找成本）——与层数 L、bloom 命中相关；三、空间放大 = 重叠数据量（未合并的旧版本+合并窗口）——与合并激进程度反相关。调节旋钮：层数（压缩每层大小比）、memtable 大小、bloom filter（降低读放大中的"实际 IO"——软缓解）、compaction 触发（文件数/大小阈值）、leveled vs tiered。工程观测：写放大（rocksdb 的 compaction 写量/总写量）、读放大（SST 访问次数/bloom 命中率）、空间（磁盘占用）；调优案例：写放大敏感（SSD 寿命）→ 增大 memtable+调小每层倍数；读放大敏感（点查多）→ bloom + 控制层数；空间受限 → 激进合并（dynamic level）。结论：memtable 把随机写变顺序批量（写放大≈1 的起点），SSTable 分层决定了读/空间放大的基线，compaction 是"用写放大与空间放大换取读放大"的调节器——三者在此三角上滑动。

以"memtable 批量顺序落盘（低写放大起点）、SSTable 分层（读放大=逐层查找）、compaction 合并（降读放大但增写/空间放大）"讲清各自贡献与三角联动。

• 退化：倾斜键的桶退化为"线性查找/嵌套循环"（桶内匹配 O(n)）、hash 表 spill 到磁盘（随机 IO 爆炸）
• bloom filter 优化：探测前用 bloom 过滤"必然不匹配的行"（减少探测/IO）——但：bloom 需要构建/传递/检查开销；小表小/选择性高时过滤收益低，开销反超；错误率（FP）高时过滤无效
• 何时有害：小表（建 bloom 开销>收益）、CPU 密集但 IO 少（内存命中场景过滤不省 IO）、倾斜（bloom 对"热键"无效（命中即全查））

hash join 的机制：把一侧（通常小表）的 join 键哈希建桶（hash table），另一侧逐行哈希探测匹配。数据倾斜的退化：join 键分布不均（少数键占绝大多数行，如"用户表 join 订单表"的超级用户）——一、桶内失衡：热键对应桶的链极长（hash 表退化：探测热键时"桶内线性匹配"（该桶存了海量小表行）——匹配复杂度从 O(1) 退化为 O(桶内行数)；二、内存 spill：hash 表超过 work_mem 时溢写磁盘（partition spill）——溢出的桶"逐批读回"（随机 IO、重复扫描）——倾斜时"热分区"反复 spill（性能灾难：秒级→分钟级）；三、并行退化：倾斜键使并行 worker 的"探测结果"全部涌向一个 worker（reduce 侧倾斜——并行 join 的单 worker 瓶颈）。缓解：倾斜值识别（统计/MCV 把热键单独处理：热键走"广播小表+直接匹配"或"分离-合并"策略）、增大 work_mem、hash 表分桶参数）。

bloom filter 优化（join/聚合的探测前过滤）：构建方（build 侧）对小表的 join 键集合建 bloom filter（位图，可能经运行时传递（如 PG 无内建 join bloom，但 bitmap index scan 与部分引擎（Spark/Parquet 的动态裁剪）用；PG 的 bitmap 是"位图索引扫描"——两类不同：bitmap index scan 是"索引位图合并"、bloom 过滤是"数据跳过"）——此处按"bloom 过滤/动态裁剪"理解）：探测侧在"读取/探测"前用 bloom 判断"该行 join 键是否可能匹配"——不匹配直接跳过（省探测与 IO）。何时反而拖慢：一、构建与检查开销——bloom 构建（哈希小表所有键）、每行检查（多次哈希+位访问）：小表/小结果集时开销占比高（过滤收益小）；二、选择性——若大部分行都匹配（bloom 全命中），过滤无收益（白付检查费）；三、IO 非瓶颈——数据全在内存/缓存（CPU 密集查询）："省 IO"的收益不存在，bloom 检查纯开销；四、错误率与热键——bloom 的假阳性使"不匹配行"仍被探测（过滤不完全）；倾斜场景热键必命中（bloom 对热键无用），冷键的过滤收益又小；五、构建方成本转移——动态 bloom（运行时构建）把"构建成本"加在查询关键路径。工程判断：bloom/bitmap 过滤的收益 =（被过滤行数 × 单行探测/IO 成本）−（构建+检查开销）——数据量大、IO 昂贵、选择性好（匹配率低）时收益正；小表、内存命中、高匹配率时收益为负。实践：测试开关对比（PG 的 enable_bitmapscan 等开关、Spark 的 runtime filter 开关）、EXPLAIN ANALYZE 看实际过滤行数；倾斜场景先治理热键（MCV 分离）再谈过滤。结论：hash join 倾斜=桶退化与 spill；bloom 过滤是"用 CPU 换 IO"的优化——IO 不贵或过滤无效时反而拖慢。

以"热键桶长链+spill"讲 hash join 倾斜退化，再以"过滤收益=省下的 IO−构建/检查开销"的算账逻辑解释 bloom 过滤何时有害。

• RAID6：双奇偶——利用率 (N-2)/N、容错 2、随机写 RMW 更重（双校验）
• RAID10（1+0）：镜像条带——利用率 50%、容错"每组镜像坏 1 块"（最多每镜像对 1 块）、随机写代价 2（写两镜像）但无 RMW——随机写性能最优
• 场景：数据库（随机写多、延迟敏感、容忍度要求）→ RAID10（随机写快、可用性高）；归档（顺序写、容量优先、容错 2）→ RAID6

RAID 级别对比（N 块盘）：一、RAID0（条带）：数据分块跨盘——利用率 100%、无冗余（任一盘坏=全丢）、写代价 1（每写一次）；只适合"临时/可重建数据"。二、RAID1（镜像）：每数据两份——利用率 50%、容错 1（单盘阵列可容忍 N-1 盘坏但阵列最小 2 盘；一般表述"容忍 1 块（每组镜像）"）、写代价 2（写两份）、读可并行。三、RAID5（单奇偶）：条带+校验——利用率 (N-1)/N、容错 1、随机写需"读-改-写（RMW）"：更新一个数据块=读旧数据块+读旧校验块→计算新校验→写数据块+写校验块（2 读+2 写，IO 放大 4 次）——随机小写代价大（写放大 2× 于 RAID10？数据+校验两次写+两次读）；顺序写可用"全条带写（full stripe write）"免 RMW。四、RAID6（双奇偶）：利用率 (N-2)/N、容错 2（同时坏 2 块可重建）、随机写 RMW 更重（双校验：读旧数据+两旧校验→写数据+两校验）。五、RAID10（RAID1+0：先镜像后条带）：利用率 50%、容错"每个镜像对中可坏 1 块"（最多坏 N/2 块、但同一镜像对不能坏 2 块）、随机写代价 2（写两份镜像）——无 RMW（镜像写不需读旧值），随机写性能最佳（与 RAID1 相当、优于 RAID5/6）。

场景选型：一、数据库（MySQL/PostgreSQL/Oracle 的典型部署）选 RAID10 的理由：a) 随机写密集（事务日志、索引更新、脏页写回）——RAID5/6 的 RMW 写放大（4 次 IO）在随机写下灾难（写吞吐大幅下降、延迟抖动）；RAID10 每写只写两份（无读-改-写）；b) 延迟敏感（事务提交等待 fsync）——RAID10 的写延迟可预测（镜像写并行）；c) 故障恢复时间（重建）：RAID5/6 重建需全盘重算校验（重建时间长、期间再故障风险高），RAID10 重建=复制镜像（快）；d) 容错：数据库通常接受"单镜像对故障"（RAID10）或双故障（RAID6 更稳但写代价高）——成本与性能平衡选 RAID10。二、大容量归档（备份、对象存储、冷数据）选 RAID6 的理由：a) 容量效率（(N-2)/N vs 50%）——大容量场景 50% 浪费不可接受；b) 顺序写为主（归档写入是顺序流）——RMW 代价小（全条带写免 RMW），写放大问题不显著；c) 容错 2（双盘故障仍可用）——大容量盘重建时间长（TB 级重建），双奇偶降低"重建期间二次故障"的丢失风险；d) 读多写少（归档读取为主）——读不受 RMW 影响。对比结论：随机写代价排序 RAID10(2 写) < RAID5(RMW 4IO) < RAID6(RMW 6IO)；利用率 RAID5 > RAID6 > RAID10；容错 RAID6(2) > RAID10(每对1) > RAID5(1)。工程注意：SSD 时代 RAID 的取舍变化（SSD 随机写快、RMW 代价降低，但 NAND 寿命受写放大影响——RAID5/6 的写放大伤寿命；部分系统用"软件 RAID（mdadm/ZFS）+缓存层"替代硬件 RAID 卡）；ZFS 的 RAIDZ（类 RAID5/6+COW 避免 RMW）与 btrfs RAID 是文件系统级替代；云盘（EBS gp3/io2 的多副本）的"RAID"由存储系统实现。

以"利用率/容错/随机写代价"三维对比五级别（重点讲 RMW 写放大与镜像写），再按"随机写+延迟敏感→RAID10、容量+顺序写+双容错→RAID6"给选型理由。