#数据库
共 23 篇（全部 77 篇）
-
冷缓存、热缓存与"假磁盘"：同一台机器为什么能测出 10.9 GB/s 和 250 MB/s
同一台机器、同一条 SQL，能测出 10.9 GB/s 和 250 MB/s。差别不在数据库，在数据来自哪一层存储。四层缓存模型、三个自测数字、一份冷热对照脚本。
-
同一份 200 万行 CSV：DuckDB、PostgreSQL、SQLite 本地分析查询实测
2,000,000 行、93.6MB 的 CSV，三个引擎、三条聚合查询。DuckDB 单线程 14.6ms，PostgreSQL 并行 8 是 70ms，SQLite 766ms。附导入耗时、文件体积与选型边界。
-
逻辑复制做零停机升级：1M 行同步 1.6 秒，切换停顿 0.86 秒，附五个必踩的坑
PostgreSQL 14.24 到 18.6，逻辑复制全流程实测：初始同步 1.6s、20 秒写入压测下延迟 0 字节、切换停顿 0.86s。附 schema/序列/DDL 三个不同步问题与真实报错。
-
Python 连 PostgreSQL：连接比查询贵 40 倍，10 个线程反而比 1 个连接慢
psycopg3 与 asyncpg 实测：单连接 11184 qps，每次新建连接掉到 360 qps，10 线程比单连接慢 55%，asyncpg 10 连接并发 23601 qps。连接成本 p50 1.8ms。
-
读放大：一条返回 21 行的查询扫了 200 万行，代价是 351 倍
200 万行的表、10 万基数的 user_id。加索引前后：扫描行数 2 亿降到 0，缓冲区块 14720 降到 4，单查询 24.6ms 降到 0.07ms。附三条量化读放大的 SQL 与一个不成立的经验法则。
-
PostgreSQL 时间点恢复演练：pg_basebackup + WAL 归档 + recovery_target_time 的一次完整跑通
在 768 MB 的 postgres:18 容器里跑完一条完整的 PITR 链：0.75 秒、3.2 MB 的基线备份，128 MB 的 WAL 归档，3.22 秒把集群恢复到 DROP TABLE 之前。三次故意失败的恢复留下原始报错，也留下"备份成功不等于能恢复"的三个验收点。
-
Redis 持久化三选一：重启后丢多少、恢复要多久
同一份 20 万键数据，纯 RDB 崩溃丢 10000 条、AOF everysec 与 always 各丢 0 条；写入吞吐差 41 倍，文件体积差 3.69 倍，而重启恢复耗时几乎一样。四种数字全部来自 Docker 容器实测，含 AOF 重写前后的对照。
-
把 PostgreSQL 塞进 512MB 容器：shared_buffers、连接开销与 work_mem 的内存账本
512MB 的 --memory 配 384MB 的 shared_buffers，实测只撑得住 33 条连接，34 条起随机被 OOM 杀，35 条起每轮必挂。但 docker inspect 给出的是 OOMKilled=true 加退出码 0，容器没有退出，被杀的是 checkpointer 或 backend。文章给出连接数阶梯、每连接 3.2MB 私有内存的测法，以及按 --memory 反推 shared_buffers 上限的公式。
-
PostgreSQL 18 参数速查：默认值、生效方式、改哪一层
17 个常改参数在 18.6 上的默认值与 context，附一条导出当前值的 SQL、三种改法的差别，以及三个容易改错层的坑。
-
pg_dump / pg_restore 常用组合：六条命令与四个坑
六条常用 dump/restore 组合、并行参数的真实报错（-j 只支持目录格式）、以及 owner/权限/序列/已存在对象四个坑。
-
容器里跑 PostgreSQL 的 8 条纪律（每条都踩过）
挂载点、停止方式、内存上限、checksums、时区、端口——8 条来自真实故障的规矩，附两条真实 panic 日志与 OOM 数字。
-
PostgreSQL 常见报错速查：12 条原文、含义与处置
从 role/database 不存在到死锁、too many clients、checksums 不一致，12 条常见报错的含义与第一步该做什么；其中 4 条为本机实测原文。
-
pg_stat_activity 一页纸：看哪几列、三条查询定位阻塞
22 个列里真正要看的是 6 个；state 与 wait_event_type 的取值怎么读；三条查询分别查长事务、阻塞树、idle in transaction 泄漏。
-
慢查询日志：log_min_duration_statement 与 auto_explain 怎么配
从一条真实日志行出发：日志参数怎么设、日志里有什么、auto_explain 怎么把执行计划也记下来，以及三个影响性能的开关。
-
PostgreSQL 索引类型速查：btree / hash / gin / gist / brin 各管什么
六种索引类型支持的运算符与适用场景，四个常见误用（BRIN 不看相关性、hash 想排序、GIN 写放大、index-only 缺 visibility map）。
-
timestamp 与 timestamptz：三个函数、两个时区、一个常见错误
两种时间类型都是 8 字节，差别在存储语义；now()、statement_timestamp()、clock_timestamp() 三个函数的区别有实测输出；附三个时区坑。
-
pgbench 速查：默认值、六组参数、一个容易自欺的规模陷阱
pgbench 的默认值（-c 1、-j 1、-t 10、-s 1）、五类常用参数、输出字段含义，以及 -s 小于 -c 时你在测的其实是锁竞争。
-
PostgreSQL 类型选择速查：字节数、精度与五个常见选错
常用类型的实际存储字节（实测 pg_type.typlen）、金额用 numeric 的代价、text 与 varchar 的真实差别，以及五个建表时最容易选错的类型。
-
PostgreSQL 14 停止支持倒计时：14 → 18 大版本升级的完整实操清单
PG 14 将在 2026-11-12 发布最后一个 minor 并结束支持。四种文件搬迁模式各有什么硬前提、统计信息怎么重建、回滚边界在哪，以及 799MB 与 308MB 两次真实升级的耗时。
-
PostgreSQL 18 异步 I/O 调优手册：io_method、io_workers 与 effective_io_concurrency 的真实默认值
PostgreSQL 18 的异步 I/O 由四个参数加一个编译选项决定。18.6 上的实测：点查负载下三种 io_method 无差别，暖缓存顺序扫描 worker 比 sync 快 1.5 倍，真冷盘则差不到 2%；io_combine_limit 抬到 1MB 反而慢 66%。
-
PgBouncer 容量数学：max_client_conn、文件描述符与 pool_size 的正确算法
官方默认 max_client_conn 只有 100，default_pool_size 只有 20。用官方的文件描述符公式算预算，再实测池模式：500 客户端加 50ms 思考时间下，transaction 9865 tps，session 只有 394 tps。
-
用 eBPF 拆开数据库 p99 长尾：bpftrace 三件套的判读矩阵
pg_stat_activity 显示一切正常、p99 却降不下来，问题通常在内核。三条判定路径对应三组 bpftrace 工具，附真实块 I/O 延迟直方图，以及一个自写探针的失败案例。
-
pg_stat_statements 三步定位慢查询：按总耗时排序，按缓存命中和 WAL 归因
按 mean_exec_time 排序是最常见的优化误区。改成按 total_exec_time 排序，用缓存命中、临时块落盘、WAL 字节三个字段归因，再用 EXPLAIN 验证，最后附两轮真实 Top-N。
没有匹配的文章，换个关键词或标签试试。