DBA

第六期：并发控制（下）—— 死锁检测、分析与消除 1. 死锁的定义与必要条件 死锁：两个或多个事务各自持有对方需要的资源，且都不释放，导致永久阻塞。 四个必要条件（全部满足才会死锁）： | 条件 | 说明 | 示例 | |——|——|——| | 互斥 | 资源一次只能被一个事务持有 | 排他锁（X）同时只能一个事务持有

第五期：并发控制（上）—— 隔离级别、锁与锁升级 1. 并发问题与隔离级别 三种常见并发问题： | 问题 | 定义 | 示例 | |——|——|——| | 脏读 | 读到未提交事务的修改 | 事务A修改了行R未提交，事务B读到修改后的值，A回滚 |

第四期：堆、聚集索引与非聚集索引 —— 物理存储与访问路径 1. 基础回顾：页（Page）与区（Extent） 页（8KB）：SQL Server 中最小的 I/O 单元。每页包含 96 字节的页头（对象ID、分区ID、下一页指针等）+ 实际数据行。 区（64KB）：8 个物理连续页的组。混合区（存放多个对象的页）和统一区（只属于一个对象）。 IAM（Index Allocation Map）页：记录表或索引使用了哪些区，用于扫描整个对象。 2. 堆（Heap）——

第三期：事务日志、WAL 与崩溃恢复 —— 如何保证断电也不丢数据？ 1. 事务日志的物理结构：不只是“一个文件” 每个数据库至少有一个日志文件（.ldf），内部被划分为 VLF（Virtual Log File） 逻辑单元： VLF 数量由日志文件大小和自动增长参数决定（过多 VLF 会影响性能）。 LSN（Log Sequence Number）：每个日志记录的单调递增编号，用于定位和恢复。 日志记录内容：事务开始/结束、每次数据修改（Before/After 或操作描述）、页分配、DDL

第二期：缓冲池与内存架构 —— 为什么缓存命中率决定性能？ 1. 内存整体视图：SQL Server 如何使用操作系统内存？ SQL Server 实例启动后，会向操作系统申请一块内存（Min Server Memory ~ Max Server Memory），主要由以下部分组成： 内存区域 作用 是否可释放 缓冲池（Buffer

第一期：SQL Server 基础架构与核心组件 1. 实例（Instance）—— SQL Server 的“进程容器” 定义：一个独立的 SQL Server 服务进程（sqlservr.exe），包含自己的一套系统数据库、用户数据库、配置和端口。 关键点： 一台机器可以装多个实例（默认实例 + 命名实例），彼此隔离，通过不同端口（默认 1433）区分。 每个实例有自己的内存、线程、调度器，但共享操作系统资源。 现象解释：为什么重启实例能清空某些缓存？因为实例重启会释放所有内存区域（如缓冲池、计划缓存）。 2.

DBA晨报·第30期｜Google Cloud数据库Agent化、Oracle CPU修复481漏洞、PG 19异步I/O增强+国产淘汰赛开启 为你摘取技术圈值得关注的3件事。今天是2026年4月25日，星期六。 01 云数据库｜Google Cloud数据库全面Agent化：Spanner Omni发布，AI原生架构重塑数据库角色 在近日举行的Google Cloud Next 2026大会上，Google Cloud正式发布了Agentic Data Cloud战略，标志着其数据库产品线全面向AI Agent时代转型。 核心战略：从“数据存储”到“智能上下文引擎” Google Cloud工程副总裁Sailesh

PostgreSQL安全权限体系详解（第五期）：三大实战场景综合安全方案 引言 跨越前四期，我们从角色权限的奠基、加密传输与强认证的边界守卫，到行级隔离（RLS）的数据围栏，再到审计与加密存储的可追溯动态保护，逐层构建了PostgreSQL的安全护城河。本期作为系列收官之作，以三个真实的生产场景为蓝图，进行安全体系的“大阅兵”，完成从理论到实战的最后一跃。 系列回廊： 期数 主题 核心能力 第一期 角色与权限体系 建立最小权限模型 第二期 加密传输与强认证 杜绝传输窃听、强化连接验证 第三期 行级安全与多租户隔离 实现行级数据隔离 第四期 审计、备份加密与TDE 满足合规审计、保障存储安全 第五期（本期）

PostgreSQL安全权限体系详解（第四期）：审计、备份加密与透明数据加密 引言 在前三期文章中，我们系统构建了从角色权限到加密传输与强认证再到行级安全与多租户隔离的安全防线。至此，我们已经能够较好地解决“谁能访问”“数据在路上是否安全”“租户之间是否隔离”三个核心问题。 然而，安全体系的终点从来不只是“防得住”，还有另外两个同等重要的维度被人熟知——“可追溯”与“静态保护”。前者要求数据的所有访问行为都有完整记录以备审查；后者要求数据在“静止”时（存储在磁盘、备份文件中）即使被物理窃取也无法被读取。这两者共同构成了“动态防护+静态保护+事后审计”的全方位安全闭环。 本期作为系列第四期，将聚焦这三个核心主题： 审计日志：借助pgAudit扩展实现合规级审计能力，覆盖金融、政务等场景的等保与GDPR合规要求 备份加密：保护备份数据免受物理窃取或云端泄露的威胁——PG_BACKREST AES-256加密、云存储加密、pg_dump管道加密等方案的完整实践 透明数据加密：这一主题将展开详细的原生TDE对比表格，完整解读pg_tde扩展、LUKS磁盘加密与驱动级TDE，并给出不同安全需求层次的选型建议 三者之间不是割裂的。一个成熟的生产级安全体系，这三者缺一不可。 系列回顾与预告： 第一期：角色与权限体系、最小权限原则 ✅ 第二期：加密传输、强认证体系 ✅ 第三期：行级安全与多租户隔离 ✅ 第四期（本期） ：审计日志、备份加密与透明数据加密 第五期：综合场景实战（多租户SaaS、金融系统、企业内网完整安全方案）

PostgreSQL安全权限体系详解（第三期）：行级安全深度实践与多租户数据隔离 引言 在系列前两期中，我们分别建立了基础的角色权限体系和加密传输与强认证体系。这两者构筑了数据库安全的“外围防线”——谁来连接、用什么身份连接、数据在路上是否安全。然而，这两层防线解决的是“谁能进大门”的问题，一旦用户获得合法的数据库连接，就能看到该表或该模式下的全部数据。 问题在于：在多租户系统中，租户A的销售人员应当只能看到租户A的客户数据，绝对不能看到租户B的客户数据。传统的做法是“每个查询都加上 WHERE tenant_id = ?”——但这条规则的高度重复性决定了它极其容易被疏忽。只要有一个查询遗漏了这个条件，数据隔离就会瞬间崩塌。 这正是行级安全（Row Level Security, RLS） 登场的场景。RLS将数据隔离从“开发者凭良心遵守的约定”变成了“数据库强制执行的安全约束”。本文将从实战角度系统讲解RLS的实现、性能优化与常见陷阱，帮助读者构建坚实的数据隔离防线。 系列回顾与预告： 第一期：角色与权限体系、最小权限原则 ✅ 第二三期：加密传输、强认证体系、行级安全与多租户隔离 ✅ 第四期：审计日志（pgAudit）、备份加密、透明数据加密（TDE） 第五期：综合场景实战（多租户SaaS、金融系统、企业内网完整安全方案）