Clik here to view.
PostgreSQL LIKE 操作符走 B-tree 索引浅析
背景 LIKE 操作符是 PostgreSQL 支持的三种模式匹配方法之一。一般情况下，如果 SQL 中有模式匹配的过滤条件期望走索引，我们更推荐使用 GIN 或者 GIST 索引，同时配合创建一些插件，比如 pg_trgm，来达到更理想的效果。如果模式匹配字符串的模式以常量前缀开头，即满足前缀匹配，那么 B-tree 索引也可能被使用。能走 B-tree...
View ArticleClik here to view.
Clik here to view.
MySQL Index-Merge代价估算原理
线上高频慢查 在PolarDB-MySQL线上慢查问题中，经常遇到因选中Index-Merge索引反而导致查询更慢的情况，这种情况一般是没有太好的通用解决办法，一般是建议客户针对查询force index来固化某个索引，或者使用NO_INDEX_MERGE 的hint关闭index merge选项。 比如下面一个PolarDB客户的查询（已脱敏），优化器选择了Index...
View ArticleClik here to view.
通过 eBPF 进行跨线程的性能分析
1 背景 通过 前一篇文章 的介绍，我们很容易能够动态地得到某个函数的执行时延。当函数的开销只是线程内部的计算时，我们可以判断出造成函数时延较大的原因。 但当函数的开销依赖于其他线程时，如在一个信号量上等待其他线程唤醒，这时分析变得复杂起来。 举两个例子。 1.1 Redo 日志落盘分析 在 MySQL 中，用户线程在提交写事务时需要等待写入的 redo 日志先落盘，确保当发生 crash...
View ArticleClik here to view.
PostgreSQL LIKE 操作符走 B-tree 索引浅析
背景 LIKE 操作符是 PostgreSQL 支持的三种模式匹配方法之一。一般情况下，如果 SQL 中有模式匹配的过滤条件期望走索引，我们更推荐使用 GIN 或者 GIST 索引，同时配合创建一些插件，比如 pg_trgm，来达到更理想的效果。如果模式匹配字符串的模式以常量前缀开头，即满足前缀匹配，那么 B-tree 索引也可能被使用。能走 B-tree...
View ArticleClik here to view.
Clik here to view.
AWS re:Invent2024 Aurora 发布了啥 – DSQL 篇
这个是前年AWS re:Invent 2022 的内容, 有兴趣可以看这个链接: Aurora re:Invent 2022 这个是去年AWS re:Invent 2023 的内容, 有兴趣可以看这个链接: Aurora re:Invent 2023 AWS reInvent 2024 刚刚结束, 笔者作为数据库从业人员主要关注的是AWS Aurora 今年做了哪些改动, 今年最大的可能就是...
View ArticleClik here to view.
MySQL优化器代码速览
MySQL的优化器实现在代码结构上比较混乱，每个阶段的界限不是特别清晰，同时，代码耦合度高，对其进行拓展和修改都难度极大。因此，对MySQL的优化器代码有一个整体上的感知是非常重要的。...
View ArticleMySQL查询优化分析 - 常见慢查问题与优化方法
MySQL查询优化分析系列过往文章： 《MySQL查询优化分析 - MySQL优化执行的基础概念》 《MySQL查询优化分析 - 常用分析方法》...
View ArticleClik here to view.
PostgreSQL 慢 SQL 优化分享
概述 慢 SQL 是一个 DBA 无法绕过的问题，在云数据库快速崛起的时代背景下，也将成为云客户支持同学必须要面对的一个问题。因此本文将分享一些 PostgreSQL 慢 SQL 的优化思路，希望能够为读者在解决慢 SQL 问题时提供一些参考。文章先介绍了下背景，再提供了几种监控慢 SQL 的方法，然后再以具体的 case 为基础阐述了慢 SQL 产生的多种原因以及对应的解决方案。 背景 慢 SQL...
View ArticleWhat’s new in PolarDB8.4(一) prepare once
概述 PolarDB8.4是polardb8.0.2的下一个版本，对标的是社区mysql 8.4,目前正在紧锣密鼓的内测当中，不久就能通过polardb-mysql官网进行购买，是时候花点时间介绍一下PolarDB8.4内核层面的新特性了 。 对笔者而言最大的惊喜是另做了一个比较现代的hypergraph optimizer，之前我和其他同事有系统性阐述过hyper optimizer, 可以参考...
View ArticleClik here to view.
白话 MySQL Online DDL 2 · 从 INT 列转 BIGINT 锁表看 MySQL DDL 执行过程
背景 笔者在几年前整理过一篇文章，介绍了 MySQL 当前 DDL 的能力情况（白话Online DDL）。之前的文章重点介绍了 MySQL 5.6、5.7 到 8.0 的 DDL 能力对比并且解释了几个 DDL 常见的问题，并没有从代码层面分析 MySQL DDL 的执行过程。最近笔者遇到有个客户询问“MySQL 的 INT 列转为 BIGINT 会不会锁表？”笔者看了下之前的文档发现，MySQL...
View ArticleClik here to view.
MySQL查询优化分析-PolarDB MySQL的查询加速与优化
MySQL查询优化分析文章： MySQL查询优化分析 - MySQL优化执行的基础概念 MySQL查询优化分析 - 常用分析方法 MySQL查询优化分析 - 常见慢查问题与优化方法 前言...
View ArticlePolarDB PostgreSQL OR 子句转 UNION ALL
概述 本文介绍了 PolarDB PostgreSQL 支持的 “OR 子句转 UNION ALL” 的查询改写功能。 背景信息 目前， PostgreSQL 优化器对于 SQL 中的 OR 子句过滤条件并没有太多优化能力。假如 OR 子句过滤条件中只涉及到一张表，并且过滤条件上都有合适的索引，优化器会为这种场景生成一个 BitmapOr 的 index path。例如： explain...
View ArticleClik here to view.
What’s new in PolarDB8.4(二）完备的集合操作
前言 PolarDB8.4已经在内测阶段了，前文介绍了What’s new in PolarDB8.4(一) prepare once ,本文继续介绍一下PolarDB8.4另一新特性-完备的集合操作，包含union, intersect, except,...
View ArticlePlarDB MySQL · 功能特性 · EXPLAIN DDL
功能介绍 在MySQL生态中，DDL操作非常复杂，不仅耗时长、消耗硬件资源，而且涉及锁表操作，若操作不当可能会影响正常业务，甚至造成灾难性后果。此外，不同的DDL操作具有不同的执行特点，例如，添加字段不需要重建表，通常可以在秒级内完成，而修改字段类型则需要全表重建，并且在执行期间无法进行写操作。...
View ArticlePolarDB PostgreSQL计划固定(Statement Outline)
前言 在实际运行的数据库环境中，慢 SQL 问题经常困扰着运维团队和开发人员。慢 SQL 的原因多种多样，可能由数据分布不均、统计信息不准确等因素导致。 为了生成更优的执行计划，使用 Hint 来干预优化器行为是一种常见且有效的手段。 然而，直接让数据库管理员在业务 SQL 语句中加上 Hint 会面临诸多挑战： 中间件生成的 SQL：许多应用的 SQL 是通过中间件自动生成的，手动添加 Hint...
View ArticleClik here to view.
PolarDB-MYSQL 性能优化之路Cache篇
背景 DB为了提升不同场景下的性能，Cache的使用也非常普遍，PolarDB作为追求性能的数据库，Cache也是非常重要的组成部分。本文主要探讨我们在PolarDB MySQL产品中有哪些Cache，这些Cache又是如何提升数据库的性能的，帮助您匹配自己的场景合理使用Cache，最大化的提升性能。本文主要讲述几种Cache的作用和区别: Buffer Pool PolarStore EMP...
View ArticleClik here to view.
PolarDB对ordering index代价计算的改进
前言 ordering index选错是线上经常遇到的一种慢查。典型的例子是： 背景：time 与 id 有很强的关联 例一： select * from t where time > （CURDATE() - INTERVAL 7 DAY） order by id limit 2; 例二： select * from t where time > （CURDATE() -...
View ArticleClik here to view.
PolarDB PostgreSQL 基于代价的查询变换框架 (CBQT)
前言 查询变换是指基于等价规则，将一个查询语句改写成语义上等价的另一种形式。例如社区 PostgreSQL 中常用的“子查询上拉”、“外连接消除”、“表达式预处理”、“消除无用连接”、“谓词下推”等都是基于规则的查询变换，并且经过这些查询变换后的计划一定是更优的，因此 PostgreSQL 一定会尝试应用这些变换。 但一些查询变换，如“子连接下推”、“OR 转 UNION...
View Article