关系型数据库

前言 InnoDB并发过程中使用两类锁进行同步。 1. 事务锁 维护在不同的Isolation level下数据库的Atomicity和Consistency两大基本特性。 InnoDB定义了如下的lock mode: /* Basic lock modes */ enum lock_m

最近上线了一个O2O相关的应用，用到了PostgreSQL和非常著名的插件PostGIS，该应用把PostgreSQL和PostGIS的优势在O2O领域成功的发挥了出来。O2O业务分为线上和线下两部分，线下部分业务和位置距离等密切相关，不可避免的需要保存商户位置信息，进行距离的计算，范围覆盖计算等.

“时间线”（Timeline）是PG一个很有特色的概念，在备份恢复方面的文档里面时有出现。但针对这个概念的详细解释却很少，也让人不太好理解，我们在此仔细解析一下。 时间线的引入 为了理解引入时间线的背景，我们来分析一下，如果没有时间线，会有什么问题？先举个将数据库恢复到以前时间点的例子。假设在一

前言 在前面几期月报我们介绍了undo log、redo log以及InnoDB如何崩溃恢复来实现数据ACID的相关知识。本期我们介绍另外一种重要的数据变更日志，也就是InnoDB change buffer。 Change buffer的主要目的是将对二级索引的数据操作缓存下来，以此减少二级索引

背景 从 MairaDB 10.0.5 开始，MariaDB 开始提供 Role（角色）的功能，补全了大家一直吐槽的 MySQL 不能像 Oracle 一样支持角色定义的功能。 一个角色就是把一堆的权限捆绑在一起授权，这个功能对于有很多用户拥有相同权限的情况可以显著提高管理效率。在有角色之前，这

Listen 和 Notify 是PG很有意思的一个功能，可以用来进行多应用间的通信。它们可以在SQL中使用，也可以用C、JDBC里面的API调用。下面介绍一下其使用方法和内核实现。 使用方法 用一个简单的例子，来看一下Listen/Notify如何使用。假设我们有两个应用A和B，部署在不同的机

背景 6.5号，小编在 Aliyun 的论坛中发现一位开发者提的一个问题，说 RDS 发现了一个超级大BUG，吓的小编一身冷汗 = =!! 赶紧来看看，背景是一个RDS用户创建了一张表，在一个都是NULL值的非索引字段上进行了排序并分页，用户发现第二页和第一页的数据有重复，然后以为是NULL

背景 我们知道当一张表的某个字段存在重复值时，这个字段没办法直接加UNIQUE KEY，但是MySQL提供了一个 ALTER IGNORE TABLE的方式，可以忽略修改表结构过程中出现的错误，但是要忽略UNIQUE重复值，就需要打开old_alter_table，也就是拷贝表的方式来ALTER

唯一键是数据库设计中常用的索引类型，主要用于约束数据，不允许出现重复的键值记录。可以想象，如果唯一键约束失效了，将可能产生可怕的逻辑错误。本文主要讨论下最近MySQL爆出来的两个唯一键约束失效导致二级索引corruption的问题。 问题一： 检查重复键加锁逻辑不当 影响版本：MySQL 5.6

在前面两期月报中，我们详细介绍了 InnoDB redo log 和 undo log 的相关知识，本文将介绍 InnoDB 在崩溃恢复时的主要流程。 本文代码分析基于 MySQL 5.7.7-RC 版本，函数入口为 innobase_start_or_create_for_mysql，这是一个非

有4压缩很任性 TokuDB有着出色的压缩特性，这不是”盖”的： RDS上有个InnoDB实例，1天的数据将近700GB空间，换成TokuDB后(默认zlib压缩)，同样的700GB可以保存５天的数据，业务读写性能也无任何影响，空间成本直线下降。 为什么TokuDB的压缩这么给力？ 因为To

背景 最近有同事问，set names 时会同时设置了3个session变量 SET character_set_client = charset_name; SET character_set_results = charset_name; SET character_set_connec

背景 MySQL保存了两份元数据，一份在server层，保存在FRM文件中，另外一份在引擎层，比如InnoDB的数据字典中，这样也就造成了DDL语句经常导致元数据不一致的情况，下面介绍两个近期出现的因为DDL产生的bug。 rename 外键引用的column BUG复现过程 CREATE

背景 目前，IO 仍然是数据库的性能杀手，为了提高 IO 利用率和吞吐量，不同的数据库都设计了不同的方法，本文就介绍下 InnoDB 提供的预读(read-ahead)功能，以及 Oracle 提供的多块读(multiblock-read)功能，并进行一些对比。 InnoDB read-ahea

问题背景 我们在管理繁忙的 MySQL 数据库时，可能都有碰到 SYS CPU 高的经历：系统突然 SYS CPU 高起来，甚至比 USER CPU 高很多，这时系统 QPS、TPS 急剧下降。 SYS CPU高是什么造成的呢？主要有2种可能： 1. context switch 不高，但

问题重现 搭建一主一备，主备配置分别如下 ，同时设置备库的auto_position=0 $cat crash_recovery-slave.opt gtid_mode=on enforce_gtid_consistency=on log_slave_updates=on

bug描述 设置 foreign_key_checks=0 删除被引用的索引后，再设置foreign_key_checks=1，对引用表进行DML操作会导致 mysqld crash，以下是重现的测例： drop table if exists t2; drop table if exists

背景描述 之前我们遇到一个咨询，客户说： 1. 同一个表，col1=a，col2=b，做 update，set col1=col2，col2=col1，这时候两个都是b 2. 不同表，A表 col1=a，B表 col2=b，做 update，就能进行交换 为什么不同表就能交换呢？ 问题实验

bug背景 官方 5.7.6 版本对 gtid 有非常多的改进和bugfix，其中有一个 bugfix 是针对 relay log 中没有接收完整的 gtid 事务的。正常的relay log 中的 gtid 事务应该是像下面这样： 1. gtid event 2. query event (

背景 官方 5.6 最新版本 5.6.24 有这样一个bugfix，当使用 GTID 协议进行复制，并且备库的 slave_net_timeout 值设置太小的话，备库的 slave io 线程会卡住，同时主库上的 binlog dump 线程数一直在涨，官方的bug地址 。 bug分析 首先

我们看到在MySQL 5.7版本里大量遗留很多年的bug都被fix掉了，bug#12161就是其中一个，该bug在2005年第一次report到Bug list上，十年之后终于在MySQL 5.7.7 第一个RC版本被fix了。 Bug描述 当我们显式开启一个XA事务，执行操作，并完成XA PR

PgSQL 9.4.1在2015年2月5日发布，主打的是安全方面的更新，修补了如下的安全漏洞： CVE-2015-0241 Buffer overruns in “to_char” functions. CVE-2015-0242 Buffer overrun in replacement pr

简介 TokuDB使用LockTree(ft-index/locktree)来维护事务的锁状态(row-lock和range-lock)，LockTree的数据结构是一个Binary Tree。  本篇将通过几个“栗子”来谈谈TokuDB的row-lock和range-lock。  表t:

TokuDB简介 TokuDB是一个支持事务的“新”引擎，有着出色的数据压缩功能，由美国TokuTek公司(http://www.tokutek.com/) 研发，该公司于2015年4月份被Percona收购。 为了降低用户数据存储成本，云数据库(Aliyun RDS)增加了TokuDB引擎

本文是对整个Undo生命周期过程的阐述，代码分析基于当前最新的MySQL5.7版本。本文也可以作为了解整个Undo模块的代码导读。由于涉及到的模块众多，因此部分细节并未深入。 前言 Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生undo记录

PG 9.4版本里面，增强了对json数据的支持，受到了很大关注。9.4之前，PG已经原生支持json数据类型了，但只是用字符串的形式存储和处理。这样做天然有性能上的缺点：每次对json字符串里面的数据进行查询，一般需要全表扫描加字符串匹配，效率很低。当然也可以在存储json的字符串字段上创建GI.

Logical Decoding是9.4里面的一个主要功能，是向最终实现逻辑复制迈出的一大步。简言之，它的功能是从PG的WAL日志中，读取数据库更新信息，然后“翻译”（Decode）成逻辑的形式，可发送到远程从库做数据同步。这个功能还可以用于，DBA在数据库宕机，并发生主从切换后，检查原主库有哪些.

背景 在MySQL中，表是和操作系统中的文件对应的，而文件名在有的操作系统下是区分大小写的（比如linux），有的是不区分大小写（比如Windows），表名与文件名的大小写对应关系，MySQL 是通过 lower_case_table_names 这个变量来控制的。 这个变量的有效取值是0，1，

背景 MySQL的DDL没有被设计成事务操作，因此DDL操作是无法回滚的（像PgSQL把DDL也设计成事务操作，DDL就可以在执行成功后被回滚操作取消）。这就会导致如果某个DDL语句内部被拆分为多个原子的DDL调用，那么这个DDL语句就不具备中途执行失败后回滚整个DDL语句的能力，也就是说，即使语