关系型数据库

背景 MySQL 企业版由 Oracle 公司维护，当然也是收费的。其产品类别也基本和 Oracle 数据库一致，包括标准版、企业版、集群版等。标准版包括基本的特性，价格也会比企业版便宜很多。今天和小编一起来看下 MySQL Enterprise Edition 提供的一些功能，这些功能的源码当然

前言 上一篇文章 提过，我们在之后的文章中会从 optimizer 的选项出发，系统的介绍 optimizer 的各个变量，包括变量的原理、作用以及源码实现等，然后再进一步的介绍优化器的工作过程（SQL 语句扁平化处理、索引选择、代价计算、多表连接顺序选择以及物理执行等内容），本期我们先看一下众所

背景 最近处理了几起线上实例表膨胀的问题。表膨胀是指表的数据和索引所占文件系统的空间，在有效数据量并未发生大的变化的情况下，不断增大。PG使用过程中需要特别关注这方面，我们来给大家解析一下表膨胀的原因。 表膨胀的直接触发因素是表上的大量更新，如全表的update操作、大量的insert+dele

前言 很久很久以前，内核君发表了一篇HA方案·TokuDB热备的文章，方法很简单： SET TOKUDB_CHECKPOINT_LOCK=ON; 开始拷贝TokuDB的数据文件(不包含日志文件)； FLUSH TABLES WITH READ LOCK; 记录binlog位置，拷贝最新的b

前言 PostgreSQL standby 可以通过两种方法来激活成为主库： trigger file，配置在recovery.conf中。 pg_ctl promote发送SIGUSR1信号给postmaster进程。 同时，PostgreSQL支持快速激活（fast promote）和非

前言 很多时候，RDS用户经常会问如何调优RDS MySQL的参数，为了回答这个问题，写一篇blog来进行解释： 哪一些参数不能修改，那一些参数可以修改； 这些提供修改的参数是不是已经是最佳设置，如何才能利用好这些参数； 哪些参数可以改 细心的用户在购买RDS的时候都会看到，不同规格能够提

背景 在日常的数据处理中，我们经常会有这样的需求：从一个文本中寻找某个字符串（比如某个单词）。 对这个需求，我们可以用类似这样的SQL完成：SELECT * FROM tbl WHERE text LIKE ‘%rds PostgreSQL%’;（找到含有“rds PostgreSQL”的文本）

前言 在前面几期关于 InnoDB Redo 和 Undo 实现的铺垫后，本节我们从上层的角度来阐述 InnoDB 的事务子系统是如何实现的，涉及的内容包括：InnoDB的事务相关模块、如何实现MVCC及ACID、如何进行事务的并发控制、事务系统如何进行管理等相关知识。本文的目的是让读者对事务系统

问题描述 bug 触发条件如下： 优化器先选择了 where 条件中字段的索引，该索引过滤性较好； SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化，最终因代价问题没有成功。 复现case 表结构 create table t

前言 4月份月报有篇文章《行锁(row-lock)与区间锁(range-lock)》，介绍了 TokuDB 的行锁/区间锁是如何使用的。这篇文章是其姐妹篇，介绍TokuDB行锁的实现，大家可以对照着看。 行锁申请 与 InnoDB 类似，TokuDB 也支持行级锁用来协调多个 txn 对数据库

问题描述 表结构如下所示: show create table test\G Table: test Create Table: CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

本文我们从一个索引选择的问题出发，来研究一下 MySQL 中 range 代价的计算过程，进而分析这种计算过程中存在的问题。 问题现象 第一种情况：situation_unique_key_id mysql> show create table cpa_order\G *********

本文我们从一个索引选择的问题出发，来研究一下 MySQL 中 range 代价的计算过程，进而分析这种计算过程中存在的问题。 问题现象 第一种情况：situation_unique_key_id mysql> show create table cpa_order\G ***********

外键约束异常现象 如下测例中，没有违反引用约束的插入失败。 create database `a-b`; use `a-b`; SET FOREIGN_KEY_CHECKS=0; create table t1(c1 int primary key, c2 int) engine=inno

PG默认每个page的大小为8K，PG数据页写入是以page为单位，但是在断电等情况下，操作系统往往不能保证单个page原子地写入磁盘，这样就极有可能导致部分数据块只写到4K(操作系统是一般以4K为单位)，这些“部分写”的页面包含新旧数据的混合。在崩溃后的恢复期间，xlog 里面存储的记录变化信息.

前言 在MySQL中，DDL是不属于事务范畴的，如果事务和DDL并行执行，操作相关联的表的话，会出现各种意想不到问题，如事务特性被破坏、binlog顺序错乱等，为了解决类似这些问题，MySQL在5.5.3引入了MDL锁(Metadata Locking)，关于其设计思路可以参考这两个worklog

背景 我们打开MySQL客户端，执行下面的SQL语句： drop table if exists t; create table t(id double)engine=innodb; insert into t values(1e-15),(1e-16); select * from t;

背景 我们打开MySQL客户端，执行下面的SQL语句： drop table if exists t; create table t(id double)engine=innodb; insert into t values(1e-15),(1e-16); select * from t;

binlog拉取存在的问题 MySQL 主备之间数据同步是通过binlog进行的，当主库更新产生binlog时，备库需要同步主库的数据，通过binlog协议从主库拉取binlog进行数据同步，以达到主备数据一致性的目的。但当主库tps较高时会产生大量的binlog，以致备库拉取主库产生的binlo

背景 之前的月报中我们比较了InnoDB linear read-ahead和Oracle的multiblock read，两个的性能有所差别，具体可以参考月报详情。 这两种方式之所以带来了更高的吞吐量，都基于数据存储的连续性的假设，比如MySQL使用自增字段作为pk的InnoDB索引表，或者是

背景 你是否曾为Error on rename of './test/#sql-78fd_780371' to './test/t2' (errno: 150)这样的错误而不解，如stackoverflow上的这个问题？ 下面我们来复现下： drop table t2; drop table