本篇文章主要用代码代码结合一些图来看。实现一个 无锁哈希表，一共需要考虑实现以下几点：无锁动态数组线程间如何管理内存，避免释放无锁链表下面我们先一一介绍 MySQL 是如何实现的，最后介绍无锁哈希表实现。1 无锁动态数组 LF_DYNARRAYLF_DYNARRAY 总共 分为 4 层，每层能容纳的元素是指数级别增加的，如第 0 层能存储 255 个元素，每个 n + 1 层包含 255 个 n 层顶长数组。这样来支持不同纬度的内存扩展。最长支持 4311810304 个元素。LF_HASH 几乎所有涉及数组部分都是基于 LF_DYNARRAY。typedefstruct{std::atomiclevel[LF_DYNARRAY_LEVELS];// 每个 level 的数组其实地址uintsize_of_element;// 数组 element 占据的内存大小}LF_DYNARRAY;voidlf_dynarray_init(LF_DYNARRAY*array,uintelement_size);几个数组操作重要的函数：// 按 idx 索引数组元素，不存在就申请空间，返回申请空间的位置void*lf_dynarray_lvalue(LF_DYNARRAY*array,uintidx);// 遍历数组元素，调用传入的回调 func，自定义的 func 需要处理每个 level ...继续阅读 (7)

官方文档FTS 简介FTS 的 IS 表FTS 的使用简介FTS 是倒排索引，对索引列上的文本分词并建立 词 -> 行 + 位置 的映射。词 -> 行 通过一个额外的隐藏列 FTS_DOC_ID 和 FTS_DOC_ID_INDEX索引完成。doc_id 是这一行的唯一标识，类似于自增唯一索引，并且在 FTS 文本更新时也会触发产生新的 doc_id。FTS 需要为每个建立 FTS 索引的表和每个 FTS 索引维护多张额外的表。这些表的维护穿插在常规建表/插入/删除等逻辑中。FTS 的数据可见性和提交逻辑与常规数据不同：即使在同一个事务内，FTS 索引的修改仅在提交后可见新增文本的 FTS 索引不随事务提交而落盘，只写入内存 cache，有额外的同步操作触发落盘删除文本的不删除 FTS 索引，仅记录删除的行（落盘），在 optimize 时触发真正的删除由于内存 cache 的机制，RW 上的修改在 RO 上不可见，PolarDB 新增日志类型同步 FTS cache 的修改，保证 RO 的一致性FTS 中一些重要结构和辅助表之间的关系代码建表建辅助表create_table_info_t::create_table /* Create the ancillary tables that are common to all FTS indexes on this table. ...继续阅读 (9)

作为一款先进的云原生数据库，PolarDB 通过存算分离架构突破传统数据库性能边界的同时，也不断地在索引高并发优化技术上深耕，推出了 PolarIndex 一系列索引优化特性：B-tree 细粒度并发控制、轻量化索引压缩、溢出页预分配等，相关技术参考这篇月报的介绍：再演进，更全面、更极致的 PolarIndex 2.0。本文聚焦 PolarDB 的 InnoDB 存储引擎核心数据结构 B-Tree，介绍我们在并发访问控制机制的技术演进路径。背景PolarDB 存储引擎的核心结构是 B-tree 索引组织数据，B-tree 的并发访问能力决定了系统的可扩展能力。对于索引结构并发访问的处理，可以将索引整体作为一个数据项，应用事务系统的并发控制机制，例如基于 2PL、时间戳、MVCC 等机制。但是由于索引访问频繁，将成为锁竞争的集中点，导致系统低并发度。考虑到索引不必像其它数据项那样处理，对于事务而言，对一个索引查找两次，并在期间发现索引结构发生了变化，这是完全可以接受的，只要索引查找返回正确的数据项。因此只要维护索引的准确性，对索引进行非可串行化的并发调度是可接受的。在 B-tree 索引的并发访问控制上，通常利用物理锁 latch 来实现互斥，在共享数据访问结束后就可以立即释放。这区别于事务系统的逻辑锁 lock，事务锁需要在事务提交时释放，通常会持续较长时间。在本文中以下术语是通用 ...继续阅读 (13)

背景MYSQL是全球最流行的数据库之一，开源易用的特点成为数据库初学者和开发者的选择。许多用户能够自行部署和管理本地 MySQL 服务，但随着业务发展不可避免会遇到了本地部署数据库的性能瓶颈，从而希望MySQL具有更高的性能、可用性和可扩展性，但是受到自有环境的物理限制难以达成。数据库的性能是直接影响用户体验的关键因素之一。数据库的持久化存储设备（如磁盘）的性能直接影响数据库性能。为了确保数据的持久性和完整性，数据库系统必须通过I/O操作将数据写入存储设备。只有当事务提交后的数据被成功写入磁盘后，才能保证在系统崩溃或断电等故障情况下数据不会丢失。在访问数据时，由于内存容量有限，数据库需要频繁地通过I/O操作从磁盘读取所需的数据。在遇到磁盘性能性能不足导致数据库性能下降时，通过升级性能更好的磁盘，将磁盘组成磁盘阵列等方法是调优的常见手段，不过磁盘的数量和性能受单机物理环境的限制。数据库的可用性同样是衡量用户体验的重要指标。通过将数据持久化到磁盘上，数据库能够在系统崩溃或服务器断电后重启，并从磁盘中恢复数据，从而重新提供服务。然而，在恢复期间，数据库将暂时不可用。如果磁盘发生故障导致无法访问，或者服务器故障无法重启，则可能导致数据永久丢失，使数据库彻底不可用。对于企业级数据库而言，高可用性和数据不丢失至关重要。为提升数据库的可用性，通常采用主备同步的机制，但通过网络传输数据会增加事务处 ...继续阅读 (10)

窗口函数Frame优化思想背景MySQL从8.0开始支持窗口函数（Window Functions），作用是计算一组聚合行的结果。其特点是可以同时具有分组和排序功能，且不改变原表行数，主要应用于数据分析场景。本文将介绍下窗口函数Frame子句的优化思想，首先看下窗口函数示例:SELECTSUM(c1)OVER(PARTITIONBYc2ORDERBYc3ROWSBETWEENxPRECEDINGANDyFOLLOWING)FROMt;如图所示，图示为窗口函数的语法逻辑。其中窗口函数分为特有的窗口函数与聚合函数两类，窗口函数子句包含分区子句，排序子句和框架子句Frame。具体地，展开上述窗口函数子句，如上述case，我们首先基于c2 分区，c3 排序，每一个分区中，计算每一行时，会根据当前行构造frame区间，如当前case会从当前行向前数x行，向后数y行，最后计算x+y+1行的sum(c1)值。默认场景下，每一行计算时，都需要先算出其Frame范围，并基于范围计算窗口函数值。一个分区遍历计算完，需要时间复杂度为O(N2). 考虑到当前行Frame与上一个的Frame关系，由此可以对Frame语句进行优化。优化思想由于窗口函数分为两类，其中一类为特有窗口函数，计算逻辑多与Frame无关，另一类为聚合函数，与Frame子句呈相关性，因此本文后续所述优化特指对聚合函数场景的Frame优化 ...继续阅读 (14)

索引模块是数据库管理系统的核心组件，其设计直接决定了数据库数据操作的性能与效率。如何构建高效高并发的索引结构，始终是数据库领域的研究重点。作为一款先进的云原生数据库，阿里云PolarDB也不断的在索引高并发优化技术上深耕。基于Latching coupling的设计理念，PolarDB实现了PolarIndex 1.0版本：将 SMO 操作分成两个阶段并引入Latching-coupling，消除InnoDB btree 索引结构变更（SMO）过程中的全局索引锁（Index Latch），并保证每次结构修改都只需在btree 的一层加锁, 从而减少了latch 粒度并，使得索引结构变更可以高度并发。PolarIndex 1.0的相关介绍可以参考PolarDB这一篇月报文章。这一技术极大的提升InnoDB Btree的写入能力，以TPCC单表测试场景为例，开启PolarIndex后峰值性能能有近3倍的提升。虽然PolarIndex 1.0版本消除了InnoDB btree SMO的全局Index latch使得SMO操作可以并发，但是仍有许多优化尚未触及的地方：1）PolarDB 在btree cursor下降过程使用 latch coupling 最多同时持有两层次 page latch，仍存在（parent）page锁的瓶颈；2）InnoDB BLOB、TEXT等可变长度列格式， ...继续阅读 (13)

InnoDB采用B+Tree来维护数据，处于非常核心的位置，可以说InnoDB中最重要的并发控制及故障恢复都是围绕着B+Tree来实现的。B+Tree本身是非常基础且成熟的数据结构，但在InnoDB这样一个成熟的工业产品里，面对的是复杂的用户场景，多样的需求，高性能高稳定的要求，以及长达几十年的代码积累，除此之外，InnoDB中的B+Tree在实现上并没有一个清晰的接口分层，这些都让这部分的代码显得复杂晦涩。本文希望从中剥茧抽丝，聚焦B+Tree本身的结构和访问来进行介绍，首先会简要介绍什么是B+Tree，之后介绍InnoDB中的B+Tree所处的位置和作用，然后介绍其数据组织方式，访问方式，以及并发控制。其余的，代码中交织在一起的诸如AHI (Adaptive Hash Index)、Change Buffer、RTree索引、Blob、代价估计等内容会先忽略掉。B+Tree对MySQL这种磁盘数据库来说，当要访问的数据不在内存中的时候，就需要从磁盘中进行加载。而内存和磁盘的访问速度是有几千甚至上万的差距的，那么作为磁盘数据库的索引，能不能有效的降低从磁盘中加载数据的次数就变得非常重要。1970年，Rudolf Bayer《Organization and Maintenance of Large Ordered Indices》一文中提出了BTree[1]，之后在这个基础上演化 ...继续阅读 (5)

在基于共享存储的 PolarDB 一写多读架构中，只读节点（RO）具备完整的 Binlog 获取能力，实现了计算节点的功能隔离，显著提升了读带宽的上限。因跨部门业务隔离、权限控制及性能考量，许多大型客户选择创建独立 RO 节点，并赋予大数据团队该节点的只读权限，用于通过 CDC（Change Data Capture）同步数据至分析系统。这一实践已成为客户接入 MySQL 生态下游的最佳路径，同类共享存储架构的 MySQL 数据库产品（如 Aurora）则不支持这个功能，而传统主从节点独立部署的 MySQL 从库不具备 binlog 位点的一致性，缺少计算节点间无缝切换和负载均衡的能力。早期版本中，PolarDB 仅主节点（RW）支持 Binlog Dump 功能，RO 节点因共享存储的分布式锁问题禁用 Binlog 操作。本文介绍如何在共享存储上设计 Binlog 多点读取能力，挑战在于协调共享文件的读写冲突。通信协议为了从 RO 上获取 Binlog，需要知道 Binlog 的基本信息，在 RO 上维护本地的 Binlog Index File。首次执行创建 IO 线程时，RO 会创建该文件；若 RO 升级为 RW 节点，该文件将被自动删除。当 Binlog Dump 请求到达 RO 时，系统首先通过本地 Index File 定位起始文件名，并从共享存储读取实际 Binlog ...继续阅读 (12)

什么是逻辑复制？一句话概括，逻辑复制是相对于物理复制的概念，物理复制是把对文件块的改动发送到下游，逻辑复制是把数据的改动（一般是修改前/修改后的行）发送到下游。逻辑复制架构逻辑复制的总架构，包含存量数据的复制、增量数据的复制。图中 1~3 表示存量数据的复制过程。在CREATE SUBSCRIPTION时，可以请求全量的数据。发布端接收和回复COPY数据。关键函数ApplyWorkerMain->start_table_sync->LogicalRepSyncTableStart->copy_table。图中 4~10 表示增量数据的复制过程。在订阅端结束1~3后，或者断开后重新建连，都会经历这样的步骤。发布端使用walsender进程发送逻辑复制的数据。关键函数ApplyWorkerMain->walrcv_startstreaming。Publication发布端创建，指定要发布什么给下游，目标是单个表或者一些表（指定shema下的表、所有表）。可以限制要发布什么行为：insert/update/delete/truncate，默认全部行为都发送。CREATE PUBLICATION name [ FOR ALL TABLES | FOR publication_object [, ... ] ] [ WITH ( publication_param ...继续阅读 (38)

背景在 MySQL 中，当我们访问一个表时，有两种主要的数据访问方式：全表扫描（Full Table Scan）和索引扫描。索引扫描又可以分为全索引扫描（Index Scan）和范围索引扫描（Range Scan）。一般而言，范围索引扫描的效率高于全索引扫描，而全索引扫描的效率又高于全表扫描。当查询的 WHERE 条件中包含索引列的范围条件时，我们可以利用这些条件进行范围扫描，从而减少扫描次数。然而，并不是所有索引列的范围条件都能有效地利用范围扫描，尤其是在复合索引的情况下。示例分析：我们创建了一个表，有6列数据（为a, b, c, d, e, f），其中前5列组成一个复合索引。Case 1: Full Table Scan对上述table进行如下查询：select a,b,c,d,e,f from ss limit 10;得到的EXPLAIN计划如下：这个例子中我们访问了所有列，因此Mysql优化器选择了Full Table Scan的方式进行查询。Case 2: Index Scan将查询换成如下形式：select a,b,c,d,e from ss limit 10;得到的EXPLAIN计划如下：由于我们没有扫描f列，直接扫描索引即可获得查询所需的全部数据。因此优化器选择了index scan，即全索引扫描。Case 3: Range Scan将查询继续换成如下形式：sele ...继续阅读 (10)

背景PolarDB MySQL在单个可用区部署时，采用分布式存储架构，数据具有三副本。这种设计确保了即使单个存储节点发生故障，系统的可用性和数据一致性也不会受到影响。与单可用区部署相比，双可用区部署在另一个可用区中额外部署了一套实例，并通过异步复制或半同步复制在可用区之间同步数据，从而提供了更高的容灾能力。然而，这种配置不能完全保证两个可用区之间的数据一致性。为了应对机房故障，保证多个可用区之间数据强一致，我们提出了新的PolarDB MySQL跨可用区强一致解决方案：三可用区部署模式。下面从架构，高可用，性能3个方面介绍一下三可用模式。架构首先来看一下整体的架构图与半同步和异步复制方式相比，采用一主一备一日志的三节点架构通过结合物理复制和X-Paxos协议来实现数据同步，提供了更可靠的数据一致性保障。在主节点上，写操作必须等待对应的Redo日志发送给备节点，并且达成多数派后才会客户端返回成功，从而确保数据的强一致性。主节点和备节点都存储完整数据和完整日志，而日志节点仅存储Redo日志。与双可用区部署相比，这种架构只是多了一个日志节点，存储成本增加很少。由于日志节点不包含数据，因此它不对外提供读写服务。MySQL官方也提供了一种强一致性的方案：MySQL Group Replication (MGR)。然而，MGR模式的一些缺点导致其在实际生产环境中的使用体验不尽如人意：Binlo ...继续阅读 (10)

前言查询变换是指基于等价规则，将一个查询语句改写成语义上等价的另一种形式。例如社区 PostgreSQL 中常用的“子查询上拉”、“外连接消除”、“表达式预处理”、“消除无用连接”、“谓词下推”等都是基于规则的查询变换，并且经过这些查询变换后的计划一定是更优的，因此 PostgreSQL 一定会尝试应用这些变换。但一些查询变换，如“子连接下推”、“OR 转 UNION ALL”等，应用后不一定使计划更优。为此，PolarDB PostgreSQL 版实现了基于代价的查询变换框架，能够基于执行代价选择是否做某种变换。对于复杂查询，CBQT 会收集该查询都可以在哪些 query block 做哪些基于代价的查询变换，这些变换会汇总成一个状态空间。CBQT 会按照指定的策略搜索状态空间，从中选择代价最低的状态。如下图所示，对于输入的 SQL 语句，CBQT 在 query block1 和 query block2 中收集到基于代价的查询变换 A 和 B，这两个变换组成的状态空间有：None（均不作变换）、[1，A]（query block1 做变换 A）、[1，B]（query block1 做变换 B）、[2，A]（query block2 做变换 A）。CBQT 会依次尝试应用状态空间的各种变换，在 linear 搜索策略中，状态[1，B]能使计划更优，因此在生成 Plan4 时， ...继续阅读 (13)

背景笔者在几年前整理过一篇文章，介绍了 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 ...继续阅读 (14)

概述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。这会带来如 ...继续阅读 (7)

概述慢 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 执行时间作为参考。这些功能由 ...继续阅读 (11)

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

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

这个是前年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 以上, 一 ...继续阅读 (12)

本文主要探讨我们在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 ...继续阅读 (17)

本文主要探讨我们在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 ...继续阅读 (16)

背景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）将会得到下面的执行计 ...继续阅读 (10)

背景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）将会得到下面的执行计 ...继续阅读 (13)

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 锁等待分析另一个在并发访问的场景，用户线程需 ...继续阅读 (14)

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

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 锁等待分析另一个在并发访问的场景，用户线程需 ...继续阅读 (17)

线上高频慢查在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信息： ...继续阅读 (18)

线上高频慢查在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信息： ...继续阅读 (17)

背景作者在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 ...继续阅读 (16)

背景作者在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 ...继续阅读 (14)

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