Each page has a certain inner layout that usually consists of the following parts:
page header
1 | test=# CREATE EXTENSION pageinspect; |
1 | /* |
1 | test=# drop table t; |
Reference:
【转】AntDB/PostgreSQL内部原理：表Page结构解析_postgresql对应antdb的版本-CSDN博客
iostat
1 | iostat -x 1 |
%util 高接近 100% → 磁盘基本饱和。await 高 → 每次 I/O 延迟大。r/s 和 w/s → 每秒读写次数，衡量吞吐能力。iotop
vmstat
1 | vmstat 1 |
bi/bo 字段表示每秒块设备读写量。wa 字段表示 CPU 等待 I/O 的百分比，高的话说明 I/O 成为 CPU 等待瓶颈。dstat / perf stat
测试磁盘最大写入带宽：
1 | dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct |
oflag=direct 避免缓存干扰。同理，可以测试并发读写：
1 | fio --name=randrw --rw=randrw --bs=4k --size=1G --numjobs=10 --runtime=60 --group_reporting |
fio 可以模拟多线程读写负载，测出 IOPS 和吞吐量。CPU vs I/O 时间：
top 或 perf top 中如果 CPU 很空闲，程序主要在等待 I/O → I/O 瓶颈。延迟累积：
锁与等待：
perf trace 或 blktrace 排查。安装apache：
1 | sudo apt update |
安装php
1 | yum install -y php php-mysql php-json |
1 | sudo apt install php libapache2-mod-php php-mysql -y |
安装database
1 | sudo yum install -y mariadb-server |
1 | apt install mysql-server -y |
修改密码：
1 | ALTER USER 'root'@'localhost' IDENTIFIED BY '12345'； |
安装wordpress
1 | cd /var/www/html |
编辑 Apache 默认虚拟主机配置
1 | sudo nano /etc/apache2/sites-available/000-default.conf |
找到：
DocumentRoot /var/www/html
改成：
DocumentRoot /var/www/html/wordpress
/etc/apache2/apache2.conf 添加：
1 | <Directory /var/www/html/wordpress> |
如果你希望支持 WordPress 的 .htaccess 功能，请保留 AllowOverride All
固定连接
1 | apache2ctl -M | grep rewrite |
在 WordPress 后台重新保存固定链接
重启服务
1 | systemctl restart apache2 |
从wal逻辑结构来看，WAL 可被描述为变长日志条目流。每个条目都包含有关特定操作的一些数据，并以标准标头作为前缀。该标头提供的信息包括但不限于：
WAL 通常是按正向读取的，但某些工具（例如 pg_rewind）可能会反向扫描它
WAL 数据本身可以具有不同的格式和含义。例如，它可能是一段页片段（page fragment），需要替换某个页面中指定偏移处的一部分内容。相应的资源管理器（resource manager）必须知道如何解析并重放这一特定条目。针对表、各种索引类型、事务状态以及其他实体，PostgreSQL 都有独立的资源管理器来处理它们各自的 WAL。
WAL 文件会占用服务器共享内存中的特殊缓冲区。用于 WAL 的缓存大小由参数 wal_buffers 决定。默认情况下，这个大小会自动设为总缓冲区缓存（buffer cache）大小的 1/32。
WAL 缓存与缓冲区缓存（buffer cache）非常相似，但它通常以环形缓冲区（ring buffer）的方式运行：新的日志条目被添加到缓冲区的头部，而旧的条目则从尾部开始写入磁盘。如果 WAL 缓存太小，就会比必要的更频繁地进行磁盘同步操作。
在系统负载较低的情况下，插入位置（即缓冲区的头部）几乎总是与已经写入磁盘的条目位置（即缓冲区的尾部）保持一致。
1 | demo=# SELECT pg_current_wal_lsn(), pg_current_wal_insert_lsn(); |
在PostgreSQL 10之前，所有函数名称都包含XLOG首字母缩写词，而不是WAL。
为了引用某个特定的日志条目，PostgreSQL 使用一种特殊的数据类型：pg_lsn（日志序列号，Log Sequence Number，简称 LSN）。它表示从 WAL 起始位置开始，以字节为单位的 64 位偏移量。LSN 通常以两个十六进制数字表示，中间用斜杠（/）分隔。
我们创建一个表：
1 | demo=# CREATE TABLE wal(id integer); |
现在执行一个任意命令，例如，更新一行数据。
1 | demo=*# UPDATE wal SET id = id + 1; |
页面的修改是在 RAM 中的缓冲区缓存（buffer cache）中进行的。这个更改也会记录在位于 RAM 中的 WAL 页面中。因此，插入的 LSN 会向前推进。
1 | demo=*# SELECT pg_current_wal_insert_lsn(); |
为了确保修改后的数据页是在对应的 WAL 条目之后才被刷新到磁盘，数据页的页头会存储该页最新相关的 WAL 条目的 LSN。你可以使用 pageinspect 插件查看这个 LSN。
1 | demo=*# SELECT lsn FROM page_header(get_raw_page('wal',0)); |
整个数据库集群只有一个 WAL，并且新的条目会不断地追加到其中。因此，存储在数据页中的 LSN 可能会比 之前某个时刻 pg_current_wal_insert_lsn() 返回的 LSN 更小。但如果系统中没有发生任何操作，这两个数值将会相同。
现在提交这个事务
1 | demo=*# commit; |
为了确保某个 CLog 页在对应的 WAL 条目写入磁盘之前不会被刷新到磁盘，必须追踪该页所对应的最新 WAL 条目的 LSN。但这种 LSN 信息是保存在内存（RAM）中的，而不是存在 CLog 页本身
某个时刻，WAL 日志条目会被写入磁盘；此时，才能把对应的 CLOG 和数据页从缓存中淘汰（evict）。如果必须更早淘汰这些缓存页，那么系统会发现这一点，并会先强制将对应的 WAL 条目写入磁盘。
如果你知道两个 LSN（日志序列号）的位置，就可以通过简单地相减计算这两者之间的 WAL 日志大小（以字节为单位）。只需将它们转换为 pg_lsn 类型即可进行减法运算
1 | demo=# demo=# SELECT '1/EBDDC500'::pg_lsn - '1/EBDDA4F8'::pg_lsn; |
在这个具体案例中，更新（update）和提交（commit）操作相关的 WAL 条目大约占用了几千字节。可以用相同的方法，估算某个工作负载在单位时间内产生的 WAL 日志量。
这些信息对设置检查点（checkpoint）参数非常重要。
在磁盘上，WAL 被存储在 PGDATA/pg_wal 目录中，以单独的文件（或称为段）的形式存在。它们的大小由只读参数 wal_segment_size 指示。
对于高负载系统，增加段大小可能是有意义的，因为这可以减少开销。但这个设置只能在集群初始化时修改（通过 initdb –wal-segsize）。
WAL 记录会写入当前文件，直到该文件空间耗尽；此时 PostgreSQL 会开始写入一个新文件。
我们可以确定某条记录位于哪个文件中，以及它在该文件起始位置的偏移量。
1 | demo=# SELECT file_name, upper(to_hex(file_offset)) file_offset FROM pg_walfile_name_offset('1/EBDDC500'); |
该文件的名称由两部分组成。最高的八位十六进制数字（4个字节）表示用于从备份中恢复的时间线（timeline），而其余部分（8个字节）表示 LSN（日志序列号）的高位比特（LSN 的低位比特则体现在 file_offset 字段中）。
要查看当前的 WAL 文件，可以调用以下函数：
1 | demo=# SELECT * |
现在让我们使用 pg_waldump 工具查看新创建的 WAL 记录的头部信息。该工具既可以按 LSN 范围（就像这个例子中那样）过滤 WAL 记录，也可以按特定的事务 ID 过滤。
pg_waldump 工具应以 postgres 用户身份运行，因为它需要访问磁盘上的 WAL 文件。
1 | postgres@lavm-bar1guved6:/root$ pg_waldump -p /usr/local/pgsql/data/pg_wal -s 1/EBDDA4F8 -e 1/EBDDC500 |
1 | rmgr: XLOG len (rec/tot): 49/109, tx: 0, lsn: 1/EBDDA4F8, prev 1/EBDDA4C0, desc: FPI_FOR_HINT , blkref #0: rel 1663/32814/376833 blk 0 FPW |
1 | rmgr: Heap len (rec/tot): 69/69, tx: 961, lsn: 1/EBDDA568, prev 1/EBDDA4F8, desc: HOT_UPDATE old_xmax: 961, old_off: 1, old_infobits: [], flags: 0x40, new_xmax: 0, new_off: 2, blkref #0: rel 1663/32814/376833 blk 0 |
1 | rmgr: Standby len (rec/tot): 54/54, tx: 0, lsn: 1/EBDDA5B0, prev 1/EBDDA568, desc: RUNNING_XACTS nextXid 962 latestCompletedXid 960 oldestRunningXid 961; 1 xacts: 961 |
1 | rmgr: XLOG len (rec/tot): 49/7777, tx: 961, lsn: 1/EBDDA5E8, prev 1/EBDDA5B0, desc: FPI_FOR_HINT , blkref #0: rel 1663/32814/2691 blk 19 FPW |
RUNNING_XACTS（再次记录活跃事务）
1 | rmgr: Standby len (rec/tot): 54/54, tx: 0, lsn: 1/EBDDC468, prev 1/EBDDA5E8, desc: RUNNING_XACTS nextXid 962 latestCompletedXid 960 oldestRunningXid 961; 1 xacts: 961 |
和之前类似，再次记录活跃事务 961。
COMMIT（事务提交）
1 | rmgr: Transaction len (rec/tot): 34/34, tx: 961, lsn: 1/EBDDC4A0, prev 1/EBDDC468, desc: COMMIT 2025-07-28 16:04:55.325979 CST |
1 | rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: 1/EBDDC4C8, prev 1/EBDDC4A0, desc: RUNNING_XACTS nextXid 962 latestCompletedXid 961 oldestRunningXid 962 |
查看日志文件路径
1 | demo=# SELECT pg_relation_filepath('wal'); |
存储引擎之所以能够快速定位数据，离不开索引。B树索引是历经考验、使用最广泛的一种索引结构。pg中的B树索引是为ordinal data types（可以比较和排序）设计的。
每一个节点就是一个页（Page）。page的大小定义决定了索引node的容量；每个节点（node）由多个element组成（element包括 索引key 和 一个指针）。内部节点中的元素指向下一层的节点；叶子节点中的元素则指向堆中的元组。这种结构就是 PostgreSQL 中 B-Tree 索引的基础：内部节点用于导航，叶子节点保存指向真实数据的引用。
一个索引文件，存储多列键值组合：索引条目（index tuple）中存储这几列的值作为一个组合键。
多列索引的比较是逐列进行的，先比较第1列 a，如果相等，再比较第2列 b，依次类推。pg使用逐字段比较器（每列使用其数据类型对应的 < 运算符）逐列比较
默认情况下，索引值是按照升序（ASC）排列的，但如果需要，你也可以指定为降序（DESC）。如果索引是基于单列创建的，排序顺序通常无所谓，因为扫描可以沿任意方向进行。但在多列索引中，排序顺序就变得很重要了。
PostgreSQL 多列索引中，当你只指定了“非第一列”的查询条件时，理论上有一种优化方法叫做 Skip Scan:
例如：
1 | CREATE INDEX idx_ab ON mytable(a, b); |
这个时候由于 没有给出 a 的值，PostgreSQL 的 B-tree 无法用这个索引来直接查找。
但是，理论上如果第一列（a）的取值不多，比如只有 v1, v2, …, vn，查询可以被改写为多次扫描：
1 | SELECT * FROM mytable WHERE a = v1 AND b = 42; |
每次都能利用索引 (a, b) 的“最左前缀”性质进行查找，然后再合并结果。这就是 Skip Scan 的思路。
PostgreSQL 当前 不支持 Skip Scan
B-tree 索引还可以通过 INCLUDE 子句扩展额外的列，这些列不参与查找，但可以包含在索引中。
1 | CREATE INDEX idx_ab_inc ON t(a, b) INCLUDE (c, d); |
这样可以使某些 SELECT 查询满足 Index-Only Scan（覆盖索引），避免回表. 类似于mysql 的聚族索引（和聚族索引不同的是：include属于冗余存储）
1 | SELECT p.name, |
clusterable 表示索引是否支持用于 CLUSTER 操作。
CLUSTER 命令会按照指定的索引顺序，对表中的数据行进行物理重排，让表的数据页顺序与索引顺序一致。
这样可以提高基于该索引的扫描性能，因为数据的物理顺序和索引顺序相同，减少随机 I/O。
1 | CLUSTER my_table USING my_index; |
索引是否支持普通的 Index Scan（例如 WHERE id = 123）
Bitmap Scan 是 PostgreSQL 查询计划中的一种索引访问方法，主要用于当多个条件组合过滤时，或者单个索引扫描返回大量行时，提高访问效率的技术。
它分两步完成：
即索引扫描支持双向遍历：可以从索引的左端（最小键）开始向右扫描，也可以从索引的右端（最大键）开始向左扫描。例如 ORDER BY id DESC 时利用该索引
索引可能会随着插入和删除不断膨胀，而不会自然收缩，需要通过重建或 REINDEX 来处理。
postgres internals 14
pgbench is a benchmarking tool bundled with PostgreSQL, designed to simulate a TPC-B-like workload, not a full TPC-C
This sets up the schema and populates data.
1 | pgbench -i -s 10 mydb |
1 | pgbench -c 10 -j 2 -T 60 mydb |
It will output something like:
1 | [postgres@iZ2ze4mflpfiplp0evcw8gZ root]$ pgbench -c 10 -j 2 -T 60 mydb |
You can benchmark with custom SQL transactions:
1 | pgbench -f myscript.sql -c 10 -T 60 mydb |
Where myscript.sql contains something like:
1 | BEGIN; |
Use :variable for substitution. We can define variables using -D:
1 | pgbench -f myscript.sql -D aid=12345 -D delta=50 -c 10 -T 60 mydb |
之前学习过各种异象，总是记乱，整理成文档备份
为了更好理解相关异象，做如下数据准备：
1 | CREATE TABLE accounts( |
当两个事务读取同一表行，然后其中一个事务更新该行，最后另一个事务更新同一行而不考虑第一个事务所做的任何更改时，就会发生丢失更新异常。
当一个事务读到了其他事务尚未尚未提交的更改时，就会发生脏读异常
当同一个事务执行两个相同的查询返回一组满足特定条件的行，而另一个事务添加一些满足该条件的其他行并在这些查询之间的时间间隔内提交更改时，就会发生幻读异常。
概念： 读到一部分老数据，又读到一部分新数据。
假设我们要在bob的账户之间转账
Transaction1
1 | woodhead=# BEGIN; |
与此同时，另一个事务2 开始循环bob的账户计算bob的账户结余（金额）
Transaction2
1 | woodhead=# BEGIN; |
这个时候，事务1提交成功：
1 | woodhead=*# UPDATE accounts SET amount = amount + 100 WHERE id = 3; |
事务2 开始读取第二个账户（读已提交的隔离状态下会读取到已提交的数据）
1 | woodhead=*# SELECT amount FROM accounts WHERE id = 3; |
最终结果：事务2读取到了1100块钱，因为它读到了不正确的数据，这种异常叫做读偏序
概念： 基于同一份旧数据做决策，但修改了不同的数据。更精确：两个事务读到同一个快照，各自认为自己的修改是安全的，但合在一起破坏了约束。
我们定义如下一致性规则：只要总余额非负，就允许客户的部分账户出现负余额。
事务1获取总额
1 | woodhead=# select * from accounts; |
事务2同样获取总额
1 | woodhead=# BEGIN ISOLATION LEVEL REPEATABLE READ; |
第一个事务合理地假设，它可以从某个账户扣除 600 元。
1 | woodhead=*# UPDATE accounts SET amount = amount - 600.00 WHERE id = 2; |
第二个事务得到同样的结论，但是从另一个账户扣除：
1 | woodhead=*# UPDATE accounts SET amount = amount - 600.00 WHERE id = 3; |
事务1也提交，然后查询：
1 | woodhead=*# commit; |
现在bob的总余额是负的，虽然每个事务单独运行都是正确的。这种异常叫写偏序
要在发生故障后恢复数据一致性（即执行恢复操作），PostgreSQL 需要向前回放 WAL 日志，并将其中表示丢失变更的记录应用到相应的数据页上。为了确定哪些变更丢失了，系统会将磁盘上数据页的 LSN（日志序列号）与 WAL 记录的 LSN 进行比较。但问题是，我们应该从哪里开始恢复？如果恢复起点选得太晚，那么在此之前已经写入磁盘的数据页将无法接收到所有应有的变更，最终导致无法修复的数据损坏。而从日志的起始位置开始恢复又不现实：不仅无法长期保存如此巨量的数据，也无法接受过长的恢复时间。因此，我们需要一个不断向前推进的检查点（checkpoint），从而可以从这个位置安全地开始恢复，同时删除所有更早的 WAL 记录。
创建检查点最直接的方式是：定期暂停系统所有操作，并将所有脏页强制刷新到磁盘。但这种方式显然是不可接受的，因为系统会因此暂停不定但相当长的时间。
正因为如此，PostgreSQL 将检查点的过程分摊到一段时间内完成，实际上构成了一个“区间”（interval）。检查点的执行是由一个特殊的后台进程负责的，这个进程叫做 checkpointer（检查点进程）
checkpointer 进程会将所有可以立即写入磁盘的内容进行刷新，包括：
检查点执行的大部分时间都耗费在将 脏页（dirty pages）刷新到磁盘上。
首先，在检查点开始时，所有当时处于“脏”状态的缓冲区（buffer）的页头会被打上一个特殊标记（tag）。这个过程非常迅速，因为它不涉及任何 I/O 操作，只是内存中的标记设置。
随后，checkpointer 会遍历所有缓冲区，并将带有该标记的页写入磁盘。这些页不会被驱逐出缓存（即它们仍然保留在缓冲池中），只是被刷盘，因此在这个过程中可以忽略使用计数（usage count）和 pin 计数（pin count）。
页面按 ID 顺序处理，以尽可能避免随机写入。为实现更好的负载均衡，PostgreSQL 会在多个表空间之间交替进行写入（因为它们可能位于不同的物理设备上）。
后端进程（backend）也可以将打了标记的缓冲页写入磁盘 —— 如果它们先访问到了这些页的话。无论由谁写入，缓冲区的标记都会在这个阶段被清除，因此每个缓冲页在此次检查点中只会被写一次。
很自然地，在 checkpoint 进行期间，缓冲区中的页面仍然可能被修改。但由于这些新的脏页没有被打上标记，checkpointer 会忽略它们。
当在检查点开始时被标记为脏的所有缓冲页都已经写入磁盘后，检查点就被视为完成。从现在起（但不是在此之前！），本次检查点的起始位置将被作为恢复操作的新起点。在这个点之前写入的所有 WAL 日志都不再需要了。
1 | Time → |
最后，checkpointer 进程会创建一条表示检查点完成的 WAL 记录，并在其中标明此次检查点的起始 LSN。由于检查点在开始时不会写入任何日志，因此这个起始 LSN 可以是任意类型的 WAL 记录所属的 LSN。
此外，PGDATA/global/pg_control 文件也会被更新，以指向最近完成的检查点。（在此过程完成之前，pg_control 始终保留着上一个检查点的信息。）
Example：
1 | => UPDATE big SET s = 'FOO'; |
最新的 WAL 条目与检查点完成有关（CHECKPOINT_ONLINE）。该检查点的起始 LSN 出现在 redo 之后；这个位置对应的是检查点开始时最新插入的 WAL 条目。
同样的信息也可以在 pg_control 文件中找到。
1 | postgres$ /usr/local/pgsql/bin/pg_controldata \ |