标签: #database

한국어English日本語中文

← 全部文章

• 300 倍不是调 PostgreSQL 调出来的数字 —— 火山模型与向量化执行

  精确解剖随 pgrust 0.2 发布一起公开的那个 300 倍。这个数字不是改 PostgreSQL 配置得来的，而是把一个用 Rust 重写的数据库放到 ClickBench 上测出来的结果；而作者另外给出的 SUM 查询实验，是从火山模型的 1.3 秒到 SIMD 的 135 毫秒，也就是 9.6 倍。我们在代码层面跟一遍批处理、算子融合、SIMD 各自消掉了什么，并把作者自己讲明的局限，和你今天就能在真实 PostgreSQL

  2026-08-09 · 12 分钟阅读 #postgresql#database#performance#query-engine#simd

• SQL 注入与参数绑定 — 用了 ORM 仍然会被打穿的那些地方

  搜索 SQL 注入的对策，最先跳出来的往往是转义函数，但正确答案是参数绑定。转义是试图让值在字符串字面量里变得安全，而绑定是让值根本不进入 SQL 文本的结构性分离。本文用日志确认预处理语句在服务端究竟是怎样被解析和执行的，再用 Python 和 JavaScript 代码展示即使用了 ORM 也会被打穿的三个地方，以及 ORDER BY 或表名这类根本无法绑定的位置该如何处理。文章还会覆盖 LIKE 子句的通配符、保存下来的值日后才引

  2026-07-26 · 22 分钟阅读 #security#sql#database#orm#python

• 建了索引却不走索引的原因 — 那些优化器对而你错的情况

  本文按原因梳理为什么建了索引之后执行计划里依然是 Seq Scan。选择性太低导致优化器故意忽略、列上套了函数或运算而不再 sargable、类型不匹配触发隐式转换、LIKE 前导通配符、OR 条件、复合索引的前导列规则、统计信息老化,直到 NULL 的处理,全部用真实 SQL 和执行计划来确认。同时也讨论部分索引与表达式索引成为答案的场景,以及索引反而有害的情况。

  2026-07-26 · 18 分钟阅读 #database#postgresql#index#query-optimization#mysql

• 连接池开太大反而吃亏的原因 — 把队列排在哪里

  本文梳理把连接池调大反而变慢这一现象背后的原理。在 PostgreSQL 的进程模型下连接为什么昂贵,既然磁盘与 CPU 的并行度有限,为什么把队列排在连接池而不是数据库内部更划算,以及常被引用的核数公式的依据与局限。文章还会结合真实查询讲解微服务中实例数乘以池大小超过最大连接数的典型事故、PgBouncer 的三种模式与事务模式下无法使用的功能、如何用 idle in transaction 抓连接泄漏,以及无服务器环境的特殊性。

  2026-07-26 · 21 分钟阅读 #database#postgresql#connection-pool#pgbouncer#performance

• 死锁的诊断与预防 — 如何从日志中锁定那两条查询

  本文按顺序梳理遇到 deadlock detected 错误时应该看什么。如何逐行解读 PostgreSQL 的死锁报告和 MySQL 的 SHOW ENGINE INNODB STATUS 输出,从而锁定究竟是哪两条查询纠缠在了一起;并讨论实务中反复出现的三种模式:更新顺序不一致、因缺少索引导致锁范围扩大、以及外键引发的父行加锁。文章还包含 deadlocktimeout 与 locktimeout 的设置,以及不把普通锁等待误诊为死

  2026-07-26 · 21 分钟阅读 #database#postgresql#deadlock#locking#mysql

• EXPLAIN ANALYZE 阅读法 — 从执行计划中找出真正瓶颈的顺序

  本文梳理如何从头到尾读懂 EXPLAIN ANALYZE 的输出。应该按什么顺序读节点,cost 为什么不是时间单位,预估行数与实际行数之间的偏差说明了什么,loops 会被相乘的陷阱又该如何避开,全部结合真实输出来讲解。同时涵盖 Nested Loop、Hash Join、Merge Join 各自被选中的条件,以及如何用 BUFFERS 判断缓存命中。文章还会给出依据,说明 Seq Scan 并不总是坏事。

  2026-07-26 · 17 分钟阅读 #database#postgresql#explain#query-optimization#performance

• 事务隔离级别与真实的异常现象 — 标准定义与实现产生分歧的地方

  本文梳理四种事务隔离级别以及 dirty read、non-repeatable read、phantom read,但不会止步于教科书里的那张表。文章用真实的 SQL 会话展示:PostgreSQL 的 Read Committed 为什么根本产生不了 dirty read,Repeatable Read 为什么其实是快照隔离、并把重试直列化失败的责任交给了应用,以及 MySQL InnoDB 的 Repeatable Read 如何

  2026-07-26 · 19 分钟阅读 #database#postgresql#transaction#isolation-level#mysql

• Neo4j 日历版本时代中期盘点 — 块格式、Cypher 25，以及 GQL 落地引擎的方式

  Neo4j 在 2025 年初转向日历版本号(CalVer)以来，大约 17 个月里发布了 18 个功能版本，而每个版本的热修复支持在下一个版本发布的那一刻就结束。截至本文撰写的 2026 年 7 月，CalVer 系列仍然没有 LTS，如果需要稳定支持，就得停留在 5.26 LTS(热修复维护到 2028 年 6 月)，代价是放弃 Cypher 25、VECTOR 类型和新的 GQL 语法。本文不谈图 RAG，而是用一手资料(官方更新

  2026-07-17 · 23 分钟阅读 #database#neo4j#graph-database#cypher#gql

• Cassandra 6.0-alpha1 与 Accord 事务 — 五年之约的「通用事务」，现在走到哪一步了

  Accord 是 Cassandra 的通用事务协议，2021 年以 CEP-15 的形式提出，终于在 2026 年 3-4 月，随 6.0-alpha1 这个可运行的发布版本一起问世。这个协议的承诺是，通过无 leader 的共识，在正常条件下用一次 WAN 往返完成多分区的 strict-serializable 事务，而且这个发布版本里确实带上了 BEGIN TRANSACTION 语法和按表设置的 transactionalmo

  2026-07-17 · 20 分钟阅读 #database#cassandra#distributed-systems#transactions

• ClickHouse 的 Lazy Materialization — LIMIT 10 的小技巧是如何长成 FINAL 和 JOIN 的

  ClickHouse 的 lazy materialization 是一种在排序和 LIMIT 完成之前不读取 SELECT 列的优化，它在 25.4(2025 年 4 月)以「仅在 LIMIT 10 及以下时才生效」的保守姿态首次登场。此后，在把逐行 lookup 改造成 join 式批量获取的 25.12 中，这道闸门被提高到 10,000；进入 2026 年后，同一个思路又扩展到 26.2 的 UNION ALL 全部分支、26.

  2026-07-17 · 22 分钟阅读 #database#clickhouse#olap#query-optimization#performance

• MySQL 9.7 之后的版本是 26.7 — 2026 年春天，MySQL 与 MariaDB 整理发布模型的方式

  2026 年 4 月 21 日，MySQL 9.7.0 以 GA 形式发布，这是自 8.4 之后近两年来第一次开启新的 LTS 分支；同一个月，MySQL 8.0 的 Extended Support 到期，降级为 Sustaining Support。随后在 6 月 16 日，Oracle 宣布把版本号切换为 YY.M 日历式版本号，于是 9.7 之后的创新版本不是 9.8，而是 26.7。MariaDB 在五周之后、5 月 29 日

  2026-07-16 · 29 分钟阅读 #mysql#mariadb#database#versioning#devops

• Postgres 19 的 pg_plan_advice — 一个长期拒绝提示的项目给出的妥协方案

  PostgreSQL 项目长期以来一直拒绝优化器提示(hint)。但在 2026 年 6 月 4 日发布的 PostgreSQL 19 Beta 1 中，Robert Haas 编写的 pgplanadvice 和 pgstashadvice 作为 contrib 模块被合并了进去。这不是 Oracle 式的提示 — 建议(advice)活在 SQL 之外，它不是替代规划器，而只是收窄搜索空间，用文档自己的话说，出来的"只会是核心规划器

  2026-07-16 · 22 分钟阅读 #postgresql#query-planner#query-optimization#database#performance

• InfluxDB 3 Core 的「72 小时限制」其实是 432 个文件的限制 — Parquet 重写留下的账单

  InfluxDB 3 把整个引擎用 Rust 重写，并把存储层架在了 Apache Arrow 和 Parquet 之上。坊间常说「Core 只能查询最近 72 小时」，但翻遍源码也找不到这样的代码。真正存在的只有一件事 — 单次查询能扫描的 Parquet 文件数上限为 432，而 72 小时不过是用默认 gen1 时间块 10 分钟乘出来的派生值，还是最理想情况下的数字。本文逐行追踪 432 这个数字在源码里的来处，确认了 2025

  2026-07-16 · 28 分钟阅读 #database#influxdb#time-series#parquet#storage-engine

• DuckDB 有了客户端-服务器协议 — Quack 改变了什么，又没有改变什么

  2026 年 5 月 12 日，DuckDB 团队发布了 Quack。这是一套架在 HTTP 之上的客户端-服务器协议，让两个 DuckDB 实例互为客户端和服务器，使同一个数据库可以被多个进程同时读写。一个把「进程内」当作身份标签坚持了 7 年的项目，如今自己给自己装上了服务器 — 相比「改变了什么」，「没有改变什么」反而更重要。本文梳理了 Quack 的设计取舍(为什么是 HTTP、为什么不是 Arrow Flight SQL)、D

  2026-07-16 · 26 分钟阅读 #database#duckdb#olap#analytics#data-engineering

• pgrust: 用 Rust 重写 Postgres 并 100% 通过回归测试 — 它真正意味着什么

  Malcolm Matis(malisper)公开了用 Rust 重写 Postgres 的 pgrust。它以兼容 Postgres 18.3 为目标，通过了四万六千多个回归测试查询，并能在真实的 18.3 数据目录上启动。本文诚实地剖析这个里程碑为何真的令人印象深刻，以及"100% 通过回归测试"这句话证明了什么、又没有证明什么。我们还会一并审视用 AI 智能体写出的代码、性能主张，以及它距离生产级 Postgres 还有多远。

  2026-07-11 · 10 分钟阅读 #postgresql#rust#pgrust#database#regression-tests

• CloudNativePG 在 Kubernetes 上跑起 Postgres 再杀掉它 — 实测故障转移 23 秒

  在真实的 8 节点 Kubernetes 集群上安装 CloudNativePG(CNPG) v1.30.0，启动一个 3 实例的 Postgres 集群，然后真的把主库杀掉。从引导启动、复制确认，到强制删除主库后的故障转移(23.1 秒内副本晋升、数据零丢失)，再到死掉的节点作为副本自愈、恢复到 3/3 — 全过程连同实测日志一并记录。运行在 NFS 存储之上的家庭实验室环境里那些诚实的数字与陷阱，也原样收录。

  2026-07-11 · 7 分钟阅读 #cloudnativepg#postgresql#kubernetes#operator#database

• DB 完全指南 — 内部结构、索引、查询规划器、分区、Vector DB (Season 2 Ep 13, 2025)

  只把数据库当成“写 SQL 的地方”，那就一辈子停在初级。B-Tree、LSM-Tree、Hash Index 的内部结构，查询规划器如何把查询变成执行计划，事务隔离的四个级别，分片与分区策略，PostgreSQL 在 2025 年的一枝独秀，以及 Vector DB(pgvector、Qdrant、Weaviate) — 一篇把数据库内部拆到电路图级别的文章。Season 2 的第十三篇。

  2026-04-15 · 17 分钟阅读 #database#postgresql#b-tree#lsm-tree#indexing

• 在 K8s 上运维 DB — CNPG、Percona、Vitess、Helm chart 完全指南

  总整理在 Kubernetes 环境中运维数据库的方法。对比 CloudNativePG、Percona Operator、Vitess 以及主流 Helm chart，并分享实战运维经验。

  2026-04-11 · 20 分钟阅读 #database#kubernetes#cnpg#postgresql#mysql

• 数据库工程完全指南：从 SQL 到向量数据库、AI RAG 系统

  从 SQL 高级技巧到 pgvector 向量检索、Pinecone、RAG 系统搭建 — 一份 AI 时代的数据库工程完全指南。

  2026-03-17 · 26 分钟阅读 #database#postgresql#vector-database#pgvector#rag

• PostgreSQL 高级索引完全指南：GIN·GiST·BRIN·Partial Index 实战活用

  深入讲解 PostgreSQL 的高级索引类型。超越 B-tree，覆盖 GIN（倒排索引）、GiST（空间索引）、BRIN（块范围索引）、Partial/Expression Index 的内部结构与应用场景，基于 EXPLAIN ANALYZE 的性能分析，直到索引膨胀的管理，提供一份实战指南。

  2026-03-10 · 21 分钟阅读 #database#postgresql#indexing#gin-index#performance