有想法的py工程师-CSDN博客

原创 PostgreSQL 大字段更新的误区：TOAST 根本不会复制！（源码级深度解析）

💡 PostgreSQL 的精妙之处在于：👉它复制的是“指针”，不是“大数据”本身。

2026-04-17 14:32:49 145

原创 PostgreSQL 深入heap_update() 与 HOT 机制（附源码级解析）

💡 PostgreSQL UPDATE 的性能关键，不在“你改了多少列”，而在：👉你改的列是否影响索引 + 能不能在同一 page 完成更新。

2026-04-17 14:14:23 358

原创 Chrome终于支持「竖向标签页」了！附开启方法

最近，Google Chrome 迎来了一个让效率党狂喜的更新——🎉。对于经常打开十几个甚至几十个标签页的开发者来说，这个功能可以说是“救命级别”的提升。这篇文章带你快速了解这个新功能，以及。

2026-04-17 11:30:08 84

原创 PostgreSQL vs PolarDB：Checkpoint 调优策略深度对比（高频 vs 低频）

Checkpoint 本质是：将内存中的脏页刷回磁盘，并记录一个一致性恢复点在 PostgreSQL 中，checkpoint 的作用包括：限制 WAL 回放长度控制恢复时间保证数据持久性少 checkpoint，大 checkpoint→ 提升吞吐先调大 max_wal_sizecheckpoint 不是越频繁越好，也不是越少越好，而是要匹配数据库架构。

2026-04-17 10:32:01 441

原创 PostgreSQL 分区表排序优化：Append Sort 优化为 Merge Append

本次优化关键点：避免让每个分区按排序键输出使用 Partial Index触发 Merge Append让每个分区先排好，再合并，而不是先合并再排序如果你也遇到 PostgreSQL 分区表排序慢的问题，这种思路通常非常有效。

2026-04-09 14:47:50 255

原创 PostgreSQL 性能优化实战：一条 Order by 的 SQL 从 5 秒优化到 100ms

这次优化带来的启发很直接：PostgreSQL 查询优化，很多时候真正关键的不是“有没有索引”，而是“索引是否和 WHERE + ORDER BY 的访问路径一致”。5 秒 → 100ms性能提升非常明显。如果你在 PostgreSQL 优化中也遇到类似的慢查询，不妨重点检查两件事：索引列顺序是否匹配查询是否可以用 Partial Index 固化固定业务条件很多时候，突破点就在这里。

2026-04-09 14:26:46 485

原创 PostgreSQL GPG公钥加密备份文件

推荐 batch 方式创建（服务器更稳定）。否则机器损坏后，可能无法解密历史备份。安全 S3 bucket。

2026-03-31 14:59:28 62

原创 PostgreSQL 向量索引的了解「AI向」

语义搜索（Semantic Search）几乎所有 AI 向量数据库都采用。FAISS大量使用 PQ。AI Agent 知识库。1000万次距离计算。

2026-03-11 08:45:00 390

原创 PostgreSQL 为什么没有 Gap Lock，却依然能解决幻读？（深度解析MVCC机制）

理解这一点，就理解了 PostgreSQL 事务的核心设计。这也是 PostgreSQL 并发能力强的重要原因。那 PostgreSQL 是如何解决幻读问题的呢？PostgreSQL 的并发性能明显更好。这也是为什么 PostgreSQL 在。之后所有查询都会基于这个快照读取数据。这样其他事务就无法插入新的记录。而 PostgreSQL。

2026-03-11 08:30:00 363

原创 PostgreSQL 事务隔离级别详解（以及与MySQL实现差异）

在数据库中，**事务隔离级别（Transaction Isolation Level）**用于控制多个事务并发执行时的可见性规则。虽然 PostgreSQL 和 MySQL 都支持相同的隔离级别名称，但实现方式完全不同。PostgreSQL同样支持SQL标准的四种隔离级别，但。PostgreSQL 的 MVCC 架构。同一事务内两次读取同一行数据结果不同。因此 PostgreSQL 在。Serializable 是。通过检测冲突保证串行执行效果。这样其他事务无法插入新记录。因此不需要锁范围来阻止插入。

2026-03-10 14:37:58 590

原创 PostgreSQL 触发器性能评估实战（pg_stat_user_functions）

3️⃣ pg_stat_user_functions 是线上分析触发器性能的最佳工具之一。，每一行数据变更都会执行一次触发器函数。在高写入业务场景下，触发器可能成为性能瓶颈。如果业务系统每天有大量批量 UPDATE，就会产生非常高的触发器调用量。但是因为调用次数巨大（1.56 亿次），累计开销非常明显。2️⃣ 单次触发器通常很轻，但高调用量会产生巨大累计成本。确认哪些 UPDATE 导致触发器大量执行。在 PostgreSQL 中，如果表上有。基本可以确定触发器参与了大量业务写入。

2026-03-10 11:15:03 364

原创微软microsoft o365 许可证 SKU ID 与名称对照表

这篇文章是为那些不想为了获取此列表而集成复杂脚本的用户准备的。假设您想使用 PowerShell 脚本获取租户中已授权用户的列表，并且希望显示真实的产品名称，而不是像“SPE_E3”（代表“Microsoft 365 E3”）这样晦涩难懂的 SKU ID 字符串。我们知道，您无法通过 API 获取这些易于理解的名称，因此您需要自行获取列表。尤其是在使用 PowerShell cmdlet（例如“Set-MSOLUserLicense”、“Get-AzureADSubscribedSku”等）时，这一点尤为重

2026-02-26 13:47:52 55

原创 Postgres 关于wal文件传输能力上限的测试【rsync + SSH 串行归档环境】

在 PostgreSQL 使用 archive_command = 'rsync -a %p user@archive_host:/path/%f' 的串行归档模型下，即使网络与磁盘性能完全正常，整体归档吞吐仍然会被。完成一次ssh连接大约0.22s，传输一个16MB文件大约0.11s，加起来是0.33s。简单计算下，16/0.33= 48，每秒钟是48MB的数据，换算成mbps，就是47。本文通过三组真实可复现实验，证明 PostgreSQL 使用 rsync + SSH 串行归档时，其性能上限由。

2026-02-26 11:19:27 568

原创 PostgreSQL archive_command 场景下的 postgres 免密 SSH 配置与排查实录

SELinux context 是否为 ssh_home_t。，无法使用 ssh-copy-id，只能手工注入。，jumpserver 仅用于“人工运维操作”。authorized_keys 权限是否 600。模拟主库，执行 archive_command。的系统上，免密会“看起来都对但就是不生效”。postgres home 权限是否 700。archive_command 运行时是。postgres 是否允许 ssh 登录。A → B 的 22 端口是否放通。仅用于人工登录，不参与运行时链路。

2026-02-05 10:21:50 465

原创一次 PostgreSQL WAL 积压的完整排查过程：从“网络/IO 怀疑”到“归档模型瓶颈”

ready 多，通常不是“失败”，而是“吞吐不够”PostgreSQL 的 archive_command 天生是。

2026-02-05 10:19:34 500

原创 PostgreSQL 分区表 + Debezium CDC：为什么 REPLICA IDENTITY FULL 不生效？

那只对这两个分区设置 FULL，先验证 before 是否正常、WAL 是否可控，再决定是否扩展到历史分区。否则即便 FULL 生效，Debezium 也可能拿不到完整 old row。若只需要少量字段的 before，优先考虑 trigger + audit 表。若忘记设置 FULL，新分区的 UPDATE again 没 before。对分区表，父表设置 REPLICA IDENTITY FULL 是不够的。FULL 有明显的 WAL 与磁盘风险，务必评估。CDC 中 before 是否存在，

2025-12-18 10:43:45 778

原创 PostgreSQL + Debezium CDC 踩坑总结

在生产环境中为 PostgreSQL（分区表）引入 Debezium CDC，将数据同步到 Kafka。大字段（bytea / text / json）极易造成 WAL 暴涨。在 pg_publication_tables 中看到的，实际上是。或 connector 使用了错误/历史的 publication。CDC 模式：逻辑复制（Logical Replication）否则直接禁止 DELETE / UPDATE（数据库级保护）或复用已有 publication（已包含其他业务表）

2025-12-18 09:25:54 1155

原创 Amazon Linux 2 安装 postgresql-contrib 导致 PostgreSQL 小版本自动升级问题总结

摘要：在Amazon Linux 2上安装PostgreSQL的pg_trgm扩展时，直接安装postgresql-contrib包会触发PostgreSQL小版本自动升级（如14.12→14.20），存在生产环境风险。原因在于contrib包对主程序有严格版本依赖。解决方案包括：（1）安装与当前版本一致的contrib包（推荐）；（2）使用yum versionlock锁定版本后再安装。操作前务必通过yum install --assumeno验证依赖关系，避免非预期升级

2025-12-18 09:00:00 659

原创 PostgreSQL × Debezium × Kafka CDC（Change Data Capture）监控体系

你的上一条回答：payload.ts_ms - payload.source.ts_ms。识别延迟是来源于 DB、Debezium、Kafka 或下游。WAL 激增会导致 Debezium backlog。下游逻辑错误不会影响 Debezium，但会产生延迟。会影响 WAL 写入速度与 Debezium 延迟。Debezium 延迟会导致 WAL 无法被回收。Kafka 的性能直接影响整个 CDC 延迟。若 ISR 不健康，会影响 Kafka 写速度。Kafka 负载高会导致 CDC 暂停/堆积。

2025-12-09 09:56:28 1056

原创 PostgreSQL × Debezium × Kafka 时间戳机制 [附对照表]

表示该行变更（INSERT/UPDATE/DELETE）在 PostgreSQL 中被写入 WAL buffer 的时间。Debezium 解析 WAL 并封装 Kafka 消息的时间。它来自 PostgreSQL 本身，记录在 WAL 日志中。因此这个时间可能比 source.ts_ms 晚很多。数据库 WAL 记录的时间（变更发生时的真实时间）立刻生成，包含 timestamp。正常情况下几乎不可能出现分钟级延迟。不是 Debezium 读取时间。不是 Kafka 写入时间。不是 commit 时间。

2025-12-09 09:20:38 860

原创【Kafka 生产实战】如何判断消费组是否落后？Consumer Lag 全面解析 + 监控 + 实战案例

fetch.min.bytes / fetch.max.bytes：单次拉取数据大小上限。未消费的消息数量 = LOG-END-OFFSET - CURRENT-OFFSET。如果消费组一直落后，旧数据会在消费之前就被 Kafka 根据保留策略清理掉，max.poll.interval.ms：处理时间上限，避免误判为“挂掉”说明这几个 Topic 的消费组已经完全追上消息，运行正常。max.poll.records：一次拉取的最大消息数。fetch.max.wait.ms：拉取等待时间。

2025-11-21 08:30:00 758

原创【Kafka + Debezium 生产环境】如何监控 PostgreSQL 复制槽、Kafka Topic、Connector 状态（含 Zabbix 监控策略）

本文基于真实生产经验（Postgres slot 限制 5GB，Kafka topic 限制 8GB），给出一套。为了保证数据链路稳定，必须对 Kafka、Debezium、PostgreSQL 进行。下面是基于“5GB slot 限制 + 8GB topic 限制”的最佳触发阈值。意味着单个 slot 最多保留 5GB WAL。超过后会报错并停止同步。replication slot 保留 WAL 太多 → 撑爆磁盘。以下是必须监控的指标，按重要程度排序。基于这些参数，我将给出完整监控策略。

2025-11-20 11:44:09 1187

原创 PostgreSQL 索引算法全解析：原理、复杂度、流程图、图谱与 SQL 实例（超全收藏版）

但很多人对“索引算法”了解并不全面，只知道 B-tree，却不知道 PostgreSQL 实际支持。，分别适用于范围查询、JSON、全文、数组、空间、日志大表等完全不同的场景。：每个块记录 min/max（粗粒度索引）索引，是数据库性能优化中最关键的一环。：可扩展树结构，空间/模糊/范围。这是选择索引最重要的参考信息。JSONB、数组、全文搜索。通用、范围、排序、主流默认。JSONB、数组、全文搜索。空间、范围、模糊、KNN。

2025-11-20 08:45:00 448

原创 2025 年最大互联网事故：Cloudflare 宕机导致全球网站瘫痪

网站无法访问、网站打开很慢、页面加载失败、DNS 错误、API 请求失败、网站超时、网站 500 错误、503 错误、静态资源加载失败、图片加载失败、CSS 加载失败、网页渲染错误、服务器崩溃、网站宕机怎么办……SEO 排名恢复、站点地图提交、修复抓取错误、提升抓取预算、网站健康检查、SEO 日志分析、网站速度优化、多 CDN 方案、灾备方案、网站故障恢复、抓取频率提升、内容更新提升排名……许多依赖 Cloudflare 的机构网站同样出现宕机，包括监管部门与情报机构。

2025-11-19 09:50:38 1608

原创微软究竟怎么了？Bug 还在，AI 又来，Windows 用户怒火冲天

近来， Microsoft 在系统中大力推广 AI 功能，比如内置 AI 助手、自动截图记录、时间线回溯等，但与此同时，“Bug 还没修完”“用户隐私还没搞定”这些声音也越来越多。微软推出名为 Recall 的功能：在 Windows 中持续截屏、记录用户操作（包括用过的应用、访问过的网站、聊天记录等），然后用 AI 帮助用户“回忆”操作轨迹。不想被记录、不想被动接受、不信任微软的“帮你记忆”承诺。：语气中的“又”体现出一种反复、叠加的不满，用户感到微软在强推 AI ，而不是先修好基础系统。

2025-11-19 09:31:51 994

原创【PostgreSQL 索引巡检篇】如何判断索引是否有效？是否需要重建？完整巡检指南（实战 + SQL）

我们之前的库两年来从来没有进行过索引巡检，以至于进行索引重建后，较原来库体积减少了1/3，真的很吓人。CREATE INDEX CONCURRENTLY 失败会留下无效索引，需要巡检并清理。idx_tup_read / idx_tup_fetch → 判断是否回表。而绝大多数慢 SQL，其实都可以通过正确的索引巡检提前发现并避免。这一篇，我们完整讲透 PostgreSQL 的索引巡检体系。如果发现重复，可删掉扫描次数较低或意义较弱的索引。的索引，删除只会提升写入性能，不会带来负面影响。

2025-11-19 09:00:00 835

原创【PostgreSQL 索引实战篇】CREATE INDEX CONCURRENTLY 到底是不是零停机？详细原理 + 实战流程

PostgreSQL 会扫描全表，按照当前的数据构建一个初始索引。如果此时有长事务，会进入“等待状态”，你会看到索引构建似乎不动了。如果 idx_scan 长期为 0，说明索引未被 SQL 使用。这是 PostgreSQL 13+ 才有的功能，非常实用。掌握这一篇文章，你已经具备在生产环境安全构建索引的能力。然而很多人以为它是“完全零影响”的，事实并不是这样。很多人只知道它“不阻塞写”，但不知道为什么能做到。因为旧事务可能修改了某些行，需要等它们提交或回滚。索引元数据不包含“是否为并发建索引”的标记。

2025-11-19 08:45:00 608

原创【PostgreSQL 索引原理篇】为什么建了索引却没生效？一篇彻底讲清楚 B-tree / GIN / GiST / BRIN

明明给字段建了索引，信心满满地执行 SQL，结果一看执行计划——依旧是 Seq Scan，全表扫描跑得飞起，性能没丝毫改善。合理选择索引类型，往往比“盲目建索引”更重要。如果你也遇到过类似问题，那么这篇文章可能比加一台服务器更能提升你的查询性能。为了真正掌握它，你需要了解 PostgreSQL 索引背后的原理与规则。很多人对索引的理解停留在“有索引 = 查询快”。这两个索引类型可以让你解决大量“为什么不走索引”的问题。掌握这一篇，你已经能避免 80% 的索引相关性能问题。范围查询：>、<、BETWEEN。

2025-11-18 15:27:19 604

原创 PostgreSQL 索引从原理到实战：创建、删除、重建、查看一篇说透

本文从索引原理到 CONCURRENTLY 的使用，再到索引的创建、删除、重建、巡检等完整实践，为你提供一篇可以直接落地的 PostgreSQL 索引管理指南。：对于 TB 级大表，如果在线建索引依然耗时过长，可通过分区表、逻辑拆表、迁移影子表等方式结合实现零停机索引构建。是否使用了 Index Scan / Index Only Scan 是判断索引效果的关键。这是不少工程师的真实痛点。索引的创建、删除、重建都可以使用 CONCURRENTLY。善用部分索引、表达式索引、INCLUDE 覆盖索引。

2025-11-18 15:23:05 1585

原创 office 365 E3 for symphony/E3 dev免费订阅申请

还需要注意的是，如果你的Microsoft 365 Admin Center 账号选择的注册区域不是CN，那么你就需要拥有对应注册区域的Visa卡或百事达等国外银行卡，比如Microsoft 365 Admin Center账号注册时选择的区域是美国（US），那么你需要一个美国银行卡，但如果你的Microsoft 365 Admin Center注册区域是中国（CN）那么你就可以直接使用支付宝方式付款。适用于全新账号, 没有亿点点难度，旧账号亲测会出现租户报错的问题，直接注册新号最方便。

2025-11-14 17:24:34 2176

原创 PostgreSQL 大表字段回填最佳实践：高并发无锁更新 + 分批提交 + 完整进度显示

摘要：本文针对高QPS环境下大表NULL值更新问题，提出了一种安全高效的backfill方案。传统方法存在全表锁、长事务、性能下降等风险，本文方案采用小批量更新（1000行/批）+SKIPLOCKED锁机制+部分索引+分批提交技术，避免了业务阻塞和性能抖动。关键创新点包括：使用PROCEDURE实现显式提交、动态进度计算、批次耗时监控、可调节休眠间隔。通过生产案例验证，该方案在36万行数据更新时保持稳定性能，相比直接UPDATE方案，将系统影响降低90%以上。最佳实践建议：设置500-2000的批次大小，0

2025-11-14 15:06:56 1004

原创 PostgreSQL 缓存污染 vs 缓存击穿你必须搞懂的两个痛点

你准备把书放到书架最右边（B-tree 右端叶子页），结果这块书架被搬走了（page 不在 buffer），你得重新拿新的书架板（磁盘读），就慢了。PG 大象肚子本来装的是营养（热点页），结果突然被人硬塞进一堆垃圾塑料袋（冷数据），导致它消化不良。pg_buffercache、pg_stat_io、pg_statio 系列、延迟采样脚本等。大表 dump 改用 --no-sync 或 --jobs=4（不要全速读）使用 pg_dump --no-sync + 低优先级 I/O。

2025-11-14 08:30:00 1592

原创 PostgreSQL 备份导致的 Cache Pollution（缓存污染）

摘要：PostgreSQL运维中常忽视缓存污染问题，即大规模顺序读操作（如pg_dump）占用shared_buffers，导致业务热点页被挤出，引发SQL性能下降。本文通过真实案例，分析pg_dump扫描大表时如何污染缓存，并提出工程解决方案：调整备份时间、限制并发、补偿预热、增大shared_buffers或改用物理备份。理解缓存污染机制有助于优化数据库稳定性，避免性能波动。

2025-11-13 09:13:40 678

原创 PostgreSQL Buffer缓存淘汰机制详解：Clock vs Clock-Sweep vs LRU

本文系统比较了数据库缓存淘汰算法LRU、Clock和PostgreSQL采用的Clock-Sweep。LRU通过双向链表精确反映访问顺序但实现复杂；Clock算法简化实现但仅区分0/1状态；Clock-Sweep在Clock基础上引入多级访问计数（usage_count），实现访问频率的渐进衰减。三者对比显示，Clock-Sweep在保持近似LRU效果的同时，具有实现简单、并发性能好等优势，特别适合数据库高并发场景，是PostgreSQL性能优化的关键设计之一。

2025-11-13 09:00:00 774

原创 PostgreSQL 可视化监控利器 —— pg_top 安装与使用全攻略（查看正在执行的SQL占用的资源）

《PostgreSQL性能监控神器pg_top实用指南》摘要：pg_top是一款类似Linux top命令的PostgreSQL实时监控工具，可直观展示数据库活跃连接、执行SQL、CPU/内存占用和锁状态等信息。文章详细介绍了pg_top的安装方法（支持主流Linux发行版）、常用快捷键操作（按CPU/内存排序、查看SQL文本和锁信息等）以及典型应用场景（定位性能问题、排查锁竞争）。通过对比其他监控工具，指出pg_top在实时诊断中的独特优势，并提供常见问题解决方案。

2025-11-12 09:50:44 1844

原创 PostgreSQL 生产环境慢SQL时的系统快照与PG快照抓取

20_pg_stat_activity.txt、21_blocking_graph.txt、22_pg_locks.txt：会话与锁。10_pg_stat_wal.txt、11_pg_stat_bgwriter.txt：WAL 与 bgwriter 指标。23_locks_by_pid_*.txt、24_activity_by_pid_*.txt：最慢 PID 附加。30_table_stats.txt、31/32/33_progress_*.txt：表统计与后台进度。

2025-11-12 09:29:27 630

原创 PostgreSQL 实战分析：UPDATE 语句性能异常与缓存击穿诊断

SQL 本身较为简单，仅更新数个字段，理论上应为毫秒级执行，但在监控中观测到延迟偶尔飙升至。同时，本文中讨论的情况，实际上就是从buffer中查询变为了从磁盘查询，也就是从ms到s的变化。从 pg_stat_activity 快照中可见，当触发慢 SQL 时，数据库并无显著锁等待，wait_event_type 为空，说明不是事务阻塞导致。d_heap（新增 heap 块读取量）在本周期突增，显示 UPDATE 过程中大量触发物理页加载，而 H_heap（命中）虽高但增长幅度小。

2025-11-11 17:46:46 760

原创 PostgreSQL insert 偶发变慢的原因分析 —— 从缓存击穿到系统 I/O

这些 SQL 操作并非批量导入（如 COPY），也不是长事务，而是普通的行级插入，主要涉及订单、账户、日志等高频表。在一次生产环境性能监控中，我们发现数据库中部分 INSERT 操作持续变慢，延迟从毫秒级飙升到秒级，触发告警。驻留率（cached ratio）低于 5%，即大多数页不在 shared_buffers 中。pg_stat_activity 显示 insert 查询运行时间较长，无锁等待。42_pg_buffercache_hot.txt —— 缓冲池中热点表命中率；

2025-11-11 17:32:41 1005

原创 PostgreSQL 从库停止回放问题排查

PostgreSQL从库WAL回放暂停事件分析：从库因参数不匹配触发停机。调查显示从库WAL回放长期暂停（108天滞后），执行恢复命令后遇到主库max_connections参数变更（225）与从库设置（150）冲突，导致保护性停机。根本原因可能是备份脚本执行pg_wal_replay_pause()后未恢复。解决方案包括调整从库参数至主库相同值并重启服务，建议加强参数同步、权限控制和回放状态监控。该事件凸显了配置一致性和完整操作流程的重要性。

2025-11-03 10:21:21 970

原创 PostgreSQL 性能测试利器：pgbench 使用详解

摘要：本文详细介绍了PostgreSQL自带的性能测试工具pgbench的使用方法。作为官方基准测试工具，pgbench基于TPC-B模型，可评估数据库吞吐量和延迟等性能指标。文章内容包括环境准备、数据初始化（约100万条记录）、标准基准测试（10并发下达2950 TPS）和自定义SQL测试的实现步骤，并提供真实命令示例和结果解析。最后给出性能优化建议（如调整shared_buffers、优化SQL等）和推荐实践方案，特别强调在服务迁移前使用pgbench进行新服务器性能测试的重要性，同时提醒避免在生产环境

2025-10-31 14:46:21 1137

PostgreSQL生产库按需抓去Slow SQL快照与动态热点集合的Bash实现

空空如也