有一些老的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 主要用来配合 ...继续阅读 (15)

在 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事件为例，其他事件的处理逻辑是类似的。假设有下面这样一个触发器函数 ...继续阅读 (15)

在 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事件为例，其他事件的处理逻辑是类似的。假设有下面这样一个触发器函数 ...继续阅读 (9)

本文介绍了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功能应运 ...继续阅读 (14)

本文介绍了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)

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 ...继续阅读 (14)

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 ...继续阅读 (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 ...继续阅读 (17)

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 ...继续阅读 (10)

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

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

本文简单介绍 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 ...继续阅读 (17)

本文简单介绍 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 ...继续阅读 (9)

背景在我们线上的客户有一个实例，在每天固定的时间都会出现慢SQL的问题；该用户线上业务对于SQL执行的时间较为严格，执行时间超过150ms就认为是慢SQL。 在以往的排查经验中，认为这类慢SQL的问题一般都是锁等待的问题，或者是底层文件系统的IO抖动造成的；但是这次我们都排查过一番，出现慢SQL语句的锁等待很低；而且在底层的文件系统虽然偶尔会有一些长尾的慢IO的情况，但是和慢SQL出现的时间对不上。 后面我们尝试使用线上版本复现用户的这个场景，后来终于在模拟了线上用户执行SQL的模式和压力后，复现了线上出现慢SQL的场景。我们尝试对这个实例进行打栈后发现一些蛛丝马迹，怀疑可能和IO有关系；因为用户请求的栈最后落到了IO上面；但是这并不能说明和IO一定有关系，因为我们打栈时的情况并不一定是出现慢SQL时的情况。 此时，我们需要一个工具来精确的分析出慢SQL到底是怎么执行的，这样我们才能具体的分析出问题的根本原因；所以我们借助PT_PERF工具来分析一下这次慢SQL具体的执行过程。排查过程通过PT_PERF 使用介绍这篇文章我们可以非常精确的知道每一个函数的执行时间；那么我们知道MySQL处理用户请求的入口函数是do_command，那么我们在获取到进程号，和执行do_command的线程号后就可以通过下面这个命令就可以查看到这个函数在处理用户请求时执行的一些具体情况：//首先通过-- ...继续阅读 (19)

背景在我们线上的客户有一个实例，在每天固定的时间都会出现慢SQL的问题；该用户线上业务对于SQL执行的时间较为严格，执行时间超过150ms就认为是慢SQL。 在以往的排查经验中，认为这类慢SQL的问题一般都是锁等待的问题，或者是底层文件系统的IO抖动造成的；但是这次我们都排查过一番，出现慢SQL语句的锁等待很低；而且在底层的文件系统虽然偶尔会有一些长尾的慢IO的情况，但是和慢SQL出现的时间对不上。 后面我们尝试使用线上版本复现用户的这个场景，后来终于在模拟了线上用户执行SQL的模式和压力后，复现了线上出现慢SQL的场景。我们尝试对这个实例进行打栈后发现一些蛛丝马迹，怀疑可能和IO有关系；因为用户请求的栈最后落到了IO上面；但是这并不能说明和IO一定有关系，因为我们打栈时的情况并不一定是出现慢SQL时的情况。 此时，我们需要一个工具来精确的分析出慢SQL到底是怎么执行的，这样我们才能具体的分析出问题的根本原因；所以我们借助PT_PERF工具来分析一下这次慢SQL具体的执行过程。排查过程通过PT_PERF 使用介绍这篇文章我们可以非常精确的知道每一个函数的执行时间；那么我们知道MySQL处理用户请求的入口函数是do_command，那么我们在获取到进程号，和执行do_command的线程号后就可以通过下面这个命令就可以查看到这个函数在处理用户请求时执行的一些具体情况：//首先通过-- ...继续阅读 (9)

在 PostgreSQL 中，子事务（也称为 “savepoints”）是事务管理中的一个高级特性，它允许用户在一个大的事务内部定义一个或多个savepoints点。这些savepoints允许在发生错误时回滚到某个savepoint，而不是整个事务。子事务是非常有用的，尤其是在事务内处理一系列复杂的操作时，需要在发生错误后从中间的某个操作开始恢复，而不是完全从头开始。子事务的作用典型的子事务的用法包括错误恢复：如果一个事务中的语句失败，可以回滚到最近的 savepoint，而不是回滚整个事务。BEGIN; -- 开始一个新的事务 INSERT INTO orders (product_id, quantity, cost) VALUES (1, 10, 99.99); SAVEPOINT before_next_operation; -- 尝试另一个操作，可能会失败，例如违反约束 INSERT INTO orders (product_id, quantity, cost) VALUES (2, 20, 199.99); -- 假设上面的插入失败了，可以回滚到savepoint ROLLBACK TO SAVEPOINT before_next_operation; COMMIT;-- 完成事务，插入成功一行存储过程中EXCEPTION块，也会隐式的开启子事务，以便于在异常出现时 ...继续阅读 (27)

PolarDB for MySQL在优化冷数据查询性能方面，聚焦于两项核心技术策略：OSS数据筛选与OSS冷数据并行查询技术。首先，OSS数据筛选机制通过利用高度针对性的列属性预处理，实现对数据对象的智能过滤。这一策略能够显著缩减数据扫描范围，避免不必要的时间消耗于无关数据的检索上，从而大幅提升查询效率与系统响应速度。另一方面，OSS冷数据并行查询技术，则是通过并发查询执行模型，即增加并发查询线程或任务的数量，来并行处理大规模数据集。此方法充分利用了现代计算资源的多核特性，实现了查询负载在多个处理单元间的均衡分配，极大缩短了查询响应时间。特别是针对数据量庞大的冷数据查询场景，该技术能够有效克服单线程处理的瓶颈，确保查询操作的高效执行与资源的最大化利用。以下详细介绍二者的使用方法和适用场景。OSS_FILE_FILTER查询优化8.0.2.2.25版本的冷数据查询功能已经支持了OSS文件筛选OSS FILE FILTER功能，该功能通过利用查询条件预前锁定数据存储位置，实现了数据检索策略的优化升级。相较于传统的并行查询方法，OSS FILE FILTER展现出更高的资源效率，在具备有利筛选条件的场景下，其查询性能的提升效果尤为显著，这不仅归功于减少了不必要的数据扫描，还有效提升了处理速度与系统响应能力。使用方法这里以经典的lineitem表作为分析案例，介绍如何使用OSS FILE ...继续阅读 (23)

过去，PolarDB在处理归档的冷数据时，遇到的主要挑战之一是对数据定义语言（DDL）操作的兼容性和效率问题，尤其是在执行诸如增加列、调整列宽等操作时。由于这些操作通常要求数据重写，通过COPY机制来实现，导致了极高的资源消耗和执行成本。这一局限性在持续归档至OSS外表的场景中尤为突出，给数据管理和运维工作带来了不便。 为应对这一挑战，我们引入了OSS META功能。该功能通过增强对冷数据的元数据管理能力，使得特定的DDL操作能够以即时（INSTANT）模式执行，从根本上优化了冷数据处理的灵活性和效率。这意味着，在OSS META功能启用状态下，系统能够智能识别并应用DDL变更，而无需经历传统意义上的全量数据重写流程。下面举一个例子详细介绍：分区归档至外表例如：客户有一张订单分区表，以订单创建时间作为分区键，每年一个分区。假设超过5年后，我们认为该订单被查询的几率不大，可以归档至OSS冷数据。其订单表结构如下：MySQL>showcreatetableOrders;+--------+----------------------------------------------------------------------------------------------+|Table|CreateTable|+--------+--------------------------- ...继续阅读 (27)

MySQL semijoin 也被称为半连接，主要是解决外查询一个或多个表的记录在包含一个或多个表的子查询结果中的存在性问题，比如 IN/EXIST 子查询。如果按照 IN/EXIST 谓词的原语义去执行，对外查询的每行记录都去计算 IN/EXIST 谓词的结果，子查询的内容就需要单独执行，在关联子查询的情况下，子查询需要多次重复执行，整体的执行效率很低。实际上，部分存在性问题(SPJ 子查询)类似于外查询的多个表与子查询的多个表(以下简述为外表和内表)的连接(JOIN)问题，能连接上说明存在。但是与普通 JOIN 不同的点在于，当外表和内表 JOIN 的时候，外表的每行记录都有可能和内表的多行连接上，这就导致了外表行的重复记录，但是按照原语义 IN/EXIST 子查询只是对外表行上进行的过滤，数据只能减少，而不能膨胀。如何在外表和内表 JOIN 的同时保证这一点呢？MySQL 中实现了四种执行策略来避免重复行：Materialize、DuplicateWeedOut、FirstMatch 和 LooseScan，以下是几种执行方式的简单概括和示意图。示意图均以该 SQL 举例：select*fromCountrywhereCountry.codeIN(selectCity.CountryfromCitywhereCity.Population>7*1000*1000)andCou ...继续阅读 (27)

前言在关系型数据库的查询处理中，数据库优化器是一项关键技术，它负责将用户写的SQL查询语句转化为高效的执行计划。连接操作（JOIN）是SQL语句中最常见也最为耗时的运算操作之一，但在某些情况下，连接可能由于表设计或查询逻辑而无需执行。PolarDB优化器的连接消除功能旨在通过分析表定义、查询条件和连接方式等情况，识别和移除查询计划中不必要的连接操作，从而提高查询执行速度。考虑一个常见的业务场景，业务方定义了一个涉及订单明细表（lineitem）与配件表（part）的外连接（OUTER JOIN）的视图，其中partkey是配件表的主键。CREATEVIEWvASSELECT*FROM...,lineitemLEFTJOINpartONlineitem.partkey=part.partkey;如果在一次查询中，需求方只需要lineitem表中的信息，那么他的查询语句可能写成SELECTl_colsFROMv;这里l_cols表示lineitem表中的任意列。根据SQL的语义，由于lineitem与part表以左连接方式连接，因此lineitem表中的每一行都会在连接结果中出现；另一方面，由于partkey是part表的主键，因此lineitem表中的每一行只能与part表中最多一行满足连接条件。因此，连接结果中的每一行与lineitem表中的每一行一一对应。又因为需求方的查询语句中 ...继续阅读 (26)

InnoDB 全文索引（FTS，以下默认指 InnoDB 中的 FTS）是通过在文本数据上建立倒排索引的方式，加速文本搜索的功能。和普通二级索引一样，FTS 也提供快速搜索和按条件过滤的能力，并额外支持计算文本相关性，提供按搜索相关性排序的能力。设计逻辑FTS 是倒排索引，对索引列上的文本分词并建立映射：分词 → 记录 + 记录中的位置。FTS 通过原表上一个额外的隐藏列定位到具体的行，每行有一个唯一的标志doc_id，类似于自增唯一索引，并且在文本更新时也会触发产生新的doc_id。为了记录倒排索引和相关信息，FTS 为带有 FTS 索引的表维护多张额外的表。这些表的维护穿插在常规建表/插入/删除等逻辑中。因为原表的一个修改可能对应倒排索引的大量修改，FTS 在设计上尽可能推迟倒排索引上的修改，新增文本的索引项不随事务提交而落盘，只写入内存 cache，由额外的“同步”操作触发索引的修改删除文本的不删除 FTS 索引，仅记录删除的行，在 optimize 时触发真正的删除这也间接导致了 FTS 的数据可见性与常规数据不同：FTS 索引的修改只在提交时产生，新增数据对当前事务也不可见FTS 上的查询不受事务可见性影响。对其他事务，FTS 索引中的数据相当于是 READ-COMMITTED 的创建 FTS同普通二级索引一样，FTS 索引可以在建表时指定，也可以通过alter tabl ...继续阅读 (38)

查询优化是数据库管理非常重要的一个方面，而使用合适的查询优化分析方法可以大幅提升效率。本文将要介绍查询优化中常用的分析方法，包括EXPLAIN命令、Optimizer Trace、Profiling、常用的监控指标。MySQL查询优化分析系列文章，前文有：《MySQL查询优化分析 - MySQL优化执行的基础概念》：介绍了MySQL优化器框架、代价模型、执行计划的基础概念，影响执行效率和计划选择的关键因素。EXPLAIN查看解读执行计划查询优化分析中，EXPLAIN是一个极为常用的命令。我们通过EXPLAIN来查看查询的执行计划，包括选择了哪个索引路径、访问方式、JOIN ORDER、估算的扫描行数、选择率等信息。语法EXPLAIN主要语法如下：EXPLAIN [ANALYZE] [FORMAT= [TRADITIONAL | JSON | TREE]] explainable_stmt; EXPLAIN FOR CONNECTION connection_id。EXPLAIN展示信息的解读EXPLAIN explainable_stmt与EXPLAIN FORMAT=TRADITIONAL explainable_stmt等价。 其展示的各个列的信息如下：列名说明id显示Query Block的序列号。select_type显示本QueryBlock的类型table表名（别名)。 ...继续阅读 (30)

ROLLUP 功能简述ROLLUP 可以在普通的 GROUP BY 聚合的情况下，增加更多层次的聚集输出。比如以下这条 SQL：SELECTyear,country,product,SUM(profit)ASprofitFROMsalesGROUPBYyear,country,productWITHROLLUP;除了计算按照年份、国家、产品分组的利润总和，也会计算按照年份、国家(GROUP BY year, country)，按照年份(GROUP BY year)和所有(No GROUP BY)的利润总和。结果如下：+------+---------+------------+--------+|year|country|product|profit|rolluplevel+------+---------+------------+--------+|2000|Finland|Computer|1500|3<-- GROUP BY year, country, product|2000|Finland|Phone|100|3|2000|Finland|NULL|1600|2<-- GROUP BY year, country|2000|India|Calculator|150|3|2000|India|Computer|1200|3|2000|India|NULL|1350|2< ...继续阅读 (29)

在上一篇文章PT_PERF: 基于 Intel PT 的时延性能分析工具中，我们介绍了 Intel Processor Trace 时延分析工具的背景，功能和实现。本篇文章我们主要介绍一下如何使用 PT_PERF 工具查看任意函数的执行时间，包括 on-cpu 和 off-cpu 的时间。1 背景时延是我们最直接判断一个函数执行效率的方式。我们最为习惯的是在编译前对程序埋点，但这费时费力，并且修改代码可能影响了程序的执行行为，造成统计误差。借助eBPF 的 func_latency 工具和 dynamic instrumentation 技术，我们能够在不修改程序的情况下，统计函数时延，但通常工具的使能开销就是 2000 cpu cycles，并且在高频函数调用下，工具对程序性能的影响达到 50% 以上。举个例子，我们对 MySQL 启动一个 32 线程的 sysbench oltp_read_only 只读负载，在 91 秒使用 eBPF 统计 1s 时间 MySQL innodb 中 ‘row_search_mvcc’ 的函数时延。此时 MySQL 的 QPS 从 30 w 下降到了 7.8 w。[90s]thds: 32 tps: 19488.04 qps: 301753.61[91s]thds: 32 tps: 4912.97 qps: 78695.49# start e ...继续阅读 (36)

1 背景1.1 常用性能分析方法程序性能一直是开发人员和用户特别关注的指标，但其调优分析也是最为艰难的一个过程。作为系统研发人员，我们会花费大量时间来分析系统的性能瓶颈、定位开发过程中引入的性能回退，并解决可能周期性发生的性能抖动问题。根据线程的执行模型，即是否调度在 CPU 上执行指令，我们通常会从 on-CPU 和 off-CPU 两个角度进行分析[1]。在 on-CPU 分析中，我们关注那些正在 CPU 上执行指令的线程，以识别 CPU 指令执行的热点。而 off-CPU 分析则关注那些不在 CPU 上执行指令的时间，比如等待磁盘 I/O、锁或网络传输等资源。CPU 是负责执行指令的核心部件。我们可以使用 perf 工具对 CPU 上执行的指令进行采样，通过 perf report 或者创建 on-CPU 的火焰图，从而了解大部分 CPU 执行的指令时间主要集中在哪些函数上。这些采样数据主要基于性能监控计数器（PMC）提供的硬件溢出中断（PMI），通过这种方式，CPU 周期性地向内核传递当前指令的位置（ip）。内核利用当前线程的栈帧或者程序的 dwarf 信息来构建函数调用栈。通过在一定频率下的采样，尤其是在 CPU 密集型负载下，我们可以确定大部分的性能瓶颈所在。然而，在非 CPU 密集型的场景下，比如大量 IO 操作、等待锁或主动休眠等情况，CPU 利用率很低。在数据库场 ...继续阅读 (32)

前言在数据库中，业务查询的性能优化是维护系统效率和稳定性的关键因素。我们在处理查询性能优化时，常常会面对：查询缓慢的原因分析，优化器在计划选择中为何出现误判，如何提升查询执行效率等种种问题。MySQL查询优化分析会通过数篇文章去讲解如何分析与优化MySQL查询性能，将会围绕MySQL优化执行的基础概念、PolarDB MySQL的查询优化和执行加速相关功能、查询分析工具与方法、常见的查询性能问题与解决方式展开叙述。本文MySQL查询优化分析系列的第一篇文章，介绍MySQL优化执行的基础概念。用户查询经过词法、语法解析后，由优化器分析选择执行计划，经过执行器执行返回客户数据。本文分别介绍MySQL优化器框架、代价模型，MySQL基表访问、JOIN、子查询执行方式。通过这些内容，对MySQL优化器计划的选择，执行计划的执行方式有一个基础的了解。MySQL优化器框架优化器基于各类元数据信息和数据库收集的统计信息，选择其认为代价最低的执行计划。MySQL优化器的主要流程如下：逻辑优化对查询做逻辑等价变换，例如semi-join、子查询解关联、谓词下推、视图合并、左连接转内连接、等值推导等。对查询做等价变换后，查询生成更优的执行计划，有更多的计划选择。初始的优化分析对表各个可能的访问路径做一个扫描行数和代价分析。扫描行数和代机的分析，可以帮助后续选择合适的基表路径，有初始的Join表排序帮助 ...继续阅读 (44)

背景简介Saas下多租户模式相对于单租户模式的典型区别在于单租户模式一般通过硬件来进行物理上的隔离，每个租户购买自己的数据库实例；而多租户模式下各租户同在一个实例下共享计算/存储资源，需要考虑数据安全层面的隔离和性能层面的隔离。 MySQL本身对多租户并无特别的原生支持。在MySQL下实现多租户的手段一般可以分为三种方式：独立数据库：一个租户一个数据库 ，物理意义上的数据隔离，类似单租户模式共享数据库+独立Schema：所有租户共享Database，但是每个租户一个Schema，逻辑上进行了数据隔离共享数据库+共享Schema+共享数据表：通过在表中增加TenantID多租户的数据字段来区分不同租户 三种方式数据独立性逐渐降低，共享度上升，但均无法实现性能资源上的隔离。PolarDB MySQL 单实例多租户模式可以使得多个租户在同一实例下共享计算/存储资源，同时保证各租户下的数据隔离，保证租户仅能访问到自己的数据，以及各租户下的资源隔离，确保租户间不会出现资源争抢，保障业务稳定运行。PolarDB MySQL 单实例多租户模式方案解决了以下一些客户业务痛点：Saas多租户业务场景需要为每个租户创建不同库/表，业务代码需要针对每个租户进行适配。关键业务在其他业务突发流量时无法保证资源分配，导致关键业务处理能力受到影响。专有名词解释租户：租户(Tenant)为实现单实例多租户模式所提 ...继续阅读 (35)

In our user environment, we find deadlock cause by this example.However, in this case, sometimes session 2 and session 3 lead to dead lock and sometimes it won’t.create table t(a int AUTO_INCREMENT, b int, PRIMARY KEY (a)); insert into t(a, b) values(10, 8); insert into t(a, b) values(5, 8); session 1: begin; delete from t where a=5; session 2: insert into t(a, b) values (5, 8) on duplicate key update b = 11; session 3: insert into t(a, b) values (5, 8) on duplicate key update b = 11; session 1: commit; # Then sometimes session 2 and session 3 lead to dead lock and sometimes it won't.I fin ...继续阅读 (56)

在之前的文章介绍了由于二级索引 unique key 导致的 deadlock, 其实主键也是 unique 的, 那么同样其实主键的 unique key check 一样会导致死锁.主键 unique 的判断在row_ins_clust_index_entry_low这里有一个判断if (!index->allow_duplicates && n_uniq && (cursor->up_match >= n_uniq || cursor->low_match >= n_uniq))这里判断的意思是:如果当前 index 是 unique index, (cursor->up_match >= n_uniq || cursor->low_match >= n_uniq) cursor 找到和插入的 record 一样的 record 了. 那么就需要走 row_ins_duplicate_error_in_clust. 对于普通的INSERT操作, 当需要检查primary key unique时, 加 S record lock. 而对于Replace into 或者 INSERT ON DUPLICATE操作, 则加X record lock否则就是当前index 没有插入过这个 record, 也就是第一次 insert primary key, 那么就不需要 ...继续阅读 (34)

这篇文章主要介绍我们在PolarDB MySQL这个产品中，针对优化器组件新构建的一套查询改写框架。这个框架意在解决开源数据库产品中基本都存在的一个基础顽疾，让PolarDB可以为复杂查询生成更优的执行计划，从而提升Ad-Hoc分析查询的执行速度，进一步提升PolarDB处理混合负载的能力。优化器到底是什么我们都知道关系型数据库一般使用SQL作为与数据库交流的语言。而作为一种声明式的结构化语言，SQL是简单且相当贴合人类的思维与表述方式的，这应该也是它经久不衰的原因之一，但这种对人类友好的方式对数据库则正好相反，数据库需要基于SQL描述的目标，在内部建立一个真正可以获取或修改数据的执行方式，这个工作就是由优化器来完成的。 优化器本质上是一个搜索器，最粗暴的做法是，我们可以把所有数据的访问方式，各个表的相互join方式、join顺序、各个算子的执行方式等全部枚举+组合起来，形成一系列的执行计划，然后为每个执行计划估算一个代价分数来衡量这个计划的执行情况（延迟、资源…），选择其中最优执行方案。显然这并不现实，但思路也就是这么个思路，其余的工作就落入了如下几个方向：如何尽量丰富的枚举出必要的候选计划，避免漏掉最优的可能如何提升搜索空间中的枚举效率，避免考虑不必要的可能计划如何给每个候选计划一个准确的评估分数，最能反映我们的优化目标… 最为核心的应该就是前面3个，第3个问题涉及到统计信息、 ...继续阅读 (37)