背景笔者在几年前整理过一篇文章，介绍了 MySQL 当前 DDL 的能力情况（白话Online DDL）。之前的文章重点介绍了 MySQL 5.6、5.7 到 8.0 的 DDL 能力对比并且解释了几个 DDL 常见的问题，并没有从代码层面分析 MySQL DDL 的执行过程。最近笔者遇到有个客户询问“MySQL 的 INT 列转为 BIGINT 会不会锁表？”笔者看了下之前的文档发现，MySQL 当前在处理所有的列类型转换的时候都只能走 Copy DDL，所以 INT 列转为 BIGINT 肯定是需要锁表的。但是这听起来又很不合理，从 INT 列转为 BIGINT 的过程中其实完全不存在任何数据不兼容的问题，为什么 MySQL 还是要锁表？带着这个问题，笔者重新整理了 MyQSL DDL 的执行过程，本文将从代码层面分析 MySQL DDL 的执行过程，并试着解决 INT 列转为 BIGINT 锁表的问题。DDL 整体执行过程在介绍 DDL 的执行细节前，先对 DDL 的整体执行过程做一个总结：上图是 MySQL InnoDB 表（本文后续内容也都是基于 InnoDB 表） DDL 的一个整体过程，DDL 的处理过程会贯穿 Server 层和 Engine 层。Server 层会串联起整个 DDL 的基本步骤，大体可以分为三个阶段：准备阶段，DDL 前的准备工作。执行阶段，DDL ...继续阅读

概述PolarDB8.4是polardb8.0.2的下一个版本，对标的是社区mysql 8.4,目前正在紧锣密鼓的内测当中，不久就能通过polardb-mysql官网进行购买，是时候花点时间介绍一下PolarDB8.4内核层面的新特性了 。 对笔者而言最大的惊喜是另做了一个比较现代的hypergraph optimizer，之前我和其他同事有系统性阐述过hyper optimizer, 可以参考DpHyper算法介绍Mysql Hyper Optimizer Interesting Order代码分享HyperOptimizer join order搜索空间正确性完备性实现现在让我们来看看8.4的另一个让人心动的特性，prepare once。在此之前先让我们看看polardb8.0.2的ps协议的实现polardb8.0.2 PS协议polardb802是基于mysql 8.0.18 codebase上进行研发的，这个版本上ps的prepare phase会进入Query_block::prepare函数， 逻辑是进行fix_fields以及进行一些rule base的查询改写。execution phase会重新进入Query_block::prepare函数，包括重新fix_fields及重新进行改写。然后继续进行optimize+execute iterator。这会带来如 ...继续阅读

概述慢 SQL 是一个 DBA 无法绕过的问题，在云数据库快速崛起的时代背景下，也将成为云客户支持同学必须要面对的一个问题。因此本文将分享一些 PostgreSQL 慢 SQL 的优化思路，希望能够为读者在解决慢 SQL 问题时提供一些参考。文章先介绍了下背景，再提供了几种监控慢 SQL 的方法，然后再以具体的 case 为基础阐述了慢 SQL 产生的多种原因以及对应的解决方案。背景慢 SQL 是指执行时间较长的 SQL 语句。其中“慢”是一个相对值，不同场景下的标准也会不一样。例如：在一般场景下，执行时间超过 5s 的 SQL 可以称为慢 SQL；在高并发场景下这个标准可能就提高为 100 ms。慢 SQL 是影响数据库性能最常见的因素之一，可能会造成以下几种危害：造成 SQL 响应变慢，影响客户业务及用户体验；增加系统负载、消耗系统资源，导致并发处理能力下降，过高的系统负载或资源占用，会导致数据库崩溃；引发长事务，带来长事务的一系列影响，在 PostgreSQL 中可能会导致数据库年龄回卷，无法清理死元组等问题。监控慢 SQL首先，我们需要拿到慢 SQL， 因此需要对慢 SQL 进行监控，这里提供几种监控慢 SQL 的手段。日志监控PostgreSQL 中主要通过记录日志的方式对慢 SQL 进行监控，所以要确保实例打开日志收集功能，同时记录 SQL 执行时间作为参考。这些功能由 ...继续阅读

MySQL查询优化分析系列过往文章：《MySQL查询优化分析 - MySQL优化执行的基础概念》《MySQL查询优化分析 - 常用分析方法》在数据库管理中，慢查询是影响业务响应速度的主要因素之一，还往往会消耗大量CPU资源，导致整体性能下降，严重影响数据库整体响应。本文总结了MySQL中慢查询的一些常见原因，并深入分析这些原因的分析和解决方法。这些分析能够解决很多业务场景的慢查问题。当然还有一部分慢查是在社区MySQL上无法解决的，在本文及后续的文章中会介绍PolarDB MySQL在查询优化与执行提升上做了哪些事情。下面本文将常见慢查的问题分以下场景介绍：无合理索引、无法利用已有索引、优化器无法选择正确执行计划、分析场景处理数据量大。无合理索引对于查询语句，如果没有合理的索引会导致查询需要扫描大量数据，IO开销和扫描数据行CPU开销都会非常大，导致查询慢。下面是一些没有合理索引的场景。过滤性更强的字段上缺失索引例如下面语句，虽然该语句的执行选择了字段c1上的索引i_c1，但其过滤性远不如等值条件的字段c2。选择i_c1索引实际需要扫描1万行，而c2字段上满足c2 = 1的行仅有1行，如果在c2上建索引那么该语句可以仅扫描一行。mysql>explainselect*fromt1wherec1>=1andc1<=10000andc2=1\G********************* ...继续阅读

MySQL的优化器实现在代码结构上比较混乱，每个阶段的界限不是特别清晰，同时，代码耦合度高，对其进行拓展和修改都难度极大。因此，对MySQL的优化器代码有一个整体上的感知是非常重要的。 本文对MySQL的优化器代码进行一个速览，本文将重点放在MySQL优化器的整体工作流程，会对每个主要步骤的作用和用到的数据结构做简要介绍但忽略其中的算法和具体实现，力求做到全但不求深，为的是能够让大家对MySQL优化器的总体工作流程有一定的理解，当遇到问题或者有功能开发需求时，能够快速定位到相应的代码模块。一个数据库优化系统一般会顺序完成以下几个任务：与数据库Catalog绑定，语义检查基于规则的逻辑变形基于代价的优化生成物理执行计划以下是MySQL优化器的逻辑架构图，可以发现MySQL的优化器确实顺序完成了上述提到的几个任务。本文主要关注MySQL优化的代码结构，首先将MySQL优化器的逻辑结构和代码结构做一个对应。从代码结构来看，优化器工作主要由两个函数构成，第一个是Query_block::prepare()，主要完成了Resolver和Logical Transformations的工作，第二个是JOIN::optimize()主要完成了CBO优化，生成物理执行计划等工作。MySQL这么划分的原因其实是prepare正好对应了PREPARE语句所需要进行的所有工作，对于普通语句，必须进行pr ...继续阅读

这个是前年AWS re:Invent 2022 的内容, 有兴趣可以看这个链接:Aurora re:Invent 2022这个是去年AWS re:Invent 2023 的内容, 有兴趣可以看这个链接:Aurora re:Invent 2023AWS reInvent 2024 刚刚结束, 笔者作为数据库从业人员主要关注的是AWS Aurora 今年做了哪些改动, 今年最大的可能就是 Aurora DSQL 的发布了.因此这个文章主要介绍 Aurora DSQL 的实现, 以及笔者的一些看法.下面的内容主要分成 3 部分:snapshot isolation + EC2 TimeSync service + OCCCross Region cache coherenceServerless在发布会上, Matt 介绍 DSQL 将多次 commit 合并成一次 commit, 从而实现了 90% 的性能提高, 那么 DSQL 是如何实现的呢?主要通过 snapshot isolation + EC2 TimeSync service + OCC 实现.具体做法原先一个事务中包含 10 条 SQL, 每一条 SQL 都需要和数据库交互, 需要对某一些行就先 row lock, 避免事务执行过程中被其他事务修改. 那么如果在跨 region 场景, 延迟可能到了 100ms 以上, 一 ...继续阅读

本文主要探讨我们在PolarDB MySQL产品中针对谓词下推这一优化器SQL重写规则所做的增强。在社区版本的基础上，我们进一步强化了下推逻辑对于等值关系的利用，通过等值语义的传递，增加了符合下推派生表规则的查询场景。此外，我们还扩展了谓词下推的范围，包括将HAVING子句中的谓词下推至WHERE子句、将WHERE子句中的谓词下推至子查询，以及将JOIN谓词下推至派生表。此系列优化旨在提升查询性能，显著改善用户的使用体验。什么是谓词下推在现代数据库系统中，用户场景的SQL查询往往复杂多样，涉及多个表的连接、子查询以及各种聚合操作。这种复杂性使得查询性能优化变得尤为重要。在这一背景下，谓词下推（Predicate Pushdown）作为一种重要的启发式优化规则，被广泛应用于优化器的查询模块中。它的核心思想是将查询条件（即谓词）尽可能早地应用于数据源，以减少后续操作的数据量。简而言之，就是在尽早的阶段对数据进行筛选，以避免不必要的数据处理，从而提高查询性能。社区版本的谓词下推Mysql社区优化器阶段的谓词下推指的是子查询派生条件下推，即在prepare阶段，Mysql会自顶向下，逐层处理每层查询的WHERE条件，将符合条件的谓词下推到子查询派生表中，比如下面的sql语句SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constan ...继续阅读 (5)

本文主要探讨我们在PolarDB MySQL产品中针对谓词下推这一优化器SQL重写规则所做的增强。在社区版本的基础上，我们进一步强化了下推逻辑对于等值关系的利用，通过等值语义的传递，增加了符合下推派生表规则的查询场景。此外，我们还扩展了谓词下推的范围，包括将HAVING子句中的谓词下推至WHERE子句、将WHERE子句中的谓词下推至子查询，以及将JOIN谓词下推至派生表。此系列优化旨在提升查询性能，显著改善用户的使用体验。什么是谓词下推在现代数据库系统中，用户场景的SQL查询往往复杂多样，涉及多个表的连接、子查询以及各种聚合操作。这种复杂性使得查询性能优化变得尤为重要。在这一背景下，谓词下推（Predicate Pushdown）作为一种重要的启发式优化规则，被广泛应用于优化器的查询模块中。它的核心思想是将查询条件（即谓词）尽可能早地应用于数据源，以减少后续操作的数据量。简而言之，就是在尽早的阶段对数据进行筛选，以避免不必要的数据处理，从而提高查询性能。社区版本的谓词下推Mysql社区优化器阶段的谓词下推指的是子查询派生条件下推，即在prepare阶段，Mysql会自顶向下，逐层处理每层查询的WHERE条件，将符合条件的谓词下推到子查询派生表中，比如下面的sql语句SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constan ...继续阅读 (4)

背景LIKE 操作符是 PostgreSQL 支持的三种模式匹配方法之一。一般情况下，如果 SQL 中有模式匹配的过滤条件期望走索引，我们更推荐使用 GIN 或者 GIST 索引，同时配合创建一些插件，比如 pg_trgm，来达到更理想的效果。如果模式匹配字符串的模式以常量前缀开头，即满足前缀匹配，那么 B-tree 索引也可能被使用。能走 B-tree 索引的理论基础是因为前缀匹配可以被转换成一个范围查询。本文将对 LIKE 操作符前缀匹配走 B-tree 索引的原理作简要分析。后面将会涉及到索引访问方法的 opclass（操作符类）和 opfamily（操作符族）的概念，可以参考另一篇文章。分析创建一张表 test，具体的创建语句为：create table test(id int, c2 varchar(20)); insert into test select i, i from generate_series(1,100000)i; create index idx_test_id_1 on test(id); create index idx_test_c2_1 on test(c2); analyze test;一般场景如果我们执行explain select * from test where id > 1 and id < 10;（SQL 1）将会得到下面的执行计 ...继续阅读 (3)

背景LIKE 操作符是 PostgreSQL 支持的三种模式匹配方法之一。一般情况下，如果 SQL 中有模式匹配的过滤条件期望走索引，我们更推荐使用 GIN 或者 GIST 索引，同时配合创建一些插件，比如 pg_trgm，来达到更理想的效果。如果模式匹配字符串的模式以常量前缀开头，即满足前缀匹配，那么 B-tree 索引也可能被使用。能走 B-tree 索引的理论基础是因为前缀匹配可以被转换成一个范围查询。本文将对 LIKE 操作符前缀匹配走 B-tree 索引的原理作简要分析。后面将会涉及到索引访问方法的 opclass（操作符类）和 opfamily（操作符族）的概念，可以参考另一篇文章。分析创建一张表 test，具体的创建语句为：create table test(id int, c2 varchar(20)); insert into test select i, i from generate_series(1,100000)i; create index idx_test_id_1 on test(id); create index idx_test_c2_1 on test(c2); analyze test;一般场景如果我们执行explain select * from test where id > 1 and id < 10;（SQL 1）将会得到下面的执行计 ...继续阅读 (2)

1 背景通过前一篇文章的介绍，我们很容易能够动态地得到某个函数的执行时延。当函数的开销只是线程内部的计算时，我们可以判断出造成函数时延较大的原因。但当函数的开销依赖于其他线程时，如在一个信号量上等待其他线程唤醒，这时分析变得复杂起来。举两个例子。1.1 Redo 日志落盘分析在 MySQL 中，用户线程在提交写事务时需要等待写入的 redo 日志先落盘，确保当发生 crash recovery 后，事务能正常恢复。而 redo 日志的落盘是由多个后台线程配合的 [1]，只有后台线程 redo 日志写入的位点 (flush_to_lsn) 达到事务提交需要的位点 (commit_lsn) 时，由 log flush notifier 通知用户线程，事务才能提交。图 1: redo 日志落盘的线程等待时序图此时通过PT_PERF，我们能看到用户等待落盘的时延是 2.6 ms 左右，那么造成这 2.6 ms 等待开销是如何组成的呢？name : avg cnt sched_time cpu_pct(%)log_write_up_to : 2583821 1522 2352067 7.051.2 锁等待分析另一个在并发访问的场景，用户线程需 ...继续阅读 (5)

​Blob (binary large object)是 Innodb 中的一种大对象存储类型，既可以存储字符对象，也可以存入二进制对象，在需要存储空间需求较大的数据的场景下，应用非常广泛。​ 所有可变长度的类型如 VARCHAR, VARBINARY 以及 TEXT，当记录超过页大小的一半时 (如 16 KB 的页最大记录长度为 8 KB)，也都会尝试将记录中的较长的字段使用外部 BLOB 页进行存储，直到 record 大小满足要求，为了方便，我们将这些外部存储的数据都统称为 blob 数据。​ PolarDB 基于分布式共享存储的一写多读架构，面向在大字段写入场景做了大量性能优化，来充分利用底座分布式存储的高吞吐能力，实际测试中在优化后在高并发下能有接近 3 倍吞吐的性能提升。​ 我们先介绍 innodb 中的 blob 实现过程，前半部分主要给出 blob 的物理组织方式，后面介绍整体的并发写入机制。1 Blob 的外部存储​ 在 Innodb 中，当字段长度较小时，blob 数据可以像正常字段一样直接存入主键索引的记录内。当字段长度较大时，则会单独存入主键索引结构之外的 blob page 外部页中。图 1: Innodb 的索引组织​ 整个主键索引的 btree 结构因此包括两部分：一部分是存在主键索引上的小字段组成的 record，另一部分是存在外部 blob pa ...继续阅读 (4)

1 背景通过前一篇文章的介绍，我们很容易能够动态地得到某个函数的执行时延。当函数的开销只是线程内部的计算时，我们可以判断出造成函数时延较大的原因。但当函数的开销依赖于其他线程时，如在一个信号量上等待其他线程唤醒，这时分析变得复杂起来。举两个例子。1.1 Redo 日志落盘分析在 MySQL 中，用户线程在提交写事务时需要等待写入的 redo 日志先落盘，确保当发生 crash recovery 后，事务能正常恢复。而 redo 日志的落盘是由多个后台线程配合的 [1]，只有后台线程 redo 日志写入的位点 (flush_to_lsn) 达到事务提交需要的位点 (commit_lsn) 时，由 log flush notifier 通知用户线程，事务才能提交。图 1: redo 日志落盘的线程等待时序图此时通过PT_PERF，我们能看到用户等待落盘的时延是 2.6 ms 左右，那么造成这 2.6 ms 等待开销是如何组成的呢？name : avg cnt sched_time cpu_pct(%)log_write_up_to : 2583821 1522 2352067 7.051.2 锁等待分析另一个在并发访问的场景，用户线程需 ...继续阅读

线上高频慢查在PolarDB-MySQL线上慢查问题中，经常遇到因选中Index-Merge索引反而导致查询更慢的情况，这种情况一般是没有太好的通用解决办法，一般是建议客户针对查询force index来固化某个索引，或者使用NO_INDEX_MERGE 的hint关闭index merge选项。比如下面一个PolarDB客户的查询（已脱敏），优化器选择了Index Merge，但查询变的更慢了：*************************** 1. row *************************** id: 1 select_type: SIMPLE table: p partitions: NULL type: index_merge possible_keys: key1,key6,key8,key5,key7,key2,key4,key3 key: key7,key5 key_len: 254,17 ref: NULL rows: 63220 filtered: 10.00 Extra: Using intersect(key7,key5); Using where ## 查看Trace信息： ...继续阅读 (4)

线上高频慢查在PolarDB-MySQL线上慢查问题中，经常遇到因选中Index-Merge索引反而导致查询更慢的情况，这种情况一般是没有太好的通用解决办法，一般是建议客户针对查询force index来固化某个索引，或者使用NO_INDEX_MERGE 的hint关闭index merge选项。比如下面一个PolarDB客户的查询（已脱敏），优化器选择了Index Merge，但查询变的更慢了：*************************** 1. row *************************** id: 1 select_type: SIMPLE table: p partitions: NULL type: index_merge possible_keys: key1,key6,key8,key5,key7,key2,key4,key3 key: key7,key5 key_len: 254,17 ref: NULL rows: 63220 filtered: 10.00 Extra: Using intersect(key7,key5); Using where ## 查看Trace信息： ...继续阅读 (4)

背景作者在polardb下一个版本开发中修复了大量带groupby+rollup集合结果不正确的bug， 顺带抽象总结一下None SPJ算子执行流程，不理解思想的话，单纯通过代码逆向反推逻辑会耗费大量精力，希望本篇文章对于入坑mysql同学有帮助。代码基于版本是mysql 8.4.2。 先抛出一个问题，我们查看一个常见groupby+order by sql执行计划时，是什么？为什么一定要加一张临时表？CREATE TABLE t1 (a INT, b INT); INSERT INTO t1 (a, b) VALUES (1,1), (1,2), (1,3); INSERT INTO t1 SELECT a + 1, b FROM t1; mysql> desc format=tree SELECT a*a, sum(b)+1, count(1)+1 as cnt FROM t1 GROUP BY a ORDER BY cnt DESC; +----------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN ...继续阅读 (7)

背景作者在polardb下一个版本开发中修复了大量带groupby+rollup集合结果不正确的bug， 顺带抽象总结一下None SPJ算子执行流程，不理解思想的话，单纯通过代码逆向反推逻辑会耗费大量精力，希望本篇文章对于入坑mysql同学有帮助。代码基于版本是mysql 8.4.2。 先抛出一个问题，我们查看一个常见groupby+order by sql执行计划时，是什么？为什么一定要加一张临时表？CREATE TABLE t1 (a INT, b INT); INSERT INTO t1 (a, b) VALUES (1,1), (1,2), (1,3); INSERT INTO t1 SELECT a + 1, b FROM t1; mysql> desc format=tree SELECT a*a, sum(b)+1, count(1)+1 as cnt FROM t1 GROUP BY a ORDER BY cnt DESC; +----------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN ...继续阅读 (4)

有一些老的DBA 还记得在很早的时候, 坊间流传的是在MySQL里面单表不要超过500万行，单表超过 500 万必须要做分库分表. 有很多 DBA 同学担心MySQL 表大了以后, Btree 高度会变得非常大, 从而影响实例性能.其实 Btree 是一个非常扁平的 Tree, 绝大部分 Btree 不超过 4 层的, 我们看一下实际情况我们以常见的 sysbench table 举例子CREATE TABLE `sbtest1` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_1` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=10958 DEFAULT CHARSET=latin1在 InnoDB 里面主要 2 种类型 Page, leaf page and non-leaf pageLeaf Page 格式如下, 每一个 Record 主要由 Record Header + Record Body 组成, Record Header 主要用来配合 ...继续阅读 (6)

有一些老的DBA 还记得在很早的时候, 坊间流传的是在MySQL里面单表不要超过500万行，单表超过 500 万必须要做分库分表. 有很多 DBA 同学担心MySQL 表大了以后, Btree 高度会变得非常大, 从而影响实例性能.其实 Btree 是一个非常扁平的 Tree, 绝大部分 Btree 不超过 4 层的, 我们看一下实际情况我们以常见的 sysbench table 举例子CREATE TABLE `sbtest1` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_1` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=10958 DEFAULT CHARSET=latin1在 InnoDB 里面主要 2 种类型 Page, leaf page and non-leaf pageLeaf Page 格式如下, 每一个 Record 主要由 Record Header + Record Body 组成, Record Header 主要用来配合 ...继续阅读 (3)

在 PostgreSQL 数据库中，Event Trigger（事件触发器）是一种触发机制，用于响应特定的数据库事件。与常规的 DML 触发器（响应行级别或语句级别操作）不同，事件触发器在 DDL 操作的生命周期中触发，触发时执行用户指定的存储过程或函数，可以用于监控或限制数据库结构的变更。 本文对事件触发器的 tag 这个小特性进行简单的原理分析，文中提到的函数和数据结构来源于PostgreSQL 15 源码。简介创建事件触发器的语法如下，允许使用filter_variable指定触发条件，确保触发器只在发生某些特定事件时触发。从 PostgreSQL官方文档可知，当前 PostgreSQL 唯一支持的filter_variable是 tag。CREATEEVENTTRIGGERnameONevent[WHENfilter_variableIN(filter_value[,...])[AND...]]EXECUTE{FUNCTION|PROCEDURE}function_name()通过一个示例来说明 tag 的用法。PostgreSQL 中有ddl_command_start、ddl_command_end、table_rewrite和sql_drop这四种事件类型，我们全文都以ddl_command_start事件为例，其他事件的处理逻辑是类似的。假设有下面这样一个触发器函数 ...继续阅读 (4)

在 PostgreSQL 数据库中，Event Trigger（事件触发器）是一种触发机制，用于响应特定的数据库事件。与常规的 DML 触发器（响应行级别或语句级别操作）不同，事件触发器在 DDL 操作的生命周期中触发，触发时执行用户指定的存储过程或函数，可以用于监控或限制数据库结构的变更。 本文对事件触发器的 tag 这个小特性进行简单的原理分析，文中提到的函数和数据结构来源于PostgreSQL 15 源码。简介创建事件触发器的语法如下，允许使用filter_variable指定触发条件，确保触发器只在发生某些特定事件时触发。从 PostgreSQL官方文档可知，当前 PostgreSQL 唯一支持的filter_variable是 tag。CREATEEVENTTRIGGERnameONevent[WHENfilter_variableIN(filter_value[,...])[AND...]]EXECUTE{FUNCTION|PROCEDURE}function_name()通过一个示例来说明 tag 的用法。PostgreSQL 中有ddl_command_start、ddl_command_end、table_rewrite和sql_drop这四种事件类型，我们全文都以ddl_command_start事件为例，其他事件的处理逻辑是类似的。假设有下面这样一个触发器函数 ...继续阅读 (4)

本文介绍了PolarStore的弹性内存池（Elastic Memory Pool，简称 EMP）技术，结合高速网络和智能缓存，大幅降低数据读取延迟，提升PolarDB在I/O密集型负载下的性能表现。背景介绍PolarStore为PolarDB提供低延迟、高吞吐量的高性能数据存储服务。作为数据库的核心组成部分，PolarStore负责将数据从存储层高效地读取到数据库内存，这在I/O密集型负载场景下至关重要。为了进一步提升性能，PolarStore基于PolarDB三层解耦架构的优势，推出了弹性内存池（Elastic Memory Pool，简称 EMP）功能。EMP利用分布式高速RDMA网络和高速介质，智能缓存热点数据，无需您感知或适配。在EMP的加持下，PolarStore数据读取延迟最高可降低5倍，显著提升PolarDB整体性能，在 I/O密集型负载下吞吐量提升可达90%。EMP功能介绍功能简介数据库的缓存池（Buffer Pool）是内存中用于缓存磁盘数据的区域。当需要访问数据时，先从Buffer Pool中读取，若数据在Buffer Pool未命中，则需要从底层存储中获取数据，相比内存访问，IO操作会增加网络和读盘延迟，这将直接影响数据库的性能。因为单台主机的内存限制，单个数据库集群Buffer Pool的大小非常有限。为了解决这个问题，PolarStore的EMP功能应运 ...继续阅读 (8)

本文介绍了PolarStore的弹性内存池（Elastic Memory Pool，简称 EMP）技术，结合高速网络和智能缓存，大幅降低数据读取延迟，提升PolarDB在I/O密集型负载下的性能表现。背景介绍PolarStore为PolarDB提供低延迟、高吞吐量的高性能数据存储服务。作为数据库的核心组成部分，PolarStore负责将数据从存储层高效地读取到数据库内存，这在I/O密集型负载场景下至关重要。为了进一步提升性能，PolarStore基于PolarDB三层解耦架构的优势，推出了弹性内存池（Elastic Memory Pool，简称 EMP）功能。EMP利用分布式高速RDMA网络和高速介质，智能缓存热点数据，无需您感知或适配。在EMP的加持下，PolarStore数据读取延迟最高可降低5倍，显著提升PolarDB整体性能，在 I/O密集型负载下吞吐量提升可达90%。EMP功能介绍功能简介数据库的缓存池（Buffer Pool）是内存中用于缓存磁盘数据的区域。当需要访问数据时，先从Buffer Pool中读取，若数据在Buffer Pool未命中，则需要从底层存储中获取数据，相比内存访问，IO操作会增加网络和读盘延迟，这将直接影响数据库的性能。因为单台主机的内存限制，单个数据库集群Buffer Pool的大小非常有限。为了解决这个问题，PolarStore的EMP功能应运 ...继续阅读 (2)

lehman blink-tree and Vladimir Lanin cocurrent BtreePosegreSQL blink-tree 实现方式引用了两个文章Lehman and Yao’s high-concurrency B-tree management algorithmV. Lanin and D. Shasha, A Symmetric Concurrent B-Tree AlgorithmMySQL InnoDB 的 btree 实现主要参考的是R. Bayer & M. Schkolnick Concurrency of operations on B-trees March 1977lehman blink-treeBlink-tree 的 2 个核心变化Adding a single “link” pointer field to each node.这里有一个当时时间点的背景, 我们现在见到的大部分的 Btree 实现里面, 都会有 left/right point 指向 left/right page. 但是当时对标准 Btree 的定义并没有这个要求. Btree 是非叶子节点也保存数据, B+tree 是只有叶子节点保存数据, 从而使 btree height 尽可能低. 但是并没有严格的要求把叶子节点连接到一起.但是总体而言, 对 Btr ...继续阅读 (10)

lehman blink-tree and Vladimir Lanin cocurrent BtreePosegreSQL blink-tree 实现方式引用了两个文章Lehman and Yao’s high-concurrency B-tree management algorithmV. Lanin and D. Shasha, A Symmetric Concurrent B-Tree AlgorithmMySQL InnoDB 的 btree 实现主要参考的是R. Bayer & M. Schkolnick Concurrency of operations on B-trees March 1977lehman blink-treeBlink-tree 的 2 个核心变化Adding a single “link” pointer field to each node.这里有一个当时时间点的背景, 我们现在见到的大部分的 Btree 实现里面, 都会有 left/right point 指向 left/right page. 但是当时对标准 Btree 的定义并没有这个要求. Btree 是非叶子节点也保存数据, B+tree 是只有叶子节点保存数据, 从而使 btree height 尽可能低. 但是并没有严格的要求把叶子节点连接到一起.但是总体而言, 对 Btr ...继续阅读 (7)

pg_repack 是 PostgreSQL 数据库生态的一款第三方插件，本文将结合 pg_repack 的源代码来介绍其原理，而不会介绍如何使用它。如果想了解 pg_repack 的具体用法，可以参考 pg_repack 的官方文档或 PolarDB PostgreSQL 版的pg_repack 文档。简介pg_repack 的字面意思是“重新包装”，可以回收碎片化的存储空间，解决表和索引的存储空间膨胀问题。PostgreSQL 内核自带的VACUUM FULL和CLUSTER功能同样可以重写表并解决存储空间膨胀问题，为何还要开发一个 pg_repack 插件来做同样的事？这是因为VACUUM FULL和CLUSTER需要锁表，可能导致业务长时间无法进行数据读写，而 pg_repack对读写请求的阻塞时间很短，对业务影响更小，这就是它相比VACUUM FULL和CLUSTER最大的优势。pg_repack 以安装在 PostgreSQL 数据库侧的 pg_repack 插件作为服务端，并提供 pg_repack 客户端给用户，两者需要搭配使用，用户执行一条形如pg_repack --table=my_table的 shell 命令，客户端会连接到服务端去执行表重写的操作。为什么需要一个单独的客户端，而不能让用户直接连接到数据库去执行类似SELECT repack_table('m ...继续阅读 (12)

pg_repack 是 PostgreSQL 数据库生态的一款第三方插件，本文将结合 pg_repack 的源代码来介绍其原理，而不会介绍如何使用它。如果想了解 pg_repack 的具体用法，可以参考 pg_repack 的官方文档或 PolarDB PostgreSQL 版的pg_repack 文档。简介pg_repack 的字面意思是“重新包装”，可以回收碎片化的存储空间，解决表和索引的存储空间膨胀问题。PostgreSQL 内核自带的VACUUM FULL和CLUSTER功能同样可以重写表并解决存储空间膨胀问题，为何还要开发一个 pg_repack 插件来做同样的事？这是因为VACUUM FULL和CLUSTER需要锁表，可能导致业务长时间无法进行数据读写，而 pg_repack对读写请求的阻塞时间很短，对业务影响更小，这就是它相比VACUUM FULL和CLUSTER最大的优势。pg_repack 以安装在 PostgreSQL 数据库侧的 pg_repack 插件作为服务端，并提供 pg_repack 客户端给用户，两者需要搭配使用，用户执行一条形如pg_repack --table=my_table的 shell 命令，客户端会连接到服务端去执行表重写的操作。为什么需要一个单独的客户端，而不能让用户直接连接到数据库去执行类似SELECT repack_table('m ...继续阅读 (6)

背景PostgreSQL 是多进程架构，它的内存架构可以划分为两大类：共享内存（shared memory area）和本地内存（local memory area）。除了动态申请的共享内存外，绝大多数共享内存是在 Postmaster 启动时分配，具有固定大小，因此内存管理相对简单，不易发生内存泄漏。而每个后端进程还必须管理自己的本地内存来完成请求的处理，这部分的内存管理比较棘手。这是因为 PostgreSQL 内核主要采用 C 语言编写，程序必须显式释放所有动态分配的内存，并且 PostgreSQL 中需要处理大量的以指针传值的逻辑，很容易产生难以排查的内存泄漏问题。内存泄漏对于多进程架构的影响是致命的，所以更好地管理本地内存是 PostgreSQL 实现中的一个重要环节。从 7.1 版本开始，PostgreSQL 引入了内存上下文（MemoryContext）机制来管理本地内存。这个机制很好地解决了内存泄漏问题；同时也提高了内存分配效率，避免了内存碎片化的产生；也让内存管理有了生命周期。MemoryContext 简介MemoryContext 本质上是对内存进行分层和分类。一个 MemoryContext 实际上是一个内存池，代表一类内存。不同的 MemoryContext 组成了一个树状结构，代表了不同种类内存之间的联系。在运行过程中，开发者可以根据自己的需要创建和删除 ...继续阅读 (12)

背景PostgreSQL 是多进程架构，它的内存架构可以划分为两大类：共享内存（shared memory area）和本地内存（local memory area）。除了动态申请的共享内存外，绝大多数共享内存是在 Postmaster 启动时分配，具有固定大小，因此内存管理相对简单，不易发生内存泄漏。而每个后端进程还必须管理自己的本地内存来完成请求的处理，这部分的内存管理比较棘手。这是因为 PostgreSQL 内核主要采用 C 语言编写，程序必须显式释放所有动态分配的内存，并且 PostgreSQL 中需要处理大量的以指针传值的逻辑，很容易产生难以排查的内存泄漏问题。内存泄漏对于多进程架构的影响是致命的，所以更好地管理本地内存是 PostgreSQL 实现中的一个重要环节。从 7.1 版本开始，PostgreSQL 引入了内存上下文（MemoryContext）机制来管理本地内存。这个机制很好地解决了内存泄漏问题；同时也提高了内存分配效率，避免了内存碎片化的产生；也让内存管理有了生命周期。MemoryContext 简介MemoryContext 本质上是对内存进行分层和分类。一个 MemoryContext 实际上是一个内存池，代表一类内存。不同的 MemoryContext 组成了一个树状结构，代表了不同种类内存之间的联系。在运行过程中，开发者可以根据自己的需要创建和删除 ...继续阅读 (9)

本文简单介绍 PostgreSQL 数据库如何对 INSERT 语句中的常量进行合法性检查，检查逻辑从上到下涉及到词法分析、语法解析、语义分析、查询优化、参数绑定、执行器等多个模块。全文的所有代码都以 PostgreSQL 14 为例，所有 SQL 示例都基于如下表定义：CREATETABLEtest_table(column_charCHAR(3),column_intINT,column_numNUMERIC(4,2));词法&语法解析在src/backend/parser/scan.l中进行词法分析，以INSERT INTO test_table VALUES('123', 123, 1.23, 123456789123456789, 1.x)语句为例：字符串  ’123’  识别为 Sconst，即 String Const，字符串常量；浮点数  1.23  识别为 FCONST，即 Float Const，浮点数常量；整数  123  识别为 ICONST，即 Integer Const，整数常量；超过 INT 类型上限的整数  123456789123456789  则无法用 ICONST 表达，在process_integer_literal函数中会判断数字是否超过了 INT 的范围，超过则识别为 FCONST：……if(*endptr!='\0'||errno==E ...继续阅读 (11)