数据库 on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

Sat, 01 Aug 2026 00:00:00 +0800

PostgreSQL 使用 MVCC 让读写尽量互不阻塞，但它也带来一个容易被忽略的代价：UPDATE 和 DELETE 不会立刻从物理文件中移除旧版本。旧元组只有在不再可能被任何事务看到后，才能由 VACUUM 清理并把空间标记为可复用。

Autovacuum 不是“可有可无的后台整理器”，而是 PostgreSQL 稳定运行的基础设施。它同时承担回收死元组、更新优化器统计信息、维护可见性映射以及防止事务 ID 回卷等工作。本文从触发公式、监控 SQL和调优方法三个角度，解释如何避免表膨胀与查询性能逐步恶化。

一、为什么会产生死元组

假设执行：

UPDATE orders SET status = 'paid' WHERE id = 1001;

PostgreSQL 通常不会在原位置覆盖旧行，而是创建新版本，并让旧版本在满足可见性条件前继续存在。这样，较早开始的事务仍可读取它应该看到的快照。

当旧版本不再对任何事务可见时，它就成为 dead tuple。若清理速度长期低于写入速度，会出现：

表和索引占用空间持续增加；
顺序扫描需要读取更多数据页；
缓存命中效率下降，磁盘 I/O 增加；
优化器统计信息过旧，可能选择错误执行计划；
维护操作耗时越来越长。

需要注意：普通 VACUUM 主要把空间交还给表内部复用，通常不会立即缩小操作系统看到的文件。VACUUM FULL 会重写整张表并归还空间，但需要额外磁盘空间和排他锁，因此不适合作为日常维护手段。

二、Autovacuum 的触发公式

对更新和删除产生的死元组，触发阈值可近似理解为：

vacuum 触发数 = autovacuum_vacuum_threshold
 + autovacuum_vacuum_scale_factor × 表估算行数

PostgreSQL 18 的默认值为：

autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2

一张估算为 1000 万行的表，默认需要约 200 万个更新或删除元组才触发一次 vacuum：

50 + 0.2 × 10,000,000 = 2,000,050

这对小表通常没问题，但对高频更新的大表可能过于宽松。分析统计信息的触发方式类似：

analyze 触发数 = autovacuum_analyze_threshold
 + autovacuum_analyze_scale_factor × 表估算行数

默认 autovacuum_analyze_threshold 为 50，autovacuum_analyze_scale_factor 为 0.1。

三、先监控，再调参数

1. 找出死元组较多的表

SELECT
 schemaname,
 relname,
 n_live_tup,
 n_dead_tup,
 round(
 100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0),
 2
 ) AS dead_pct,
 last_autovacuum,
 last_autoanalyze,
 autovacuum_count,
 autoanalyze_count
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

不要只盯着 dead_pct：百万行大表的 5% 可能已经很多，而几十行小表的 50% 通常影响有限。应同时观察绝对数量、增长速度、表尺寸和业务延迟。

2. 查看表与索引大小

SELECT
 n.nspname AS schema_name,
 c.relname AS table_name,
 pg_size_pretty(pg_table_size(c.oid)) AS table_size,
 pg_size_pretty(pg_indexes_size(c.oid)) AS indexes_size,
 pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
 AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 20;

pg_stat_user_tables 中的元组数是统计估算，不是严格实时计数。累计统计可能有短暂延迟，而且默认在同一事务中读取时会缓存到事务结束，因此排障时应避免在长事务里反复查询后误判数据没有变化。

3. 检查 Autovacuum 是否正在工作

SELECT
 pid,
 datname,
 relid::regclass AS table_name,
 phase,
 heap_blks_total,
 heap_blks_scanned,
 heap_blks_vacuumed,
 index_vacuum_count
FROM pg_stat_progress_vacuum;

同时检查全局配置：

SHOW autovacuum;
SHOW track_counts;
SHOW autovacuum_max_workers;
SHOW autovacuum_naptime;
SHOW autovacuum_vacuum_cost_delay;
SHOW autovacuum_vacuum_cost_limit;

四、针对热点大表做局部调优

相比一开始就修改全局配置，更稳妥的方式是为写入最频繁的表设置存储参数：

ALTER TABLE orders SET (
 autovacuum_vacuum_scale_factor = 0.02,
 autovacuum_vacuum_threshold = 1000,
 autovacuum_analyze_scale_factor = 0.02,
 autovacuum_analyze_threshold = 1000
);

若 orders 有 1000 万行，新的 vacuum 触发值约为：

1000 + 0.02 × 10,000,000 = 201,000

这比默认约 200 万行更及时，同时不会让所有表都采用同样激进的策略。调整后至少持续观察一个完整业务周期：

n_dead_tup 是否形成可控波动而非持续上升；
autovacuum 的执行次数与单次持续时间；
数据盘 IOPS、吞吐和延迟；
SQL 的 P95/P99 延迟；
表和索引尺寸是否趋于稳定。

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

只要某个老快照仍可能看见旧版本，VACUUM 就不能安全移除它。可先排查长时间未结束的事务：

SELECT
 pid,
 usename,
 state,
 xact_start,
 now() - xact_start AS xact_age,
 wait_event_type,
 wait_event,
 left(query, 120) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

应用连接池中的 idle in transaction、未提交的批处理、长期保持的报表事务，都是常见根因。此时继续降低 scale factor，只会让 vacuum 更频繁地尝试，却未必能回收空间。

2. 清理能力跟不上写入速度

Autovacuum 使用基于成本的延迟机制来降低后台维护对前台业务的 I/O 冲击。如果多张大表同时高频更新，worker 数量、成本限额或磁盘能力可能成为瓶颈。

调优顺序建议是：

先解决长事务和异常写入；
针对热点表降低触发阈值；
确认磁盘有余量后，再评估 worker 数量和成本参数；
每次只改一组参数，并保留前后监控数据。

不要只为“让 vacuum 尽快结束”就无限提高成本限额，否则维护 I/O 可能直接影响在线查询。

3. 误把内部可复用空间当成故障

普通 VACUUM 后文件不缩小，并不表示它没有工作。若表仍会持续写入，保留并复用这些空闲空间往往比频繁执行 VACUUM FULL 更合理。

只有在一次性大规模删除、确认未来不会很快重新增长，并且能够安排锁表维护窗口时，才考虑 VACUUM FULL、CLUSTER 或其他表重写方案。执行前必须预留接近表及索引重建所需的额外空间。

六、生产调优清单

保持 autovacuum 开启，不要把关闭它当成性能优化。
用 pg_stat_user_tables 建立死元组数量、比例和清理时间的趋势图。
优先为热点大表设置表级参数，避免粗暴修改全局阈值。
同时监控磁盘 I/O 和业务延迟，防止维护任务挤压前台负载。
排查长事务、复制槽和其他可能维持旧快照的因素。
将普通 VACUUM 作为日常机制，把表重写当作有维护窗口的例外操作。
定期检查事务 ID 年龄，不能只关注磁盘膨胀。

总结

Autovacuum 的本质不是“定时清垃圾”，而是根据表的变更规模动态触发的一组维护任务。真正有效的优化，不是简单把参数调得更激进，而是让触发频率、清理吞吐和业务写入速度达到平衡。

面对表膨胀时，应先回答三个问题：死元组为什么持续产生、为什么未被及时清理、普通 VACUUM 回收的空间是否已经被业务复用。把这些问题与长事务、I/O 能力和表级阈值结合起来分析，通常比直接执行 VACUUM FULL 更安全，也更接近根因。

参考资料

PostgreSQL WAL、检查点与崩溃恢复：原理、参数与工程实践

Fri, 31 Jul 2026 00:00:00 +0800

生产环境里，数据库“提交成功”并不等于数据页已经刷到表文件。PostgreSQL 用 Write-Ahead Logging（WAL，预写日志） 把变更先顺序写到日志，再异步回写堆/索引页；一旦进程或主机崩溃，就从最近检查点（checkpoint）开始 REDO 前滚，把还没落盘的变更重放回来。理解 WAL 与检查点，才能在“提交延迟、恢复时间、磁盘占用”之间做正确取舍，而不是盲目把 fsync 关掉。

问题背景：为什么不能每次提交都刷数据页？

一次事务可能修改很多表页。如果每次 COMMIT 都把相关数据页 fsync 到磁盘：

随机写成本高：小事务会在不同数据文件之间来回寻道。
吞吐难扩展：并发提交会互相争抢刷脏页。
恢复语义更复杂：缺少统一的“已持久化边界”。

WAL 的核心规则（官方表述）：对数据文件的修改，必须在描述该修改的 WAL 记录刷到永久存储之后才能写入数据页。遵循这条规则后，提交时只需保证相关 WAL 已落盘，崩溃时再用日志重做（roll-forward / REDO）尚未写入数据页的变更。

这带来两个工程收益：

提交路径偏顺序写：同步成本主要在 WAL 文件，而不是整页随机写。
支持在线备份与 PITR：归档 WAL + 基准备份，可回放到任意覆盖时间点。

核心原理：LSN、段文件、检查点与 REDO

1. LSN：日志里的“字节尺”

每条 WAL 记录写入后，插入位置用 Log Sequence Number（LSN） 描述，本质上是 WAL 中单调递增的字节偏移。PostgreSQL 用 pg_lsn 类型表示它，可用于比较两点之间产生了多少 WAL、衡量复制与恢复进度。

常用函数：

-- 当前 WAL 写位置
SELECT pg_current_wal_lsn();

-- 计算两个 LSN 之间的字节差（备份/复制场景常用）
SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0');

2. 段文件布局：`pg_wal` 里的 16MB 段

WAL 默认存放在数据目录下的 pg_wal/（历史版本曾叫 pg_xlog）。段文件通常 每段 16MB（initdb --wal-segsize 可改），段内再按页划分（常见 8kB）。文件名是递增编号，例如从 000000010000000000000001 起。

运维提示：

WAL 磁盘与主数据盘分离，有助于把顺序写与随机写解耦（可在停库后迁移 pg_wal 并用符号链接指回原路径）。
段文件在检查点之后、确认不再需要时会被 回收重命名 或删除；归档模式下必须先归档再回收。

3. 检查点：恢复的“安全锚点”

检查点是 WAL 序列中的一个保证点：该点之前的堆/索引变更，都已反映到数据文件并刷盘。检查点过程会：

把脏数据页写回磁盘；
在 WAL 中写入特殊的 checkpoint 记录；
把检查点位置写入 pg_control。

崩溃恢复时，服务器：

读 pg_control 找到最新检查点；
定位 checkpoint 记录中的 redo 起点；
从该 LSN 向前扫描 WAL 做 REDO。

因此：检查点越频繁，崩溃后需要重放的 WAL 通常越少，恢复更快；但刷脏页更勤，运行期 I/O 更重。

默认自动触发条件（二者先到为准）：

参数	含义	默认（官方文档）
`checkpoint_timeout`	两次自动检查点的最长时间间隔	5 分钟
`max_wal_size`	自动检查点期间 WAL 增长的软上限	1 GB
`checkpoint_completion_target`	检查点 I/O 在间隔内的目标完成比例	0.9
`min_wal_size`	低于该占用时优先回收复用段，而不是删除	80 MB

CHECKPOINT SQL 可强制立即检查点，但文档明确：不适合作为常规业务操作，一般留给维护窗口或排障。

4. 全页写（Full Page Writes）与页撕裂

默认 full_page_writes = on：检查点之后，某个数据页 第一次被修改 时，会把 整页内容 记入 WAL（FPI，full page image）。目的是防止崩溃时页只写了一半（torn page），仅靠“增量修改记录”无法正确还原。

代价是：检查点刚结束后的一段时间内 WAL 量会冲高。高负载系统常通过合理调大 max_wal_size / checkpoint_timeout，避免检查点过于密集导致 FPI 风暴。

提交耐久性：`synchronous_commit` 与 `fsync`

这是最容易踩坑的一组旋钮，必须分清 丢最近事务 与 数据库损坏 的差别。

`synchronous_commit`（可会话级调整）

控制：在向客户端返回“成功”前，WAL 需要处理到什么程度。合法值包括：

remote_apply、on（默认）、remote_write、local、off。

关键语义：

非 off 的本地行为：等待 本地 WAL 刷盘。
off（异步提交）：逻辑提交完成后即可返回，不等待 WAL 落盘；崩溃可能丢失最近若干已“成功”的事务。
官方强调：异步提交的风险是 数据丢失，不是数据损坏。恢复仍会重放到最后已刷盘的 WAL，库状态自洽，只是像最近事务被干净回滚一样。

典型用法：

-- 会话级：日志/埋点等可接受极短窗口丢失
SET synchronous_commit = off;

INSERT INTO event_log(payload) VALUES ('...');
-- 默认仍是 on；按事务开始时的参数值决定该事务提交模式

银行出钞、扣款等“客户端会据此做外部动作”的场景，不要关同步提交。

`fsync`（集群级，危险）

fsync = on 时，PostgreSQL 通过 fsync() 或等价方法（见 wal_sync_method）尽量把更新真正写到磁盘，保证 OS/硬件崩溃后仍可恢复到一致状态。

关掉 fsync 可能换来吞吐，但在掉电/系统崩溃时可能导致 不可恢复损坏。文档只建议在可整体重建的场景（初始装载、用完即丢的批处理库、只读克隆等）临时关闭。

工程对照：

设置	主要风险	适用
`synchronous_commit=off`	丢最近事务，库仍一致	可丢失的短事务
`fsync=off`	可能损坏，需重建	几乎仅限可重建环境
默认两者开启	提交稍慢，耐久性强	绝大多数生产

可复现观测实验（实验室）

下面命令假设你有一个可写的测试实例。目标是把“看不见的 WAL 机制”变成可观察指标。

1）看当前 WAL 与检查点统计

SHOW wal_level;
SHOW fsync;
SHOW synchronous_commit;
SHOW checkpoint_timeout;
SHOW max_wal_size;
SHOW min_wal_size;
SHOW full_page_writes;
SHOW checkpoint_completion_target;

SELECT pg_current_wal_lsn() AS current_lsn;

-- 新版本检查点统计在 pg_stat_checkpointer
SELECT num_timed, num_requested, num_done,
 write_time, sync_time, buffers_written
FROM pg_stat_checkpointer;

-- WAL 生成量与 FPI
SELECT wal_records, wal_fpi, wal_bytes, wal_buffers_full
FROM pg_stat_wal;

说明：

num_timed / num_requested 会计入完成与跳过；num_done 只计真正完成的检查点。
空闲实例可能因“自上次检查点以来没有 WAL”而跳过定时检查点。

2）制造 WAL 并观察 LSN 前进

在 psql 中：

CREATE TABLE IF NOT EXISTS wal_lab(
 id bigserial PRIMARY KEY,
 payload text
);

-- 记录写入前 LSN（psql 变量）
SELECT pg_current_wal_lsn() AS before_lsn \gset

INSERT INTO wal_lab(payload)
SELECT repeat('x', 200)
FROM generate_series(1, 5000);

SELECT pg_current_wal_lsn() AS after_lsn,
 pg_wal_lsn_diff(pg_current_wal_lsn(), :'before_lsn') AS wal_bytes;

pg_wal_lsn_diff 返回两个 LSN 之间的字节差，便于量化一次批量写入产生了多少 WAL。若不用 \gset，可先手工抄下 before_lsn 再代入比较。

3）对比同步/异步提交延迟（概念实验）

\timing on

BEGIN;
SET LOCAL synchronous_commit = on;
INSERT INTO wal_lab(payload) VALUES ('sync');
COMMIT;

BEGIN;
SET LOCAL synchronous_commit = off;
INSERT INTO wal_lab(payload) VALUES ('async');
COMMIT;

在高并发小事务压测下，异步提交通常降低提交等待；但要清楚这是 用丢失窗口换延迟，不是免费午餐。

4）强制检查点（仅实验）

CHECKPOINT;
SELECT num_done, write_time, sync_time, buffers_written
FROM pg_stat_checkpointer;

观察 write_time / sync_time 与 buffers_written 的变化，理解检查点 I/O 的代价。

工程调参与排错清单

恢复时间 vs 运行期 I/O

缩短崩溃恢复：减小 checkpoint_timeout / max_wal_size → 检查点更勤 → REDO 更少。
减轻检查点尖峰：增大二者，并把 checkpoint_completion_target 维持在接近 0.9，让刷脏页摊到整个间隔。
不要用检查点频率去“保证归档频率”：若关心归档 RPO，应调 archive_timeout，而不是把检查点拧得很紧。

WAL 目录膨胀

常见原因：

归档命令失败，段无法回收；
复制槽（replication slot）落后，强制保留旧段；
wal_keep_size / 相关保留设置过大；
批量导入、索引重建产生大量 WAL。

排查思路：

-- 归档相关（若启用）
SHOW archive_mode;
SHOW archive_command;
SHOW archive_timeout;

-- 当前是否在恢复（备库）
SELECT pg_is_in_recovery();

同时检查 pg_wal 磁盘占用、复制槽延迟与归档日志报错。

`wal_level` 选型

级别	大致用途
`minimal`	仅崩溃恢复所需信息，体积最小；不足以 PITR/流复制
`replica`（默认）	支持归档与物理复制、备库只读查询
`logical`	在 replica 基础上增加逻辑解码所需信息

生产若要做流复制或连续归档，不要用 minimal；文档还指出：max_wal_senders 非 0 时甚至不能以 minimal 启动。

硬件与虚假“写成功”

WAL 要求日志先于数据页持久化。若磁盘/控制器 谎报写完成（只进缓存未真正落盘），掉电仍可能造成不可恢复损坏。务必确认 WAL 所在存储关闭了危险写缓存，或有电池备份写缓存（BBU）。

常见坑对照表

现象	可能原因	处理方向
提交延迟高、小事务 TPS 低	每次提交都在等 WAL fsync	评估 `synchronous_commit=off`（可丢）或提升 WAL 盘延迟；关注 group commit
检查点期间延迟尖刺	脏页集中刷写	调大 `max_wal_size`/`checkpoint_timeout`，保持 `checkpoint_completion_target≈0.9`
崩溃恢复很久	检查点过稀，REDO 区间过长	适度降低 `max_wal_size` 或 `checkpoint_timeout`
`pg_wal` 撑满磁盘	归档失败 / 复制槽落后	修归档、清理无用槽、扩容并监控
关 `fsync` “更快”	用损坏风险换吞吐	生产禁止；可重建场景才临时关闭
异步提交后“丢单”	崩溃窗口内事务未刷盘	业务上接受丢失，或关键路径保持 `on`
检查点后 WAL 暴涨	FPI（`full_page_writes`）	避免检查点过密；观察 `pg_stat_wal.wal_fpi`

总结

WAL 先于数据页：提交持久化的关键路径是刷 WAL，而不是立刻刷所有脏表页。
检查点定义 REDO 起点：checkpoint_timeout 与 max_wal_size 共同决定自动检查点节奏，直接影响崩溃恢复时间与运行期 I/O。
synchronous_commit=off ≠ fsync=off：前者可能丢最近事务但保持一致；后者可能损坏。
用 LSN 与统计视图观测：pg_current_wal_lsn、pg_stat_checkpointer、pg_stat_wal 把机制落到指标。
调参要绑定目标：RTO（恢复时间）、提交延迟、磁盘占用、复制/归档 RPO，不要只抄一组“神秘最优参数”。

把这些机制吃透后，再去谈高可用、PITR、逻辑复制，才会知道每条配置背后买的是什么、卖的是什么。

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

Fri, 24 Jul 2026 00:00:00 +0800

线上 SQL 变慢时，第一反应往往是“加个索引”。但在 PostgreSQL 里，索引不是“有就快”的开关：默认的 B-tree 适合哪些谓词？多列索引为什么“左边优先”？为什么 EXPLAIN 里会出现 Index Scan、Bitmap Heap Scan 或 Index Only Scan？部分索引、INCLUDE 覆盖列、CREATE INDEX CONCURRENTLY 又分别解决什么工程问题？

本文基于 PostgreSQL 官方文档（当前文档站对应 PostgreSQL 18 手册章节），从机制讲到可复现实验与排错清单，帮助你把索引用在真正该用的地方。

问题背景：没有索引时，数据库在做什么

官方索引导论用了一个很直观的例子：表 test1(id, content) 上频繁执行：

SELECT content FROM test1 WHERE id = constant;

如果没有预先准备，系统只能 逐行扫描整表 找匹配行；行数很大而命中很少时，这显然低效。若在 id 上维护索引，定位匹配行可以走更高效的路径（例如在搜索树中只走几层），而不必通读整本书式的堆表。

关键工程含义：

索引要提前“预见”查询会怎样查找数据——这是 DBA/开发者的职责，而不是数据库自动替你猜对所有场景。
索引创建后会随表的增删改自动维护，但也会带来 写放大与存储开销。
规划器是否选用索引，依赖统计信息；因此要定期 ANALYZE，并学会用 EXPLAIN 验证真实计划。

核心原理：为什么日常几乎都是 B-tree

PostgreSQL 提供多种索引访问方法：B-tree、Hash、GiST、SP-GiST、GIN、BRIN，以及扩展如 bloom。
CREATE INDEX 默认创建 B-tree，因为它覆盖了最常见的相等与范围查询场景。其它类型需要显式 USING method，例如：

CREATE INDEX name ON table USING HASH (column);

B-tree 能加速哪些谓词

官方说明：B-tree 可处理 可排序数据 上的相等与范围查询。规划器会在索引列参与下列比较时考虑使用 B-tree：

运算符 / 形态	说明
`<` `<=` `=` `>=` `>`	基本比较
`BETWEEN` / `IN`	可视为上述比较的组合
`IS NULL` / `IS NOT NULL`	也可用于 B-tree
`LIKE` / `~`	仅当模式为常量且锚定在字符串开头，如 `col LIKE 'foo%'`、`col ~ '^foo'`；`'%bar'` 这类前后缀/中间匹配不行

补充：

非 C locale 时，模式匹配类查询可能需要特殊 operator class 才能用索引（见手册“Operator Classes and Operator Families”相关章节）。
ILIKE / ~* 更受限：模式通常需要以“不受大小写转换影响的字符”开头。
Hash 索引 只存 32-bit 哈希码，因此 只能处理简单相等比较，不能替代 B-tree 的范围与排序能力。

只有 B-tree 能“带着顺序”吐行

索引除了找行，还可能直接按指定顺序交付结果，从而避免额外排序。官方明确：在当前支持的索引类型中，只有 B-tree 能产生有序输出；其它类型返回匹配行的顺序是未指定、实现相关的。

默认 B-tree 条目按 升序、NULLS LAST 存储（相等时用表 TID 作决胜列）。因此：

正向扫描满足 ORDER BY x（即 ASC NULLS LAST）
反向扫描可满足 ORDER BY x DESC（对应 DESC NULLS FIRST 等组合规则）

工程上特别有价值的形态是 ORDER BY ... LIMIT n：显式排序往往要处理全部候选才能取前 n 行；若有匹配的 B-tree，可直接取前 n 行，无需扫完剩余数据。

唯一性约束如何落地

目前只有 B-tree 可声明为 unique。
默认情况下，唯一列中的 多个 NULL 不视为相等（允许多个 NULL）；NULLS NOT DISTINCT 会把 NULL 当相等处理。
定义 PRIMARY KEY / UNIQUE 约束时，PostgreSQL 会自动创建 对应唯一索引，无需再手写一份重复索引。

扫描方式：同一条 SQL，三种常见“走路方式”

PostgreSQL 的索引是 二级索引（secondary index）：索引与堆表（heap）分开存储。普通索引扫描通常既读索引，又回表读堆；匹配的索引项可能相邻，但对应堆行可能散落各处，带来随机 I/O。

1）Index Scan：点查 / 高选择性范围

适合“索引快速锁定少量行，再回表取完整行”的路径。EXPLAIN 中常见 Index Scan using ...。

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

当需要组合多个索引、或单次索引扫描无法直接表达某些 OR/AND 形态时，系统可：

扫描一个或多个索引，在内存中生成 bitmap（标记可能命中的堆位置）
对 bitmap 做 AND / OR
再按 物理顺序 访问堆表（Bitmap Heap Scan）

官方指出：按物理序访问会 丢失原索引顺序，因此后续若需要排序，可能再加 Sort。这也解释了：bitmap 路径擅长降低随机 I/O，但不一定能顺便满足 ORDER BY。

3）Index Only Scan：尽量不回表

Index-only scan 的目标是 只靠索引回答查询。官方给出两个基本前提：

索引类型支持 index-only scan：B-tree 始终支持；GiST/SP-GiST 仅部分 operator class；GIN 等通常不支持（索引项往往只存原值的一部分）。
查询只引用索引中存有的列。例如索引在 (x, y) 上：
- 可用：SELECT x, y FROM tab WHERE x = 'key';
- 不可用（还要读 z）：SELECT x, z FROM tab WHERE x = 'key';

即便列都在索引里，PostgreSQL 仍要做 MVCC 可见性 判断。可见性信息不在索引项里，而在堆中；因此引入 visibility map（可见性映射）：

若堆页对应 all-visible 位已设置，可认为行对当前/未来事务可见，无需再访问堆元组
若未设置，仍需回表检查可见性——此时相对普通 Index Scan 的收益会明显下降

因此：Index Only Scan “物理上可能”，但 只有当表中相当比例堆页的 all-visible 位有效时 才更划算。对“大量行很少变化”的表，这类扫描非常实用；写很频繁、可见性图难以保持的表，收益会打折。

覆盖索引与 `INCLUDE`

为了让高频查询更容易走 index-only，可以做 covering index（覆盖索引）：让索引包含查询需要返回/过滤的列。PostgreSQL 允许用 INCLUDE 添加 非键（non-key）列：

非键列不能用于索引扫描的查找条件，也不参与唯一/排他约束判定
但 index-only scan 可直接从索引叶子返回这些列，无需回表
INCLUDE 列会增大索引、复制数据；宽列要谨慎
带 non-key 列的 B-tree 不会使用 deduplication
表达式不能作为 INCLUDE 列（因为无法用于 index-only scan）
当前 B-tree / GiST / SP-GiST 支持该特性；叶子存 INCLUDE 值，上层导航项不包含它们

-- 键列用于查找，INCLUDE 列服务于覆盖返回
CREATE INDEX orders_user_created_cover
 ON orders (user_id, created_at)
 INCLUDE (status, amount);

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

索引最多 32 列（含 INCLUDE；编译期可改 pg_config_manual.h）。
多键列目前由 B-tree、GiST、GIN、BRIN 等支持（与能否 INCLUDE 是两件独立的事）。
多列 B-tree 可用于涉及任意列子集的条件，但 在前导（最左）列上有约束时最高效。
精确规则（官方表述）：对前导列的 相等约束，加上第一个没有相等约束的列上的 不等式约束，总是用于限制扫描的索引区间；更右侧列上的条件仍会在索引内检查（可减少回表），但不一定缩小扫描区间。
新版本还有 skip scan 优化：在合适基数下，可对缺少常规相等约束的中间列做内部动态相等约束，减少读取区间——但这是优化，不是让你随意打乱“左前缀”设计习惯。

经验对照：

查询形态	更合适的索引直觉
总是 `WHERE a = ? AND b = ?`	`(a, b)` 复合索引
有时只有 `a`，有时只有 `b`，有时两者	可能两个单列 + 让规划器组合；或评估 skip scan / 复合
`ORDER BY a, b LIMIT n`	与排序方向一致的 `(a, b)` B-tree
只查“活跃订单”等小子集	部分索引往往比全表索引更划算

部分索引：只索引“值得索引”的子集

部分索引建立在表的一个子集上，子集由谓词（WHERE）定义，索引 只包含满足谓词的行。

官方给出的核心动机：

避免给常见值建索引：若某值占比很高，查它本来也未必走索引，放进索引只会白白增大体积、拖慢写路径。
缩小索引 → 命中索引的查询更快，且很多更新不必维护该索引。

典型场景：访问日志中组织内网 IP 占比极高，但排查更关心外部 IP：

CREATE INDEX access_log_client_ip_ix
 ON access_log (client_ip)
 WHERE NOT (
 client_ip > inet '192.168.100.0'
 AND client_ip < inet '192.168.100.255'
 );

只有查询条件也落在“被索引子集”内时，规划器才能使用该部分索引；条件与谓词冲突时不会用。

可复现实验：从建表到读懂 EXPLAIN

下面用一套小实验把机制落到命令（在任意 PostgreSQL ≥ 14 环境可跑；语句本身与官方语义一致）。

-- 1) 准备数据
DROP TABLE IF EXISTS demo_orders;
CREATE TABLE demo_orders (
 id bigserial PRIMARY KEY,
 user_id int NOT NULL,
 status text NOT NULL,
 amount numeric(12,2) NOT NULL,
 created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO demo_orders (user_id, status, amount, created_at)
SELECT
 (random()*10000)::int,
 (ARRAY['paid','pending','cancelled','paid','paid'])[1 + (random()*4)::int],
 round((random()*500)::numeric, 2),
 now() - ((random()*365)::int || ' days')::interval
FROM generate_series(1, 200000);

ANALYZE demo_orders;

-- 2) 无业务二级索引时看计划（主键本身是 B-tree 唯一索引）
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM demo_orders WHERE user_id = 42;

-- 3) 建立常用复合索引 + 部分索引 + 覆盖索引
CREATE INDEX CONCURRENTLY demo_orders_user_created_idx
 ON demo_orders (user_id, created_at DESC);

CREATE INDEX CONCURRENTLY demo_orders_pending_idx
 ON demo_orders (created_at)
 WHERE status = 'pending';

CREATE INDEX CONCURRENTLY demo_orders_user_cover_idx
 ON demo_orders (user_id)
 INCLUDE (status, amount);

ANALYZE demo_orders;

-- 4) 对比计划节点名称
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, status, amount
FROM demo_orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM demo_orders
WHERE status = 'pending'
 AND created_at > now() - interval '7 days';

EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, status, amount
FROM demo_orders
WHERE user_id = 42;
-- 若统计与可见性合适，可能出现 Index Only Scan（依赖 INCLUDE 覆盖 + visibility map）

读计划时优先看：

节点类型：Seq Scan / Index Scan / Bitmap Index Scan + Bitmap Heap Scan / Index Only Scan
实际行数 vs 估算行数（rows）：偏差大 → 统计过期或谓词难估，先 ANALYZE，再考虑扩展统计
Buffers：命中共享缓冲还是读盘；Index Only Scan 是否仍有大量 heap fetches（可见性图不给力）
是否多了不必要的 Sort：排序方向与索引 (ASC/DESC, NULLS ...) 是否一致

生产变更：`CREATE INDEX CONCURRENTLY`

普通 CREATE INDEX 会对表加写锁：其它事务仍可读，但 INSERT/UPDATE/DELETE 会阻塞到索引建完。大表上这可能长达数小时，生产不可接受。

CREATE INDEX CONCURRENTLY 的官方要点：

构建过程 不获取会阻止并发写 的锁（允许正常 DML 继续）
代价：通常要 两次表扫描，并等待可能修改/使用该索引的相关事务结束，总工作量更大、耗时更长
过程中索引会先以 INVALID 状态进入系统目录；成功结束后才标为可用
若扫描阶段失败（死锁、唯一冲突等），命令失败但可能留下 INVALID 索引：查询会忽略它，却仍要为写维护它 → 推荐 DROP 后重试 CREATE INDEX CONCURRENTLY（或 REINDEX INDEX CONCURRENTLY）
CREATE INDEX CONCURRENTLY 不能放在事务块里；分区表并发构建有额外限制（可先对分区并发建，再非并发建分区父索引以缩短写锁定窗口）
同一表上 同时只能有一个 concurrent index build

CREATE INDEX CONCURRENTLY sales_quantity_index
 ON sales_table (quantity);

常见坑与排查清单

现象	常见原因	怎么查 / 怎么办
建了索引仍 `Seq Scan`	选择性差、统计过期、函数包住列导致无法匹配、成本模型认为全表更便宜	`EXPLAIN`；`ANALYZE`；避免 `WHERE func(col)=...`（改表达式索引）；用真实参数看计划
`LIKE '%x%'` 不走 B-tree	B-tree 需要前缀锚定模式	换 `pg_trgm` + GIN/GiST 等（另一条路线，不是默认 B-tree）
多列索引“像没用”	谓词没落在最左列，或类型/排序规则不匹配	检查前导列是否有相等/范围条件；核对 `ASC/DESC NULLS`
期望 Index Only Scan 却回表很多	查询列未覆盖；visibility map 中 all-visible 比例低	`INCLUDE` 覆盖；减少无意义更新；关注 vacuum 是否跟上
写变慢、膨胀	索引过多、宽 INCLUDE、低选择性索引	用 `pg_stat_user_indexes` 看扫描次数；删冗余；部分索引收窄
`CONCURRENTLY` 后有 `INVALID`	构建失败留下残留	`\d table` 确认；`DROP INDEX` 后重建
唯一约束“允许多个 NULL”	默认 NULL 不相等	需要业务唯一含 NULL 时用 `NULLS NOT DISTINCT`

辅助观测：

-- 索引是否被使用（需打开 stats）
SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC
LIMIT 30;

-- 无效索引排查（概念：concurrent 失败残留）
SELECT c.relname AS index_name, i.indisvalid
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE NOT i.indisvalid;

工程实践建议（可直接落地）

先写清访问路径：等值 / 范围 / 排序 / 覆盖返回列 / 是否只查子集。
默认从 B-tree 开始：范围、排序、唯一约束几乎都靠它；Hash 仅在“只要相等且理解其限制”时考虑。
复合索引按过滤+排序设计列序：高频等值列靠左，范围/排序列靠右；方向与 ORDER BY 对齐。
热点子集优先部分索引：状态机里的 pending、软删除后的“有效行”、租户内活跃数据等。
高频只读投影再谈 INCLUDE：覆盖收益要压过索引变大与 dedup 失效的代价。
生产建索引用 CONCURRENTLY，并处理 INVALID 残留。
用 EXPLAIN (ANALYZE, BUFFERS) 闭环，而不是用“感觉”判断索引是否生效。

总结

PostgreSQL 索引体系的核心不是“类型清单”，而是三层决策：

访问方法：日常以 B-tree 承载相等、范围、排序与唯一性；Hash/GIN/GiST/BRIN 解决更专门的谓词与数据形态。
扫描算子：Index Scan 精确定位，Bitmap 组合与减少随机 I/O，Index Only Scan 在覆盖列 + 可见性图友好时避免回表。
工程形态：多列最左前缀、部分索引缩子集、INCLUDE 做覆盖、CONCURRENTLY 保障在线变更。

把这三层和 EXPLAIN 对上，索引才会从“玄学加速”变成可验证的性能工具。

参考资料

OceanBase 从零开始：核心概念、上手路径，以及和 MySQL 的关键差异

Fri, 17 Jul 2026 01:00:00 +0800

如果你已经会 MySQL，第一次接触 OceanBase 时，最容易卡住的不是“SQL 怎么写”，而是：

它看起来很像 MySQL，为什么连接方式、资源模型、高可用和运维概念完全不是一回事？

本文面向零基础到 MySQL 初中级同学，用一条从概念到上手的路径讲清楚：

OceanBase 是什么
和 MySQL 在架构、租户、连接、兼容性上的核心差异
从连接、建库建表到基础 SQL 的最小实践
什么场景该把 OceanBase 当“更强的 MySQL”，什么场景不能这么想

说明：本文以 OceanBase 社区版（MySQL 模式） 为主。官方文档明确：社区版仅提供 MySQL 模式；企业版还支持 Oracle 模式。

一、先建立正确心智模型

1. MySQL 的常见心智模型

很多人对 MySQL 的默认理解是：

一台机器 / 一个 mysqld 实例
 └── 多个 database
 └── 多个 table

连接通常很直接：

mysql -h127.0.0.1 -P3306 -uroot -p

你连上的，基本就是“这个实例本身”。

2. OceanBase 的心智模型

OceanBase 更接近：

一个集群（Cluster）
 └── 多个节点（OBServer）
 └── 多个可用区（Zone）
 └── 多个租户（Tenant） ← 应用视角下更像“数据库实例”
 └── 多个 database
 └── 多个 table / 分区

关键变化只有一句话：

在 OceanBase 里，应用通常不是“连一台 MySQL 机器”，而是“连某个租户”。

官方文档把租户定义为：集群内互相隔离的数据库“实例”。对应用来说，一个租户近似一个独立数据库实例；租户之间数据、权限、资源隔离。

二、OceanBase 是什么

OceanBase 是蚂蚁集团开源的分布式关系型数据库，基于 Paxos 类共识协议与分布式架构，提供高可用和水平扩展能力，可运行在普通服务器集群上。

官方强调的关键能力包括：

水平扩展
高可用（RPO=0、RTO 秒级恢复目标）
MySQL 兼容，便于迁移
HTAP（同一套系统同时服务事务与分析负载）
多租户资源隔离

你可以把“上手阶段”理解成两层：

层	你感受到的
SQL 层	很像 MySQL：`CREATE DATABASE` / `CREATE TABLE` / `SELECT`
系统层	更像分布式数据库：集群、Zone、租户、Unit、副本、OBProxy

三、和 MySQL 的核心差异总览

维度	MySQL（常见单机/主从）	OceanBase
基本部署单元	实例（mysqld）	集群 + 租户
应用连接对象	实例	租户（经直连或 OBProxy）
默认端口（常见）	`3306`	直连 `2881`，经 ODP/OBProxy 常见 `2883`
用户写法	`root`	`root@tenant` 或 `user@tenant#cluster`
扩展方式	垂直扩容 / 读写分离 / 分库分表	原生分区、多节点、副本扩展
高可用机制	主从复制、MGR 等	基于 Multi-Paxos 的多副本日志流
多业务隔离	多实例 / 多库 + 权限	原生多租户 + 资源池
存储引擎模型	InnoDB 等可插拔引擎	自研分布式存储与事务体系
SQL 兼容	原生 MySQL	MySQL 模式兼容 5.7/8.0 大部分能力，但非 100%
社区版模式	MySQL	仅 MySQL 模式

一句话：

MySQL 更像“一台关系库”；OceanBase 更像“一个可多租户的分布式数据库平台”。

四、架构差异：为什么它不像单机 MySQL

1. Shared-Nothing 集群

官方系统架构文档指出，OceanBase 常用无共享（Shared-Nothing）模式：

节点对等
每个节点都有自己的 SQL / 存储 / 事务能力
表可水平拆分为多个分区（Partition）
分区数据落在 Tablet，修改通过日志流（Log Stream）持久化
主从副本通过 Multi-Paxos 保持一致性

这意味着：

数据天然可分布到多节点
故障切换依赖副本选举，而不是简单“切到另一台 mysqld”
建表时的分区设计，会直接影响数据分布与扩展性

2. 多租户：最容易被 MySQL 同学忽略的概念

在 OceanBase 中：

集群初始化后会有系统租户 sys
sys 保存集群元数据，本身也是 MySQL 兼容模式租户
业务一般应在普通租户里建库建表，而不是把所有业务都堆在 sys

创建业务租户的典型顺序是：

Unit Config（资源规格）
 → Resource Pool（资源池）
 → Tenant（租户）

这和 MySQL 里“直接 CREATE DATABASE”完全不同。
MySQL 的 database 更像命名空间；OceanBase 的 tenant 更像独立实例边界。

3. OBProxy / ODP：应用如何“像访问单机库一样”访问分布式库

为了让应用尽量少感知分区和副本分布，OceanBase 提供 ODP（OceanBase Database Proxy，又称 OBProxy）：

应用通常连代理
代理把 SQL 路由到合适节点
对应用更接近“连一个入口地址”

这对应 MySQL 生态里的 proxy / 中间件角色，但在 OceanBase 里它更常作为标准访问路径出现。

五、连接差异：最容易踩坑的地方

1. Docker 体验环境（最简单）

快速体验可用官方镜像：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce | tail -1 # 期望 boot success!

连接示例：

# 系统租户 root
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

# 或宿主机 mysql 客户端
mysql -h127.0.0.1 -P2881 -uroot
mysql -h127.0.0.1 -P2881 -uroot@test

2. 正式连接写法：用户名里有租户

官方文档给出两类常见连接：

直连 OBServer（默认端口常为 2881）

mysql -h<observer_ip> -P2881 -u用户名@租户名 -p

注意：

直连时 -u 应是 用户名@租户名
不要在直连用户名里带集群名，否则可能报错
普通租户直连时，目标节点上需要有该租户资源

通过 ODP/OBProxy（默认端口常为 2883）

mysql -h<odp_ip> -P2883 -u用户名@租户名#集群名 -p

用户名还可能写成：

集群名:租户名:用户名
集群名-租户名-用户名
集群名.租户名.用户名

这和 MySQL 的 root@'%' 完全不是同一套语义。

3. 客户端选择

可用 obclient
也可用 MySQL 客户端连接 MySQL 模式租户
官方文档提到当前支持的 MySQL 客户端版本包括 5.5 / 5.6 / 5.7（以你使用版本的文档为准）

六、从零上手：MySQL 同学 10 分钟路径

下面假设你已经能连上一个 MySQL 模式租户。

1. 看有哪些库

SHOW DATABASES;

体验环境里常见会看到 oceanbase、test、information_schema、mysql 等。

2. 创建业务库

CREATE DATABASE demo DEFAULT CHARACTER SET utf8mb4 READ WRITE;
USE demo;

这和 MySQL 非常像。

3. 建表、写入、查询

CREATE TABLE users (
 id INT PRIMARY KEY,
 name VARCHAR(64) NOT NULL,
 created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (id, name) VALUES
 (1, 'alice'),
 (2, 'bob');

SELECT id, name FROM users WHERE id = 1;
UPDATE users SET name = 'alice2' WHERE id = 1;
DELETE FROM users WHERE id = 2;

官方 MySQL 模式基础文档也覆盖了：

CREATE DATABASE / SHOW DATABASES
CREATE TABLE / SHOW TABLES / SHOW CREATE TABLE
ALTER TABLE
INSERT / UPDATE / DELETE / TRUNCATE
多表查询、聚合、EXPLAIN 等

4. 看建表细节时的“OceanBase 味道”

在 OceanBase 里执行：

SHOW CREATE TABLE users\G

你可能会看到比 MySQL 更“重”的表属性，例如副本数、压缩、Tablet 相关参数等。
这说明：SQL 表面兼容，元数据与存储参数并不等同于 InnoDB。

七、兼容性：像 MySQL，但不是 100% MySQL

官方《与 MySQL 兼容性对比》说明：

OceanBase 的 MySQL 模式兼容 MySQL 5.7/8.0 的绝大部分功能和语法；因架构差异或需求优先级，部分功能未支持。

1. 相似度高的部分

通常对应用最友好的部分：

常见数值 / 时间 / 字符 / JSON 等数据类型
SELECT / INSERT / UPDATE / DELETE
多表连接、子查询、聚合分组
存储过程、函数、触发器等大部分 PL 能力
information_schema、mysql 中的大量视图（但不是逐列完全等价）

因此：

很多基于 MySQL 协议的驱动可直接连
简单 CRUD 业务迁移门槛较低
你会有“这不就是 MySQL 吗”的错觉

2. 必须注意的差异

官方明确提到的差异方向包括：

类别	差异点
SQL 语法	例如不支持 `SELECT ... FOR SHARE ...`
TRUNCATE	不支持在事务处理与表锁定过程中操作
系统视图	不保证所有视图/列含义都与 MySQL 相同
存储引擎	不是 InnoDB 插件体系，而是自研分布式存储事务体系
优化器	执行计划与优化策略不同
分区 / 备份恢复	能力模型与操作路径不同
架构相关功能	因分布式架构，部分单机 MySQL 习惯不能照搬

3. 实战迁移建议

从 MySQL 迁到 OceanBase 时，不要只做“能不能连上”：

先验证协议层：驱动、连接池、ORM
再验证 SQL 层：慢 SQL、锁、事务边界、分页、HINT
再验证运维层：备份恢复、监控指标、扩缩容、租户资源
最后验证边界语法：冷门函数、系统表、复制相关特性、特定锁语法

一句话：

兼容的是“MySQL 使用体验”，不是“MySQL 内核实现”。

八、对象模型对比：database 相同，边界不同

MySQL

Instance
 └── Database
 └── Table / View / Procedure

权限、连接、资源，常常都围绕“实例 + 账号”展开。

OceanBase

Cluster
 └── Tenant（资源与权限边界更强）
 └── Database
 └── Table / Index / Procedure
 └── sys 租户（集群元数据）

对 MySQL 同学最实用的迁移记忆：

你在 MySQL 想做的事	在 OceanBase 更常见的对应
新建一个业务实例	新建一个业务租户
在实例里建库	在租户里 `CREATE DATABASE`
给业务分配 CPU/内存	调整 Unit Config / Resource Pool
连业务库	连 `user@tenant`
做高可用	规划 Zone / 副本 / 主备切换，而不是只配主从

九、一个最小对比实验（帮助真正理解差异）

实验 A：同一套 CRUD

在 OceanBase MySQL 模式租户执行：

CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4;
USE shop;

CREATE TABLE orders (
 order_id BIGINT PRIMARY KEY,
 user_id BIGINT NOT NULL,
 amount DECIMAL(10,2) NOT NULL,
 status VARCHAR(16) NOT NULL
);

INSERT INTO orders VALUES
 (1001, 1, 19.90, 'PAID'),
 (1002, 2, 39.00, 'CREATED');

SELECT * FROM orders WHERE status = 'PAID';

你会发现：
如果只看 SQL，这和 MySQL 几乎没区别。

实验 B：连接串差异

MySQL：

mysql -h127.0.0.1 -P3306 -uroot -p shop

OceanBase 直连某租户：

mysql -h127.0.0.1 -P2881 -uroot@test -p shop

OceanBase 经 ODP：

mysql -h127.0.0.1 -P2883 -uroot@test#cluster_name -p shop

你会发现：
真正拉开差距的，是“你连到了哪里”和“资源边界在哪里”。

实验 C：多租户隔离

在 sys 中创建两个业务租户后：

root@tenant1 里建表
root@tenant2 里看不到那张表

官方多租户示例正是用这种方式证明：
租户之间资源、数据、权限隔离。

这比 MySQL 里“两个 database 互相授权”要更接近“两个实例”。

十、什么时候适合用 OceanBase，什么时候继续 MySQL

更适合考虑 OceanBase 的场景

需要水平扩展，单机 MySQL + 分库分表成本高
需要更强的金融级高可用与多副本一致性
希望一套系统兼顾 TP 与部分 AP
多业务要强隔离，但又想统一运维平台（多租户）
已有大量 MySQL 协议应用，希望降低改造成本

更适合继续 MySQL 的场景

单机或轻量业务，数据量和可用性要求不高
团队只熟悉传统 mysqld 运维，短期不想引入分布式复杂度
深度依赖某些 MySQL 专有行为 / 插件 / 生态工具且未验证兼容
本地开发只需要极轻量依赖（虽然也可用 OceanBase Docker，但 MySQL 更轻）

十一、学习路线建议

如果你是 MySQL 背景，建议按这个顺序学：

先跑起来：Docker / obd demo
先会连：user@tenant、2881 / 2883
先当 MySQL 用：建库建表 CRUD
再学租户与资源：Unit / Resource Pool / sys 与普通租户
再学分布式：分区、副本、Zone、OBProxy 路由
最后做迁移评估：兼容性清单 + 压测 + 备份恢复演练

配套阅读：

本站另一篇：OceanBase 多平台搭建教程
官方 MySQL 兼容性文档
官方系统架构与多租户文档

十二、速查对照表

主题	MySQL	OceanBase
默认连接	`root@host:3306`	`root@tenant@host:2881` 或经 ODP `2883`
业务隔离	database / 多实例	tenant
管理入口	实例管理员	常先登 `sys` 做集群与租户管理
扩展	加配 / 分库分表	分区 + 多节点 + 资源单元
高可用	复制拓扑	Multi-Paxos 多副本
SQL 习惯	原生 MySQL	高度兼容，但要做差异验证
社区版模式	MySQL	仅 MySQL 模式

总结

OceanBase 对 MySQL 同学并不“难在 SQL”，而难在换模型：

把“实例”理解升级成“集群 + 租户”
把“连上 mysqld”升级成“连上正确的租户入口”
把“兼容 MySQL”理解成“协议与常用 SQL 友好，不等于内核相同”
先用 CRUD 建立信心，再用租户、分区、副本理解它的分布式能力

掌握这四步后，你就不会再把 OceanBase 误当成“换了皮的 MySQL”，也能更准确判断它该用在什么地方。

参考资料

OceanBase 官方仓库 README（中英文，MySQL 兼容与快速开始）：https://github.com/oceanbase/oceanbase
OceanBase 官方文档：系统架构（oceanbase-doc / V4.3.5）
OceanBase 官方文档：与 MySQL 兼容性对比
OceanBase 官方文档：SQL 基础操作（MySQL 模式）
OceanBase 官方文档：体验多租户特性
OceanBase 官方文档：通过 MySQL 客户端连接 OceanBase 租户
OceanBase Docker 镜像：https://hub.docker.com/r/oceanbase/oceanbase-ce
OceanBase 中文文档中心：https://www.oceanbase.com/docs/oceanbase-database-cn

OceanBase 多平台搭建教程：Linux / Windows / macOS / Docker 从零到可连接

Fri, 17 Jul 2026 00:00:00 +0800

OceanBase 是蚂蚁集团开源的分布式关系型数据库，兼容 MySQL 协议，适合本地体验、开发联调与集群试验。很多人第一次上手时最困惑的不是“它强在哪”，而是：

我在 Linux / Windows / macOS 上，到底该用哪一种方式装？

本文按官方社区推荐路径，整理一套可复用的多平台搭建方法：优先讲最快跑起来，再讲更接近生产部署的方式，并给出连接验证与常见排错。

说明：本文以 OceanBase 社区版（CE） 的官方开源安装路径为主，面向学习与开发环境。官方 Docker 镜像明确标注仅供测试，不建议直接用于生产。

一、先选对安装路径

平台	最推荐方式	备选方式	说明
Linux	`all-in-one` + `obd demo`	Docker / OBD 自定义集群	官方 all-in-one 仅支持 Linux
macOS	Docker Desktop + `oceanbase-ce`	远程 Linux 开发机	本机不建议硬编译 observer 当第一选择
Windows	Docker Desktop	WSL2 + Linux 方案	原生 Windows 不适合当主路径
任意平台（快速体验）	Docker `oceanbase/oceanbase-ce`	quay.io / ghcr.io 镜像源	单实例、端口 `2881`
Kubernetes	`ob-operator`	—	容器化生产/类生产集群请走 operator

资源底线（很重要）

不同路径对资源要求不同，至少记住两档：

Docker 官方镜像（测试）
- 主机建议至少 2 物理核 + 8GB 内存
obd demo 本地单节点
- 至少 2 CPU、6GB 可用内存、54GB 可用磁盘
- 端口 2881 / 2882 未被占用

机器太小会导致 bootstrap 卡住、容器反复重启，看起来像“命令写错了”，其实是资源不足。

二、通用概念：端口、租户、客户端

搭好后，通常这样连接：

项目	常见值
协议	MySQL 兼容
SQL 端口	`2881`
系统租户	`sys`
示例业务租户	`test`（Docker 镜像常见）
客户端	`obclient` 或标准 `mysql` 客户端

常用连接示例：

# 系统租户 root
mysql -h127.0.0.1 -P2881 -uroot

# 普通租户 root（Docker 文档示例）
mysql -h127.0.0.1 -P2881 -uroot@test

如果你本机没有 mysql 客户端，可用容器内置客户端：

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

三、最快路径：Docker（Linux / Windows / macOS 通用）

这是跨平台体验 OceanBase 最省事的方式。
官方提供镜像：

Docker Hub：oceanbase/oceanbase-ce
备选：quay.io/oceanbase/oceanbase-ce
备选：ghcr.io/oceanbase/oceanbase-ce

官方说明：该镜像用于快速搭建测试环境，只支持单实例；若在 Kubernetes 中运行，请改用 ob-operator。

1. 前置条件

已安装并可运行 Docker（Linux Docker Engine / Docker Desktop）
主机资源满足：约 2 核 + 8GB 内存
本机 2881 端口空闲

2. 启动实例

# mini 模式：适合快速体验（官方 README 推荐写法）
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

Docker Hub 文档还给出了其他模式：

# 使用容器更多资源
docker run -p 2881:2881 --name oceanbase-ce -e MODE=normal -d oceanbase/oceanbase-ce

# slim / fastboot 模式
docker run -p 2881:2881 --name oceanbase-ce -e MODE=slim -d oceanbase/oceanbase-ce

若 Docker Hub 拉取慢，可切换镜像源：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d quay.io/oceanbase/oceanbase-ce
# 或
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d ghcr.io/oceanbase/oceanbase-ce

3. 等待 bootstrap 完成

首次启动可能需要几分钟。查看日志末尾：

docker logs oceanbase-ce | tail -1

期望看到：

boot success!

4. 连接验证

# 方式 A：容器内客户端
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

# 方式 B：宿主机 mysql 客户端
mysql -h127.0.0.1 -P2881 -uroot
mysql -h127.0.0.1 -P2881 -uroot@test

进入后可执行：

SHOW DATABASES;
SELECT version();

5. 常用运维命令

docker ps -a | grep oceanbase-ce
docker logs -f oceanbase-ce
docker restart oceanbase-ce
docker stop oceanbase-ce
docker rm -f oceanbase-ce

6. 初始化 SQL（可选）

官方镜像支持挂载初始化脚本目录：

docker run -p 2881:2881 --name oceanbase-ce \
 -v /path/to/init-sql:/root/boot/init.d \
 -d oceanbase/oceanbase-ce

注意：官方文档提醒，初始化脚本中不要直接改 root 密码；若要改密码，应使用镜像提供的环境变量（如 OB_TENANT_PASSWORD，以当前镜像说明为准）。

四、Linux 原生：all-in-one + OBD（官方推荐体验路径）

如果你有一台 Linux 服务器或虚拟机，想更接近“真集群工具链”，优先用官方 all-in-one。

1. 一键安装 all-in-one

官方 README 明确：仅 Linux。

# 需要能访问外网
bash -c "$(curl -s https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/download-center/opensource/oceanbase-all-in-one/installer.sh)"
source ~/.oceanbase-all-in-one/bin/env.sh

2. 一键拉起演示实例

obd demo

obd demo 会在本机部署并启动一个 OceanBase 实例。部署完成后：

obclient -h127.0.0.1 -uroot -P2881

3. 单独安装 OBD（CentOS/RHEL 系）

如果你不走 all-in-one，也可以单独装 OceanBase Deployer：

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
sudo yum install -y ob-deploy
source /etc/profile.d/obd.sh

然后同样可用：

obd demo

4. `obd demo` 前自检清单

端口 2881、2882 空闲
可用内存 ≥ 6GB
CPU ≥ 2
可用磁盘 ≥ 54GB
系统时间正常、主机名可解析

资源不够时，OBD 往往会在预检阶段失败；先把机器规格补齐再重试，比反复改 YAML 更有效。

五、Windows 搭建

Windows 原生不适合作为 OceanBase observer 主部署平台。实操建议两条路：

方案 A：Docker Desktop（最简单）

安装 Docker Desktop for Windows
确保 WSL2 后端已启用（Docker Desktop 默认推荐）
在 PowerShell / Windows Terminal 执行：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce

看到 boot success! 后连接：

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

Windows 上若本机没有 mysql 客户端，优先用容器内 obclient。

方案 B：WSL2 + Linux 路径

适合希望练习 obd / all-in-one 的同学：

安装 WSL2 与 Ubuntu（或其他受支持发行版）
给 WSL 分配足够内存（建议在 .wslconfig 中提高 memory）
在 WSL 内按上文 Linux all-in-one / Docker 步骤执行

注意：WSL 的磁盘 I/O 与内存限制会影响 bootstrap 时间，尽量把数据放在 Linux 文件系统内，不要跨挂载到很慢的 Windows 目录。

六、macOS 搭建

macOS 上同样优先 Docker：

1. 安装 Docker Desktop for Mac

Intel / Apple Silicon 都可使用 Docker Desktop
在 Docker Desktop → Settings → Resources 中给足 CPU/内存（建议 ≥ 2 CPU、8GB）

2. 启动 OceanBase

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

拉取慢时可换：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d ghcr.io/oceanbase/oceanbase-ce

3. 连接

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

4. macOS 特别提醒

官方 all-in-one 标注 Linux Only，不要在 macOS 上硬套那条 installer 当主路径
Apple Silicon 上若镜像/依赖偶发兼容问题，优先换官方备用镜像源，或使用远程 Linux 机器做部署练习
开发联调可把应用跑在 macOS，数据库跑在 Docker 容器；应用连接 127.0.0.1:2881

七、进阶：Kubernetes 与多节点

当你已经不满足“本机单实例体验”，可以往这两类走：

1. Kubernetes：`ob-operator`

官方 README 推荐使用 ob-operator 在 K8s 中部署管理 OceanBase。
适合：

想练容器化运维
需要更接近云原生的生命周期管理
本地 kind/k3s/自建集群实验

快速入口见：https://oceanbase.github.io/ob-operator

2. OBD 自定义集群

obd demo 只是快速单机演示。真正做多副本/多节点时，应使用 OBD 的集群配置与命令组（镜像仓库、集群启停、升级等）。
这已经超出“第一次搭起来”的范围，但方向应是：

先用 Docker / obd demo 跑通连接
再学 OBD 配置文件与集群拓扑
最后再上 K8s operator

八、连接后的最小验收清单

不管你用哪种平台，搭完后建议做同一套验收：

-- 1. 能登录
SELECT 1;

-- 2. 看版本信息
SELECT version();

-- 3. 建库建表
CREATE DATABASE demo;
USE demo;
CREATE TABLE t1(id INT PRIMARY KEY, name VARCHAR(64));
INSERT INTO t1 VALUES (1, 'oceanbase');
SELECT * FROM t1;

宿主机侧再确认：

# 端口监听
# Linux
ss -lntp | grep 2881
# macOS
lsof -iTCP:2881 -sTCP:LISTEN

九、常见问题排查

1. 容器一直起不来 / 没有 `boot success!`

优先检查：

内存是否低于 8GB（Docker 场景）
磁盘是否紧张
docker logs oceanbase-ce 是否有 OOM / 权限 / 存储错误
是否重复占用容器名 oceanbase-ce

处理：

docker rm -f oceanbase-ce
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

2. `2881` 端口冲突

# 换宿主机端口映射，例如 12881 -> 2881
docker run -p 12881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
mysql -h127.0.0.1 -P12881 -uroot

3. Docker Hub 拉取失败

依次尝试：

quay.io/oceanbase/oceanbase-ce
ghcr.io/oceanbase/oceanbase-ce
配置可用的镜像加速 / 代理

4. 能进容器但不能从宿主机连接

确认 -p 2881:2881 已映射
Windows/macOS 确认 Docker Desktop 正在运行
云服务器还要放行安全组/防火墙入站规则

5. `obd demo` 预检失败

对照官方条件逐项查：

内存、CPU、磁盘是否达标
2881/2882 是否被占用
是否在非 Linux 环境误跑 all-in-one

十、平台选型建议（实战版）

你的目标	建议
30 分钟内先连上跑 SQL	Docker `MODE=mini`
在 Linux 服务器练官方部署工具	all-in-one + `obd demo`
Windows 笔记本本地体验	Docker Desktop
macOS 开发机联调	Docker Desktop
学习 K8s 运维	ob-operator
准备生产环境	不要直接用体验镜像；按正式部署/高可用架构与官方生产文档规划

一句话总结：

跨平台先 Docker；Linux 深造用 OBD；生产上集群/K8s，不要拿体验镜像硬上。

十一、精简命令速查

Docker（全平台）

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce | tail -1
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

Linux all-in-one

bash -c "$(curl -s https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/download-center/opensource/oceanbase-all-in-one/installer.sh)"
source ~/.oceanbase-all-in-one/bin/env.sh
obd demo
obclient -h127.0.0.1 -uroot -P2881

OBD RPM（CentOS/RHEL）

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
sudo yum install -y ob-deploy
source /etc/profile.d/obd.sh
obd demo

总结

OceanBase 的“多平台搭建”并不要求你在每个 OS 上都原生编译一套数据库：

Docker 是 Linux / Windows / macOS 的最大公约数，适合快速体验与开发联调。
Linux all-in-one + OBD 更接近官方部署工具体验，适合服务器环境。
Windows / macOS 应把精力放在 Docker Desktop（或 WSL2）而不是强行原生部署。
需要容器编排时，转向 ob-operator，而不是把 oceanbase-ce 体验镜像直接当生产方案。

先保证“能启动、能连接、能建表”，再进入租户管理、资源规格、多副本和高可用，路径会清晰很多。

参考资料

OceanBase 官方仓库 README（中英文 Quick Start / Docker / all-in-one）：https://github.com/oceanbase/oceanbase
OceanBase Docker 镜像说明（Docker Hub oceanbase/oceanbase-ce）：https://hub.docker.com/r/oceanbase/oceanbase-ce
OceanBase Docker 镜像仓库文档：https://github.com/oceanbase/docker-images
OceanBase Deployer（OBD）中文 README：https://github.com/oceanbase/obdeploy
ob-operator 文档：https://oceanbase.github.io/ob-operator
OceanBase 中文文档中心：https://www.oceanbase.com/docs/oceanbase-database-cn
快速体验入口：https://open.oceanbase.com/quickStart

MySQL InnoDB 事务隔离级别与 MVCC：原理、可见性与工程实践

Tue, 14 Jul 2026 00:00:00 +0800

在业务代码里，很多人把「开事务」当成理所当然：BEGIN → 几条 SQL → COMMIT。线上一旦出现脏数据、重复扣减、偶发死锁，第一反应却是「加锁」或「把隔离级别调高」。其实 InnoDB 的默认行为已经是一套完整的 多版本并发控制（MVCC）+ 行级锁 组合；真正关键的是：读走快照还是走加锁读、当前隔离级别如何决定可见性与间隙锁。

本文基于 MySQL 官方手册中的隔离级别、多版本、一致性非锁定读、间隙锁/next-key 与死锁说明，梳理可复用的原理与工程实践，而不是版本变更清单。

问题背景：并发事务到底在“打架”什么

SQL 标准用隔离级别描述并发下的异常现象（脏读、不可重复读、幻读）。InnoDB 实现了标准里的四级隔离：

隔离级别	典型问题	InnoDB 要点（官方行为）
READ UNCOMMITTED	脏读	普通 `SELECT` 可能读到「更早版本」的行，读本身不一致
READ COMMITTED	不可重复读、幻读	每次一致性读使用新快照；锁定读通常只锁记录、不锁间隙
REPEATABLE READ（默认）	幻读在加锁读路径上被抑制	事务内普通一致性读复用首次读建立的快照；范围锁定读使用 gap/next-key
SERIALIZABLE	最强串行语义	在 `autocommit` 关闭时，普通 `SELECT` 隐式变为 `SELECT ... FOR SHARE`

默认是 REPEATABLE READ。很多团队在迁移自 Oracle 等库时会改成 READ COMMITTED，这会显著改变锁与幻读行为——必须按业务场景评估，而不是「听说更像 Oracle 就改」。

核心原理：MVCC 如何让读不挡写

行上的隐藏字段与 undo

InnoDB 是多版本存储引擎：被修改行的旧版本信息保存在 undo 表空间 / 回滚段 中，用于：

事务回滚时做 undo
一致性读时构造「更早版本的行」

官方文档指出，InnoDB 会在每行内部维护（概念上）这些字段：

DB_TRX_ID（6 字节）：最近一次插入或更新该行的事务 ID；删除在内部也视作更新，并打上删除标记
DB_ROLL_PTR（7 字节）：回滚指针，指向 undo log，从而能重建更新前的行内容
DB_ROW_ID（6 字节）：单调递增的行 ID；仅在没有合适主键、需要自动生成聚簇索引时进入索引结构

undo 又分为 insert undo 与 update undo：insert undo 在事务提交后即可丢弃；update undo 还要服务一致性读，只有当不再存在「可能需要该历史版本」的读视图事务时，才能清理。这也是「长事务拖垮 undo / 历史版本膨胀」的根因。

一致性非锁定读（Consistent Nonlocking Read）

在 READ COMMITTED 与 REPEATABLE READ 下，普通 SELECT 默认走 一致性读：

查询看到某个时间点之前已提交事务所做的修改
看不到之后提交或未提交事务的修改
例外：同一事务内更早语句自己写过的变更，当前事务能看见

一致性读 不在表上加读锁，因此其他会话可以同时改这些表——这就是 MVCC 带来的读写并发。

快照时机是理解 RR / RC 差异的关键：

REPEATABLE READ：事务内第一次一致性读建立快照，后续普通 SELECT 复用同一快照，彼此一致
READ COMMITTED：事务内每一次一致性读都建立并读取新的快照

因此在 RR 下，「同一事务里两次 SELECT 结果一样」是默认语义；在 RC 下，「读到别人已提交的新数据」是默认语义。

官方还特别提醒：快照主要作用于事务内的 SELECT，不一定约束 UPDATE/DELETE 的目标行集合。在 RR 中可能出现：

-- 会话 A：REPEATABLE READ
SELECT COUNT(*) FROM t1 WHERE c1 = 'xyz'; -- 0
DELETE FROM t1 WHERE c1 = 'xyz'; -- 却可能删掉其他事务刚提交的多行
SELECT COUNT(*) FROM t1 WHERE c1 = 'xyz'; -- 仍可能是 0（普通 SELECT 仍看旧快照）

也就是说：写路径看到的是“当前最新可提交状态 + 锁”，读路径在 RR 下仍可能停在旧快照。混用「普通 SELECT 决策 + DML」时，要意识到二者语义不同；需要当前读时用 SELECT ... FOR UPDATE / FOR SHARE。

加锁读与间隙：幻读如何被挡住

普通 SELECT 是快照读；下列语句是 locking read / 当前读：

SELECT ... FOR UPDATE / SELECT ... FOR SHARE
UPDATE / DELETE（以及会读取并锁定目标行的 DML）

在 REPEATABLE READ 下（官方）：

唯一索引 + 唯一等值条件：通常只锁住找到的索引记录，不锁前面的 gap
其他搜索条件（范围、非唯一等）：扫描范围内使用 gap lock 或 next-key lock，阻止其他会话向间隙中插入

Next-key lock = 索引记录锁 + 该记录之前间隙上的 gap lock。官方用幻读例子说明：若只锁已有记录、不锁间隙，其他事务可在范围中间插入新行，导致同一事务再次查询出现「幻影行」。InnoDB 通过 next-key 算法抑制这类插入。

在 READ COMMITTED 下（官方）：

锁定读一般只锁 index record，不锁 gap，因此允许在已锁记录旁插入新行
gap 锁主要用于外键检查与重复键检查
因为 gap 锁关闭，可能出现幻读
另有工程意义：UPDATE/DELETE 对 不匹配 WHERE 的行 会在评估后释放锁，死锁概率通常更低；但死锁仍可能发生

SERIALIZABLE 不是「神秘黑盒」

官方定义很明确：SERIALIZABLE 类似 REPEATABLE READ，但当 autocommit 关闭 时，InnoDB 会把普通 SELECT 隐式转换成 SELECT ... FOR SHARE。若 autocommit 开启，单条 SELECT 本身就是只读事务，可走一致性非锁定读而不必阻塞。

因此：

想用 SERIALIZABLE 做「读也要挡住别人改」：确保在显式事务中（关闭 autocommit）
它会显著增加锁竞争，只适合 XA、强一致性专项场景，不适合默认全库开启

实践：如何查看、设置与正确选用

查看与设置隔离级别

-- 查看（MySQL 8 推荐系统变量）
SELECT @@GLOBAL.transaction_isolation, @@SESSION.transaction_isolation;

-- 仅影响下一笔未开始的事务
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 影响当前会话后续事务
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 影响新连接的默认（需权限）
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

也可在配置文件中设置服务端默认：

[mysqld]
transaction-isolation = READ-COMMITTED

（选项值使用连字符形式，如 REPEATABLE-READ。）

访问模式还可设为 READ ONLY / READ WRITE，只读事务有助于引擎做优化，适合报表会话。

业务选型建议（工程向）

默认保持 REPEATABLE READ
- 账户余额校验 + 扣减、库存预占、需要「事务内多次普通读一致」的流程更自然
- 范围更新/删除配合索引时，要注意 gap/next-key 带来的插入阻塞
高并发、写多读多、能接受「读到最新已提交」时考虑 READ COMMITTED
- 常见于互联网业务减少间隙锁、降低死锁
- 必须接受：同一事务内两次普通读可能不同；幻读可能发生
- 官方要求 RC 下二进制日志实质走 row-based（MIXED 时会自动切 row）
需要「读到的行在事务期间不被别人改」
- 不要只靠普通 SELECT 的 RR 快照（别人仍可改，你只是看不见）
- 使用 SELECT ... FOR UPDATE（要改）或 FOR SHARE（共享读）明确当前读
避免长事务
- 官方建议即使是只做一致性读的事务也要及时提交，否则 update undo 无法回收，回滚段膨胀
- 长事务还会拉长锁持有时间，放大死锁与锁等待

可复现的小实验（建议在测试库）

准备：

CREATE TABLE account (
 id INT PRIMARY KEY,
 balance INT NOT NULL
) ENGINE=InnoDB;
INSERT INTO account VALUES (1, 100), (2, 200);

实验 A：RR 下快照读

-- 会话 1
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT balance FROM account WHERE id = 1; -- 100

-- 会话 2
UPDATE account SET balance = 90 WHERE id = 1;
COMMIT;

-- 会话 1
SELECT balance FROM account WHERE id = 1; -- 仍为 100（复用首次快照）
COMMIT;
SELECT balance FROM account WHERE id = 1; -- 提交后新事务可见 90

实验 B：需要当前读时加锁

START TRANSACTION;
SELECT balance FROM account WHERE id = 1 FOR UPDATE; -- 当前读 + X 锁
-- 业务校验 balance >= 10 后再扣减
UPDATE account SET balance = balance - 10 WHERE id = 1;
COMMIT;

实验 C：范围条件与插入阻塞（RR）

-- 会话 1
START TRANSACTION;
SELECT * FROM account WHERE id >= 1 FOR UPDATE; -- 范围 + next-key/gap

-- 会话 2
INSERT INTO account VALUES (3, 50); -- 往往会等待会话 1 提交

把 FOR UPDATE 换成普通 SELECT 时，会话 2 通常可以插入（快照读不加锁），这能直观区分「看不见」和「锁住」。

常见坑与排查

1. 用普通 SELECT 做决策，却期望互斥

快照读不互斥。库存/余额扣减必须：

事务内 SELECT ... FOR UPDATE 再更新，或
直接条件更新并检查影响行数：UPDATE ... WHERE id=? AND balance>=?

仅靠 RR 的「两次 SELECT 一样」不能防止超卖。

2. 唯一等值 vs 范围：锁范围差很多

官方写明：RR 下唯一索引等值命中通常只锁记录；范围或非唯一条件会锁间隙。排查「插入被堵住」时，先看 SQL 是否走了范围扫描、索引是否合适。

3. RR 下「SELECT 看不到，DELETE 却删到了」

这是官方明确描述过的快照读与 DML 当前读差异，不是玄学 bug。审计日志或对账逻辑要按「语句类型」理解可见性。

4. 死锁：隔离级别救不了写写冲突

官方指出：死锁可能性与隔离级别无直接关系——隔离级别主要改读行为，而死锁来自写锁互相等待。处理要点：

保持默认死锁检测开启（innodb_deadlock_detect）
死锁发生时 InnoDB 会回滚其中一个事务（victim），应用必须可重试
关闭检测时依赖 innodb_lock_wait_timeout，代价是更长的等待
用 SHOW ENGINE INNODB STATUS 查看最近一次死锁
工程上：固定多表/多行加锁顺序、缩短事务、给 WHERE 列建合适索引

5. 历史版本与「undo 涨爆」

长查询、忘记提交的会话、超大事务都会让 update undo 滞留。监控 undo 表空间、历史列表长度，并在应用层强制事务超时/连接回收。

6. 混用锁定读与非锁定读

官方不建议在同一 RR 事务里混用大量「普通 SELECT」与 UPDATE/SELECT ... FOR UPDATE，因为二者看到的状态基准不同，逻辑难推理；若目标接近串行，应显式使用加锁读或评估 SERIALIZABLE。

总结

InnoDB 默认 REPEATABLE READ，普通读靠 MVCC 快照，写与加锁读靠 行锁 +（RR 下）gap/next-key。
RC 每次一致性读换新快照、锁定读基本不锁 gap，并发更好但幻读与不可重复读更易出现。
SERIALIZABLE 在关闭 autocommit 时把普通 SELECT 变成 FOR SHARE，代价是锁竞争。
工程上优先：短事务、正确索引、该当前读就 FOR UPDATE、死锁可重试；不要把「提高隔离级别」当成唯一药方。
理解「快照读 vs 当前读」比背诵四个级别名称更能减少线上数据竞争事故。

参考资料

MySQL 8.4 Reference Manual — Transaction Isolation Levels
MySQL 8.0 Reference Manual（Oracle Docs）— InnoDB Multi-Versioning
MySQL 8.0 Reference Manual — Consistent Nonlocking Reads
MySQL 8.0 Reference Manual — InnoDB Locking
MySQL 8.0 Reference Manual — Phantom Rows
MySQL 8.0 Reference Manual — Deadlocks in InnoDB
MySQL 8.0 Reference Manual — SET TRANSACTION Statement
MariaDB Knowledge Base — SET TRANSACTION（辅助对照 InnoDB 兼容实现）

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

Mon, 13 Jul 2026 00:00:00 +0800

在高并发系统里，Redis 常常被放在数据库前面做读加速。一旦缓存设计不当，问题往往不是“Redis 慢一点”，而是数据库被瞬间打穿。工程上最常见、也最容易被混为一谈的三类故障是：缓存穿透、缓存击穿和缓存雪崩。

这三类问题听起来相似，根因却不同：

问题	典型特征	直接伤害
缓存穿透	查的是不存在的数据，缓存和 DB 都没有	恶意或异常请求反复打到 DB
缓存击穿	某个热点 key 刚好过期	同一时刻大量请求打到 DB
缓存雪崩	大量 key 同时失效，或缓存层整体不可用	系统级读流量直接压垮 DB

本文从现象、根因、可落地方案三层拆开，并结合 Redis 官方能力（SET 的 NX/EX、EXPIRE、淘汰策略、分布式锁模式）给出可复用实践。

一、先把请求路径画清楚

一个典型读路径是：

Client -> App -> Redis -> (miss) -> Database -> write back Redis -> response

缓存层的价值在于：

把高频读从数据库剥离出来；
用更低延迟响应热点数据；
给数据库争取容量和稳定性。

因此，任何“绕过缓存直接打 DB”的路径，都要被当成故障设计点来处理。

二、缓存穿透：查不存在的数据

1. 现象

请求的 key 在业务上不存在，例如：

用户 ID -1
商品 ID 999999999
被爬虫扫出来的非法参数

此时 Redis 没有缓存，数据库也查不到记录。如果应用只在“查到结果时才写缓存”，那么每次请求都会落到数据库。

2. 根因

穿透的本质不是“缓存过期”，而是：

空结果没有被负缓存（negative caching）保护。

3. 解法

方案 A：缓存空对象（最常用）

查库为空时，也写入一个短 TTL 的空值标记：

# 伪命令：空结果缓存 60 秒
SET product:999999999 __NULL__ EX 60

应用读到 __NULL__ 时直接返回“不存在”，不再访问数据库。

注意：

TTL 不要太长，避免真实数据刚创建后长时间读不到；
空值要有统一约定，避免和正常业务值冲突；
对写路径做缓存失效/更新，保证最终一致。

方案 B：布隆过滤器（Bloom Filter）前置拦截

对“可能存在”的 ID 集合做布隆过滤器：

数据写入时同步/异步加入过滤器；
查询前先判断“一定不存在还是可能存在”；
一定不存在则直接拒绝，不打 Redis/DB。

适合海量 ID、爬虫扫描、开放查询接口。代价是：

有极低误判率（把不存在判断成可能存在）；
需要维护过滤器更新与扩容。

方案 C：参数与权限校验前置

很多穿透其实是脏流量：

非数字 ID
超范围分页
未登录却访问私有资源

在网关/应用入口直接拦截，比把压力交给缓存更划算。

三、缓存击穿：热点 key 刚好失效

1. 现象

某个非常热的 key（首页配置、秒杀库存视图、热门商品详情）在某一瞬间过期。
下一毫秒，成千上万请求同时看到 miss，一起去查数据库，形成“单点热点打穿”。

2. 根因

击穿关注的是：

单个热点 key 过期窗口内的并发回源。

它和穿透不同：数据本来存在，只是缓存刚好空了。

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

只有一个请求负责回源重建，其他请求等待或短暂失败重试。

Redis 官方 SET 支持原子条件写入，可用 NX + EX 做互斥：

# 抢重建锁，5 秒自动过期，防止进程崩溃后死锁
SET rebuild:lock:product:1001 1 NX EX 5

流程：

读缓存 miss；
SET lock NX EX 抢锁；
抢到锁的请求查 DB，写回缓存，释放锁；
没抢到锁的请求短暂 sleep/重试读缓存，或返回旧兜底。

官方文档明确：SET key value NX EX seconds 是设置值并带过期时间的常用原子写法；SETNX 在新代码中更推荐用 SET ... NX 替代。

方案 B：逻辑过期（logical expire）

缓存 value 内嵌业务过期时间，物理 key 不过期或过期很久：

{
 "data": {"id": 1001, "price": 99},
 "expireAt": 1720857600
}

读取时：

未逻辑过期：直接返回；
已逻辑过期：返回旧数据，同时异步触发重建。

优点是用户几乎无感 miss；代价是要接受短暂脏读，并做好异步重建失败补偿。

方案 C：热点 key 永不过期 + 主动更新

对真正的超级热点，不依赖 TTL 被动失效，而由写路径/定时任务主动更新。
TTL 更适合普通数据；热点数据更适合“写时更新 + 监控”。

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

两类雪崩最常见：

过期雪崩：大量 key 在同一时间点过期；
可用性雪崩：Redis 集群故障、网络分区、连接打满，导致缓存层整体不可用。

结果都是数据库在短时间内接到远超容量的读请求。

2. 根因

雪崩的核心不是某一个 key，而是：

缓存保护面在同一时间失效，流量失去缓冲层。

3. 解法

方案 A：TTL 加随机抖动

不要让同类数据使用完全相同的过期时间：

ttl = base_ttl + random(0, jitter)
# 例如 3600 + random(0, 300)

这样可以把过期曲线打散，避免整点集体回源。

方案 B：多级缓存与本地缓存

本地 Caffeine/Guava Cache 挡住进程内重复读；
Redis 作为分布式缓存；
DB 作为最终数据源。

本地缓存 TTL 更短，可显著降低 Redis 抖动对 DB 的传导。

方案 C：限流、熔断、降级

缓存层异常时，应用不能无脑回源：

对回源 QPS 做令牌桶/漏桶限流；
数据库错误率升高时熔断；
非核心接口返回兜底页/默认配置；
核心读接口优先返回短暂旧数据。

方案 D：正确使用 Redis 内存淘汰策略

当 Redis 用作缓存时，官方建议配置最大内存和淘汰策略，以便内存触顶时按策略驱逐 key，而不是写失败或无规划崩溃。常见策略包括：

allkeys-lru / allkeys-lfu：在全部 key 中淘汰；
volatile-lru / volatile-lfu / volatile-ttl：只在设置了过期时间的 key 中淘汰。

关键点：

缓存场景应显式设置 maxmemory；
按业务选择 LRU/LFU；
监控 evicted_keys、命中率、内存使用，避免“默默淘汰关键数据”却无人知晓。

淘汰策略解决的是内存压力下的可持续性，不能替代业务层的穿透/击穿防护，但能降低缓存层自身失控概率。

五、一套可落地的组合策略

真实系统很少只选一种方案，更常见的是分层组合：

1. 入口校验：挡住非法参数
2. 布隆过滤器/存在性索引：挡住明显不存在的 key
3. Redis 读：命中则返回
4. miss 时：
 - 热点 key：互斥重建或逻辑过期
 - 普通 key：允许有限并发回源
5. DB 空结果：写短 TTL 空缓存
6. DB 有结果：写缓存，TTL 加抖动
7. 全链路：限流 + 熔断 + 监控告警

伪代码示例

def get_product(product_id: str):
 if not valid_id(product_id):
 return None

 if bloom and not bloom.might_contain(product_id):
 return None

 cached = redis.get(f"product:{product_id}")
 if cached == "__NULL__":
 return None
 if cached is not None:
 return decode(cached)

 # 热点互斥重建
 locked = redis.set(f"rebuild:lock:product:{product_id}", "1", nx=True, ex=5)
 if not locked:
 time.sleep(0.05)
 return get_product(product_id) # 简化：重试读缓存

 try:
 row = db.query_product(product_id)
 if row is None:
 redis.set(f"product:{product_id}", "__NULL__", ex=60)
 return None
 redis.set(f"product:{product_id}", encode(row), ex=3600 + random.randint(0, 300))
 return row
 finally:
 redis.delete(f"rebuild:lock:product:{product_id}")

说明：

SET ... NX EX 用于短锁，避免击穿时并发回源；
空值缓存用于防穿透；
TTL 抖动用于打散过期，降低雪崩概率。

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

Redis 命中率是否骤降
Redis 连接数/超时是否升高
数据库 QPS、慢查询、连接池是否打满
是否集中在某几个 key，还是大面积 key

2. 判断路径

观察	更可能是
大量非法/不存在 ID，DB 查空很多	穿透
单个热 key 流量尖峰，过期瞬间 DB 飙升	击穿
整点或批次任务后大面积 miss	过期雪崩
Redis 超时/主从切换/集群异常同时发生	可用性雪崩

3. 临时止血

对异常查询参数限流；
对热点 key 预热并临时延长 TTL；
打开空值缓存；
给 DB 回源加总开关/配额；
非核心读降级。

七、设计原则总结

缓存不是数据库的影子，是保护层。 任何 miss 路径都要有预算。
空结果也是结果。 不做负缓存，就容易被穿透。
热点不能靠“碰巧没过期”。 要有互斥重建、逻辑过期或主动更新。
过期时间要工程化。 相同 TTL 是雪崩温床，抖动是基本操作。
缓存故障要有降级。 没有限流和熔断的缓存架构，只是把风险延后到数据库。
可观测性比“感觉很快”更重要。 命中率、回源 QPS、淘汰数、锁竞争都要可监控。

八、什么时候不该过度设计

不是所有系统都要上布隆过滤器 + 逻辑过期 + 多级缓存：

读 QPS 不高、数据几乎都存在：做好空值缓存和基础 TTL 即可；
写极少、读极多的配置类数据：适合主动更新 + 较长 TTL；
强一致要求极高的余额/库存：缓存只能做辅助，核心以数据库/专用组件为准，并明确一致性模型。

架构选择应匹配流量模型和一致性要求，而不是堆名词。

总结

缓存穿透、击穿、雪崩并不是三个神秘黑话，而是三条清晰的失败路径：

穿透：不存在的数据反复打穿 DB；
击穿：热点 key 失效瞬间被并发打穿；
雪崩：保护面大面积失效，流量失去缓冲。

把问题定义清楚后，解法会自然收敛到：入口校验、空值缓存、互斥重建、TTL 抖动、淘汰策略、限流熔断与监控。
Redis 提供了 SET NX/EX、EXPIRE、内存淘汰和分布式锁模式等基础能力，但真正决定系统稳不稳的，是你有没有把这些能力嵌进完整的读路径设计里。

参考资料

Redis 官方文档：SET 命令（含 NX / EX 等选项）
Redis 官方文档：EXPIRE 命令
Redis 官方文档：SETNX 命令
Redis 官方文档：Key eviction 内存淘汰策略
Redis 官方文档：Distributed locks 分布式锁模式

MySQL深度调优实战：从SQL到架构的全面优化

Fri, 26 Jun 2026 17:00:00 +0000

前言

MySQL 是最流行的关系型数据库之一，但在生产环境中，性能问题往往是开发和运维面临的最大挑战。本文将从 SQL 优化、索引设计、配置调优、架构优化四个维度，全面介绍 MySQL 性能调优的实战技巧。

一、SQL 优化

1.1 EXPLAIN 执行计划分析

EXPLAIN SELECT * FROM users WHERE age > 25 AND city = 'Beijing';

关键字段说明：

字段	说明	优化目标
type	访问类型	至少达到 range 级别
key	使用的索引	避免 NULL
rows	扫描行数	越小越好
Extra	额外信息	避免 Using filesort/temporary

type 访问类型（从好到差）：

system > const > eq_ref > ref > range > index > ALL

1.2 索引优化技巧

最左前缀原则

-- 联合索引 (a, b, c)
-- ✅ 命中索引
SELECT * FROM table WHERE a = 1;
SELECT * FROM table WHERE a = 1 AND b = 2;
SELECT * FROM table WHERE a = 1 AND b = 2 AND c = 3;

-- ❌ 无法使用索引
SELECT * FROM table WHERE b = 2;
SELECT * FROM table WHERE c = 3;
SELECT * FROM table WHERE b = 2 AND c = 3;

覆盖索引

-- 创建覆盖索引
ALTER TABLE users ADD INDEX idx_name_age (name, age);

-- 查询只需要索引字段，无需回表
SELECT name, age FROM users WHERE name = 'John';

索引失效场景

-- ❌ 函数操作
SELECT * FROM users WHERE YEAR(create_time) = 2024;
-- ✅ 改为范围查询
SELECT * FROM users WHERE create_time >= '2024-01-01' 
 AND create_time < '2025-01-01';

-- ❌ 隐式类型转换
SELECT * FROM users WHERE phone = 13800138000;
-- ✅ 类型匹配
SELECT * FROM users WHERE phone = '13800138000';

-- ❌ LIKE 左模糊
SELECT * FROM users WHERE name LIKE '%John';
-- ✅ 前缀匹配
SELECT * FROM users WHERE name LIKE 'John%';

-- ❌ OR 条件
SELECT * FROM users WHERE age = 25 OR name = 'John';
-- ✅ 使用 UNION
SELECT * FROM users WHERE age = 25
UNION
SELECT * FROM users WHERE name = 'John';

1.3 查询优化

分页查询优化

-- ❌ 慢查询（深分页）
SELECT * FROM orders ORDER BY id LIMIT 1000000, 10;

-- ✅ 延迟关联
SELECT o.* FROM orders o
INNER JOIN (
 SELECT id FROM orders ORDER BY id LIMIT 1000000, 10
) t ON o.id = t.id;

-- ✅ 游标分页
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 10;

JOIN 优化

-- 确保关联字段有索引
ALTER TABLE orders ADD INDEX idx_user_id (user_id);

-- 小表驱动大表
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

子查询优化

-- ❌ 子查询
SELECT * FROM orders WHERE user_id IN (
 SELECT id FROM users WHERE status = 1
);

-- ✅ JOIN 优化
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

二、索引设计原则

2.1 索引设计规范

-- 1. 选择区分度高的列
SELECT 
 COUNT(DISTINCT city) / COUNT(*) AS selectivity
FROM users;
-- 区分度 > 0.1 才考虑建索引

-- 2. 联合索引字段顺序
-- 区分度高的字段在前
-- 查询频率高的字段在前
-- 排序字段在最后

-- 3. 避免过多索引
-- 每张表索引不超过 5 个
-- 单个索引字段不超过 5 个

2.2 索引监控

-- 查看索引使用情况
SELECT 
 object_schema,
 object_name,
 index_name,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
ORDER BY count_read DESC;

-- 查看未使用的索引
SELECT 
 object_schema,
 object_name,
 index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
 AND index_name IS NOT NULL
 AND count_star = 0;

三、配置调优

3.1 InnoDB Buffer Pool

# my.cnf
[mysqld]
# Buffer Pool 大小，建议物理内存的 70-80%
innodb_buffer_pool_size = 8G

# Buffer Pool 实例数，减少锁竞争
innodb_buffer_pool_instances = 8

# Buffer Pool 预热
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

3.2 日志配置

[mysqld]
# Redo Log 大小
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# 刷盘策略
# 1：每次提交都刷盘（最安全）
# 2：每次提交写入OS缓存
# 0：每秒刷盘
innodb_flush_log_at_trx_commit = 1

# 双1配置（生产推荐）
sync_binlog = 1

3.3 连接配置

[mysqld]
# 最大连接数
max_connections = 500

# 连接超时
wait_timeout = 600
interactive_timeout = 600

# 线程缓存
thread_cache_size = 64

# 表缓存
table_open_cache = 4096
table_definition_cache = 2048

3.4 查询缓存（MySQL 8.0 已移除）

# MySQL 5.7 及以下
[mysqld]
query_cache_type = 0 # 建议关闭
query_cache_size = 0

3.5 排序和临时表

[mysqld]
# 排序缓冲区
sort_buffer_size = 4M

# JOIN 缓冲区
join_buffer_size = 4M

# 临时表大小
tmp_table_size = 64M
max_heap_table_size = 64M

# 读缓冲区
read_buffer_size = 2M
read_rnd_buffer_size = 8M

四、架构优化

4.1 读写分离

 ┌─────────────┐
 │ 应用程序 │
 └──────┬──────┘
 │
 ┌──────▼──────┐
 │ 代理层 │
 │ (ProxySQL) │
 └──────┬──────┘
 │
 ┌──────────────┼──────────────┐
 │ │ │
 ┌──────▼──────┐ ┌────▼────┐ ┌───────▼──────┐
 │ Master │ │ Slave 1 │ │ Slave 2 │
 │ (写) │ │ (读) │ │ (读) │
 └─────────────┘ └─────────┘ └──────────────┘

ProxySQL 配置示例：

-- 添加后端MySQL服务器
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, '10.0.0.1', 3306), -- 写组
(20, '10.0.0.2', 3306), -- 读组
(20, '10.0.0.3', 3306); -- 读组

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup) VALUES
(1, '^SELECT.*FOR UPDATE', 10), -- 写操作
(2, '^SELECT', 20); -- 读操作

4.2 分库分表

垂直分库

用户库 (user_db)
├── users
├── user_profiles
└── user_settings

订单库 (order_db)
├── orders
├── order_items
└── payments

商品库 (product_db)
├── products
├── categories
└── inventory

水平分表

-- 按用户ID分表
orders_0 -- user_id % 4 = 0
orders_1 -- user_id % 4 = 1
orders_2 -- user_id % 4 = 2
orders_3 -- user_id % 4 = 3

-- ShardingSphere 配置
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.sharding.tables.orders.actual-data-nodes=ds$->{0..1}.orders_$->{0..3}
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.algorithm-expression=orders_$->{user_id % 4}

4.3 缓存策略

┌──────────┐ ┌──────────┐ ┌──────────┐
│ 应用程序 │───▶│ Redis │───▶│ MySQL │
└──────────┘ └──────────┘ └──────────┘
 │ │ │
 │ 1.查询缓存 │ │
 │──────────────▶│ │
 │ 2.返回缓存 │ │
 │◀──────────────│ │
 │ │ │
 │ 3.缓存未命中│ │
 │──────────────────────────────▶│
 │ 4.查询数据库│ │
 │◀──────────────────────────────│
 │ │ │
 │ 5.写入缓存 │ │
 │──────────────▶│ │

缓存更新策略：

// Cache Aside Pattern
public User getUser(Long userId) {
 // 1. 先查缓存
 String key = "user:" + userId;
 User user = redis.get(key);
 if (user != null) {
 return user;
 }
 
 // 2. 缓存未命中，查数据库
 user = userMapper.selectById(userId);
 if (user != null) {
 // 3. 写入缓存
 redis.setex(key, 3600, user);
 }
 return user;
}

4.4 表设计优化

-- 1. 选择合适的数据类型
-- ❌ 不推荐
CREATE TABLE users (
 id BIGINT,
 name VARCHAR(1000),
 age INT,
 status VARCHAR(20)
);

-- ✅ 推荐
CREATE TABLE users (
 id BIGINT UNSIGNED AUTO_INCREMENT,
 name VARCHAR(50) NOT NULL,
 age TINYINT UNSIGNED,
 status TINYINT NOT NULL DEFAULT 1,
 PRIMARY KEY (id),
 INDEX idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 避免NULL
-- 使用 NOT NULL + DEFAULT

-- 3. 主键设计
-- 使用自增ID作为主键
-- 避免使用UUID作为主键（无序，影响插入性能）

五、监控与诊断

5.1 慢查询日志

[mysqld]
# 开启慢查询日志
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 超过1秒记录
log_queries_not_using_indexes = ON

# 分析慢查询日志
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 使用 pt-query-digest
pt-query-digest /var/log/mysql/slow.log > slow_report.txt

5.2 性能监控SQL

-- 查看当前连接
SHOW PROCESSLIST;

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS;

-- 查看表大小
SELECT 
 table_schema,
 table_name,
 ROUND(data_length / 1024 / 1024, 2) AS data_mb,
 ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'your_database'
ORDER BY data_length DESC;

-- 查看索引使用统计
SELECT 
 object_schema,
 object_name,
 index_name,
 count_star,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database';

5.3 诊断工具

# Percona Toolkit
# 安装
apt install percona-toolkit

# 分析慢查询
pt-query-digest /var/log/mysql/slow.log

# 检查重复/冗余索引
pt-duplicate-key-checker --host=localhost --user=root --password=xxx

# 查看索引使用情况
pt-index-usage --host=localhost --user=root --password=xxx /var/log/mysql/slow.log

六、调优清单

6.1 SQL 层面

所有查询都使用了合适的索引
避免了 SELECT *，只查询需要的字段
分页查询使用了延迟关联
避免了深分页（LIMIT offset 过大）
JOIN 查询关联字段有索引
避免了索引失效的写法

6.2 索引层面

高频查询字段都有索引
联合索引遵循最左前缀原则
区分度低的字段不建索引
定期清理未使用的索引
使用覆盖索引减少回表

6.3 配置层面

Buffer Pool 设置为物理内存的 70-80%
开启慢查询日志
设置合理的连接数
配置合适的日志刷盘策略

6.4 架构层面

读写分离（读多写少场景）
分库分表（数据量大场景）
引入缓存层（热点数据）
表设计规范化

总结

MySQL 调优是一个系统工程，需要从多个维度综合考虑：

SQL 优化是基础：写好 SQL 是最直接的优化手段
索引设计是核心：合理的索引能提升查询性能数倍
配置调优是保障：正确的配置能最大化硬件利用率
架构优化是根本：当单机瓶颈时，架构扩展是必由之路

建议按照本文的调优清单逐步检查，结合监控数据持续优化。

达梦数据库 DM8 与 MySQL 差异全解析：迁移避坑指南

Wed, 24 Jun 2026 11:00:00 +0000

前言

随着国内信创（信息技术应用创新）政策的推进，越来越多的项目需要从 MySQL 迁移到国产数据库。达梦数据库（DM8） 是最主流的国产关系型数据库之一，兼容大部分 SQL 标准，但与 MySQL 在语法、函数、数据类型等方面仍存在不少差异。

本文从实际迁移角度出发，系统梳理 DM8 与 MySQL 的核心差异，帮助开发者少踩坑。

1. 架构差异

对比项	MySQL	达梦 DM8
数据库模型	单实例多数据库（`database`）	单数据库多 Schema（一个用户对应一个 Schema）
默认端口	3306	5236
存储引擎	InnoDB / MyISAM 等可选	单一存储引擎
大小写	默认不区分（可配置）	默认区分大小写
空字符串	`''` 和 `NULL` 是不同的	`''` 等同于 `NULL`

⚠️ 重点注意：DM8 中空字符串 '' 就是 NULL，这是迁移中最容易踩的坑。MySQL 中 WHERE col = '' 和 WHERE col IS NULL 结果完全不同，在 DM8 中两者等价。

2. 数据类型映射

2.1 数值类型

MySQL	DM8	说明
`TINYINT`	`TINYINT`	兼容
`SMALLINT`	`SMALLINT`	兼容
`MEDIUMINT`	`INT`	DM 无 MEDIUMINT
`INT`	`INTEGER`	兼容
`BIGINT`	`BIGINT`	兼容
`FLOAT`	`FLOAT`	兼容
`DOUBLE`	`DOUBLE` / `NUMBER`	建议用 DOUBLE
`DECIMAL(p,s)`	`NUMBER(p,s)`	精度一致

2.2 字符串类型

MySQL	DM8	说明
`CHAR(n)`	`CHAR(n)`	兼容
`VARCHAR(n)`	`VARCHAR2(n)`	DM 推荐用 VARCHAR2
`TEXT`	`CLOB`	大文本用 CLOB
`MEDIUMTEXT`	`CLOB`
`LONGTEXT`	`CLOB`
`ENUM`	`VARCHAR2`	DM 无 ENUM，存为字符串
`SET`	`VARCHAR2`	DM 无 SET

2.3 日期时间类型

MySQL	DM8	说明
`DATE`	`DATE`	MySQL 只存日期，DM 的 DATE 包含时间
`DATETIME`	`DATE` / `TIMESTAMP`	DM 的 DATE 就带时间
`TIMESTAMP`	`TIMESTAMP`
`TIME`	`TIME`	DM 支持 TIME 类型，可直接映射
`YEAR`	`CHAR(4)`	DM 无 YEAR 类型

2.4 其他类型

MySQL	DM8	说明
`BLOB`	`BLOB`	兼容
`JSON`	`CLOB` / `JSONB`（新版本）	旧版用 CLOB 存储
`BOOLEAN`	`BIT`
`AUTO_INCREMENT`	`IDENTITY(1,1)`	自增语法不同

3. 函数差异对照

这是迁移中改动量最大的部分。

3.1 字符串函数

MySQL	DM8	示例
`CONCAT(a, b)`	`a \|\| b` 或 `CONCAT(a, b)`	DM 推荐用 `\|\|`
`SUBSTRING(str, pos, len)`	`SUBSTR(str, pos, len)`	少了个 `ING`
`LOCATE(sub, str)`	`INSTR(str, sub)`	参数顺序相反
`GROUP_CONCAT(col)`	`LISTAGG(col, ',') WITHIN GROUP (ORDER BY col)`	语法差异大
`REPLACE(str, old, new)`	`REPLACE(str, old, new)`	兼容

3.2 日期函数

MySQL	DM8	示例
`NOW()`	`SYSDATE` 或 `CURRENT_TIMESTAMP`
`CURDATE()`	`CURRENT_DATE` 或 `SYSDATE`
`DATE_FORMAT(d, '%Y-%m-%d')`	`TO_CHAR(d, 'YYYY-MM-DD')`	格式化语法不同
`STR_TO_DATE(s, '%Y-%m-%d')`	`TO_DATE(s, 'YYYY-MM-DD')`
`DATE_ADD(d, INTERVAL 1 DAY)`	`d + 1` 或 `ADD_DAYS(d, 1)`
`DATE_SUB(d, INTERVAL 1 MONTH)`	`ADD_MONTHS(d, -1)`
`DATEDIFF(d1, d2)`	`d1 - d2`	DM 直接相减
`YEAR(d)`	`EXTRACT(YEAR FROM d)`
`MONTH(d)`	`EXTRACT(MONTH FROM d)`

3.3 条件与空值函数

MySQL	DM8	说明
`IF(cond, v1, v2)`	`CASE WHEN cond THEN v1 ELSE v2 END`	DM 无 IF 函数
`IFNULL(expr, default)`	`NVL(expr, default)`	也可用 COALESCE
`IFNULL` 多层嵌套	`COALESCE(a, b, c)`	推荐用 COALESCE

3.4 类型转换

MySQL	DM8	说明
`CONVERT(expr, type)`	`CONVERT(type, expr)`	参数顺序相反 ⚠️
`CAST(expr AS type)`	`CAST(expr AS type)`	兼容

4. SQL 语法差异

4.1 自增主键

-- MySQL
CREATE TABLE users (
 id BIGINT AUTO_INCREMENT PRIMARY KEY,
 name VARCHAR(100)
);

-- DM8
CREATE TABLE users (
 id BIGINT IDENTITY(1,1) PRIMARY KEY,
 name VARCHAR2(100)
);

4.2 分页查询

-- MySQL
SELECT * FROM users LIMIT 10 OFFSET 20;

-- DM8（兼容 LIMIT 或使用 ROWNUM）
SELECT * FROM users LIMIT 10 OFFSET 20;

-- DM8 传统写法
SELECT * FROM (
 SELECT t.*, ROWNUM rn FROM (
 SELECT * FROM users ORDER BY id
 ) t WHERE ROWNUM <= 30
) WHERE rn > 20;

DM8 较新版本已支持 LIMIT offset, count 语法，但 ROWNUM 仍是 DM 的保留关键字，不要用作列名。

4.3 多行插入

-- MySQL
INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

-- DM8
INSERT ALL
 INTO users (name) VALUES ('Alice')
 INTO users (name) VALUES ('Bob')
 INTO users (name) VALUES ('Charlie')
SELECT 1 FROM dual;

4.4 多表更新

-- MySQL
UPDATE t1, t2 SET t1.col = t2.col WHERE t1.id = t2.id;

-- DM8（使用 MERGE INTO）
MERGE INTO t1 USING t2 ON (t1.id = t2.id)
WHEN MATCHED THEN UPDATE SET t1.col = t2.col;

4.5 多表删除

-- MySQL
DELETE t1 FROM t1, t2 WHERE t1.id = t2.id AND t2.status = 0;

-- DM8
DELETE FROM t1 WHERE id IN (SELECT id FROM t2 WHERE status = 0);

4.6 修改列名

-- MySQL
ALTER TABLE users CHANGE name full_name VARCHAR(100);

-- DM8
ALTER TABLE users RENAME COLUMN name TO full_name;

4.7 删除列

-- MySQL
ALTER TABLE users DROP COLUMN age;

-- DM8
ALTER TABLE users DROP age;

5. GROUP BY 语义差异（重要！）

这是迁移中最容易出 bug 的地方。

5.1 MySQL 的宽松模式

MySQL 默认允许 SELECT 中出现未在 GROUP BY 中声明的非聚合列（ONLY_FULL_GROUP_BY 关闭时）：

-- MySQL 可以执行（但结果不确定）
SELECT id, name, COUNT(*) FROM users GROUP BY department;

5.2 DM8 的严格模式

DM8 严格执行 SQL 标准，SELECT 中的非聚合列必须出现在 GROUP BY 中：

-- DM8 必须这样写
SELECT department, COUNT(*) FROM users GROUP BY department;

5.3 GROUP BY 主键 ≠ DISTINCT

迁移时不要轻易把 GROUP BY id 改成 SELECT DISTINCT，当 JOIN 导致行数膨胀时，两者结果不同。

6. 其他语义陷阱

6.1 别名引用

-- MySQL：HAVING 可以引用 SELECT 别名
SELECT name AS alias_name, COUNT(*) AS cnt
FROM users GROUP BY alias_name HAVING cnt > 5;

-- DM8：HAVING 不能引用别名，必须用原始表达式
SELECT name AS alias_name, COUNT(*) AS cnt
FROM users GROUP BY name HAVING COUNT(*) > 5;

6.2 别名引号

-- MySQL：单引号
SELECT name AS '姓名' FROM users;

-- DM8：双引号
SELECT name AS "姓名" FROM users;

6.3 隐式类型转换

DM8 类型检查更严格，字符串列与数字比较会报错：

-- MySQL 可以执行（隐式转换）
SELECT * FROM users WHERE phone = 13800138000;

-- DM8 必须类型一致
SELECT * FROM users WHERE phone = '13800138000';

7. JDBC 连接配置

7.1 驱动配置

配置项	MySQL	DM8
驱动类	`com.mysql.cj.jdbc.Driver`	`dm.jdbc.driver.DmDriver`
JDBC URL	`jdbc:mysql://host:3306/db`	`jdbc:dm://host:5236`
默认端口	3306	5236

7.2 Hibernate / MyBatis 方言

# MySQL
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.jpa.database-platform=org.hibernate.dialect.MySQLDialect

# DM8
spring.datasource.driver-class-name=dm.jdbc.driver.DmDriver
spring.datasource.url=jdbc:dm://localhost:5236
spring.jpa.database-platform=dm.hibernate.dialect.DmDialect

7.3 指定 Schema

DM8 默认一个用户对应一个 Schema，连接时可以通过 JDBC 参数指定：

jdbc:dm://localhost:5236?schema=MY_SCHEMA

8. 建库注意事项

DM8 一个实例即对应一个数据库，字符集在实例初始化（dminit）阶段确定，之后不可更改，没有 MySQL 那样的 CREATE DATABASE ... CHARSET= 语句。务必在初始化时就选择 UTF-8：

# 初始化实例时指定字符集（CHARSET：0=GB18030，1=UTF-8，2=EUC-KR）
dminit PATH=/dm/data DB_NAME=mydb INSTANCE_NAME=mydb CHARSET=1 PAGE_SIZE=16

如果字符集选错，中文数据会出现乱码，且修改成本很高。

9. 迁移工具推荐

工具	方向	语言	特点
sql-dialect-adapter	MySQL ↔ DM	Java	SQL 方言自动转换，支持 6 个方向
MySQL2DM	MySQL → DM	Python	多线程数据迁移，自动类型映射
DM2MySQL	DM → MySQL	Go	企业级反向迁移工具
mysqltodmsqltransfer	MySQL → DM	Java	MyBatis 插件，运行时自动转换 SQL
DM 数据迁移工具 (DTS)	多种 → DM	GUI	达梦官方工具，图形化操作

10. 迁移检查清单

建库时选择 UTF-8 字符集
AUTO_INCREMENT 改为 IDENTITY(1,1)
VARCHAR 改为 VARCHAR2，TEXT 改为 CLOB
NOW() 改为 SYSDATE，DATE_FORMAT 改为 TO_CHAR
GROUP_CONCAT 改为 LISTAGG
IF() 改为 CASE WHEN
IFNULL() 改为 NVL()
检查所有 GROUP BY 语句是否符合严格模式
检查空字符串 '' 的业务逻辑（DM 中等同于 NULL）
检查隐式类型转换（字符串 vs 数字比较）
更新 JDBC 驱动和连接 URL
更新 ORM 方言配置（Hibernate / MyBatis）
测试分页查询是否兼容
测试多行 INSERT、多表 UPDATE/DELETE 语法

Docker 安装达梦 DM8

Tue, 28 Apr 2026 10:00:00 +0000

背景

近期开源项目 SmartAdmin 的很多用户反馈需要支持达梦数据库，现在将 docker 安装达梦数据库记录下来，以便让更多有需要的技术人员看到，节省时间。

1、提前准备

环境为：Linux 系统 CentOS 8，达梦数据库为达梦 DM8 版本，单机版。

2、下载达梦镜像

达梦官方下载地址为：eco.dameng.com/download/，可能已经不提供 Docker 镜像下载。

所以请从笔者百度网盘下载：

链接: pan.baidu.com/s/1SsQK7mlJ
提取码: d83h
下载文件：dm8_20240715_x86_rh6_rq_single.tar.zip

3、上传并解压

1）将 dm8_20240715_x86_rh6_rq_single.tar.zip 上传到 Linux 服务器 CentOS 中

2）将其解压：

unzip dm8_20240715_x86_rh6_rq_single.tar.zip

4、加载 DM8 镜像到 Docker 中

1）进入镜像 dm8_20240715_x86_rh6_rq_single.tar 文件所在目录

2）执行加载命令：

docker load -i dm8_20240715_x86_rh6_rq_single.tar

3）检查是否成功加载 DM8 镜像：

docker images

5、明确启动容器参数

端口 15236
容器名字 dm8
不开启大小写敏感 -e CASE_SENSITIVE=0
数据映射目录：/home/database/dm8/data
字符集 UTF-8 -e UNICODE_FLAG=1
实例名称 -e INSTANCE_NAME=dm8_smartadmin

最终明确启动参数如下：

docker run -dit \
-p 15236:5236 \
--restart=always \
--name dm8 \
--privileged=true \
-e PAGE_SIZE=16 \
-e LD_LIBRARY_PATH=/opt/dmdbms/bin \
-e EXTENT_SIZE=32 \
-e BLANK_PAD_MODE=1 \
-e LOG_SIZE=1024 \
-e UNICODE_FLAG=1 \
-e LENGTH_IN_CHAR=1 \
-e CASE_SENSITIVE=0 \
-e INSTANCE_NAME=dm8_smartadmin \
-v /home/database/dm8/data:/opt/dmdbms/data \
dm8_single:dm8_20240715_rev232765_x86_rh6_64

6、启动容器

将上面的启动参数命令进行执行，查看是否启动成功：

docker ps

7、启动/停止/重启

docker stop dm8
docker start dm8
docker restart dm8

8、进入容器

进入容器命令为：

docker exec -it dm8 bash

9、其他注意事项

Docker 镜像中数据库默认用户名/密码为 SYSDBA/SYSDBA001

数据库 on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

一、为什么会产生死元组

二、Autovacuum 的触发公式

三、先监控，再调参数

1. 找出死元组较多的表

2. 查看表与索引大小

3. 检查 Autovacuum 是否正在工作

四、针对热点大表做局部调优

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

2. 清理能力跟不上写入速度

3. 误把内部可复用空间当成故障

六、生产调优清单

总结

参考资料

PostgreSQL WAL、检查点与崩溃恢复：原理、参数与工程实践

问题背景：为什么不能每次提交都刷数据页？

核心原理：LSN、段文件、检查点与 REDO

1. LSN：日志里的“字节尺”

2. 段文件布局：pg_wal 里的 16MB 段

3. 检查点：恢复的“安全锚点”

4. 全页写（Full Page Writes）与页撕裂

提交耐久性：synchronous_commit 与 fsync

synchronous_commit（可会话级调整）

fsync（集群级，危险）

可复现观测实验（实验室）

1）看当前 WAL 与检查点统计

2）制造 WAL 并观察 LSN 前进

3）对比同步/异步提交延迟（概念实验）

4）强制检查点（仅实验）

工程调参与排错清单

恢复时间 vs 运行期 I/O

WAL 目录膨胀

wal_level 选型

硬件与虚假“写成功”

常见坑对照表

总结

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

问题背景：没有索引时，数据库在做什么

核心原理：为什么日常几乎都是 B-tree

B-tree 能加速哪些谓词

只有 B-tree 能“带着顺序”吐行

唯一性约束如何落地

扫描方式：同一条 SQL，三种常见“走路方式”

1）Index Scan：点查 / 高选择性范围

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

3）Index Only Scan：尽量不回表

覆盖索引与 INCLUDE

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

部分索引：只索引“值得索引”的子集

可复现实验：从建表到读懂 EXPLAIN

生产变更：CREATE INDEX CONCURRENTLY

常见坑与排查清单

工程实践建议（可直接落地）

总结

参考资料

OceanBase 从零开始：核心概念、上手路径，以及和 MySQL 的关键差异

一、先建立正确心智模型

1. MySQL 的常见心智模型

2. OceanBase 的心智模型

二、OceanBase 是什么

三、和 MySQL 的核心差异总览

四、架构差异：为什么它不像单机 MySQL

1. Shared-Nothing 集群

2. 多租户：最容易被 MySQL 同学忽略的概念

3. OBProxy / ODP：应用如何“像访问单机库一样”访问分布式库

五、连接差异：最容易踩坑的地方

1. Docker 体验环境（最简单）

2. 正式连接写法：用户名里有租户

直连 OBServer（默认端口常为 2881）

通过 ODP/OBProxy（默认端口常为 2883）

3. 客户端选择

六、从零上手：MySQL 同学 10 分钟路径

1. 看有哪些库

2. 创建业务库

3. 建表、写入、查询

4. 看建表细节时的“OceanBase 味道”

2. 段文件布局：`pg_wal` 里的 16MB 段

提交耐久性：`synchronous_commit` 与 `fsync`

`synchronous_commit`（可会话级调整）

`fsync`（集群级，危险）

`wal_level` 选型

覆盖索引与 `INCLUDE`

生产变更：`CREATE INDEX CONCURRENTLY`

4. `obd demo` 前自检清单

1. Kubernetes：`ob-operator`

1. 容器一直起不来 / 没有 `boot success!`

2. `2881` 端口冲突

5. `obd demo` 预检失败