背景

我们打开MySQL客户端，执行下面的SQL语句：

1
2
3
4

drop table if exists t;
create table t(id double)engine=innodb;
insert into t values(1e-15),(1e-16);
select * from t;

select * from t出来的内容如下，我们看到浮点数1e-15用正常的数值来表示，1e-16用科学技术法来表示。

1
2
3
4
5
6

+-------------------+
| id                |
+-------------------+
| 0.000000000000001 |
|             1e-16 |
+-------------------+

binlog拉取存在的问题

MySQL 主备之间数据同步是通过binlog进行的，当主库更新产生binlog时，备库需要同步主库的数据，通过binlog协议从主库拉取binlog进行数据同步，以达到主备数据一致性的目的。但当主库tps较高时会产生大量的binlog，以致备库拉取主库产生的binlog时占用较多的网络带宽，引起以下问题：

背景

你是否曾为Error on rename of './test/#sql-78fd_780371' to './test/t2' (errno: 150)这样的错误而不解，如stackoverflow上的这个问题？

NUMA 问题曾经一直是困扰DBA的一个大问题，早在 2010 年, 就有人给MySQL报了Bug#57241, 指出了MySQL在x86系统下存在严重的 “swap insanity” 问题。在NUMA架构越来越普遍的今天，这个问题越来越严重。

最近上线了一个O2O相关的应用，用到了PostgreSQL和非常著名的插件PostGIS，该应用把PostgreSQL和PostGIS的优势在O2O领域成功的发挥了出来。O2O业务分为线上和线下两部分，线下部分业务和位置距离等密切相关，不可避免的需要保存商户位置信息，进行距离的计算，范围覆盖计算等，这部分业务简称LBS（Location Based Service），即基于地理位置信息服务。使用PostgreSQL和PostGIS实现这些业务，具有天然的优势。

“时间线”（Timeline）是PG一个很有特色的概念，在备份恢复方面的文档里面时有出现。但针对这个概念的详细解释却很少，也让人不太好理解，我们在此仔细解析一下。

背景

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

前言

InnoDB并发过程中使用两类锁进行同步。

前言

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

在MySQL5.5之前的版本中，由于只支持缓存insert操作，所以最初叫做insert buffer，只是后来的版本中支持了更多的操作类型缓存，才改叫change buffer，这也是为什么代码中有大量的ibuf前缀开头的函数或变量。为了表达方面，本文也将change buffer缩写为ibuf。

由于历史上ibuf的数据格式曾发生过多次变化，本文讨论的相关内容基于如下设定： 版本为5.5及之后的版本，不涉及旧版本的逻辑，innodb_change_buffering 设置为ALL，表示缓存所有操作。

导读：TokuDB在“云端”的优势

为了降低用户数据存储成本，2015年４月份，云数据库(Aliyun RDS)增加了TokuDB引擎支持(MySQL5.6版本)，也是第一家支持TokuDB的RDS。