这次还是以介绍TokuDB内部机制为主, 本篇来谈谈TokuDB内部的线程池模型。

TokuDB内部有一个线程池实现kibbutz， 代码: https://github.com/Tokutek/ft-index/blob/master/util/kibbutz.cc

其调度思想基于work-stealing， 代码也很简洁， 大体思路就是：维护一个任务队列， 空闲线程自己去这个队列领取任务。

kibbutz中文为“基布兹”,是以色列的一个集体社区，感兴趣的戳这里。

PG 9.4版本里面，增强了对json数据的支持，受到了很大关注。9.4之前，PG已经原生支持json数据类型了，但只是用字符串的形式存储和处理。这样做天然有性能上的缺点：每次对json字符串里面的数据进行查询，一般需要全表扫描加字符串匹配，效率很低。当然也可以在存储json的字符串字段上创建GIN索引，但需要对查询中用到的json的key或value创建单独索引，造成要被动维护很多索引。所以，这种json类型，只适用于把PG单纯作为数据存储，只读入读出数据，不对数据进行限定key或value查询的场景。

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

背景

MySQL 5.6 开始支持index_condition_pushdown特性，即server层把可以在index进行filter的谓词传递给引擎层完成过滤，然后结果返回到server。

在上期的月报中，我们已经详细介绍了Oracle MySQL以及社区分支最新的对InnoDB page flush的优化。在最近release的5.7.6版本中又有了进一步的改进。主要包括以下几点修改

背景

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

现象
mysql5.5,通过命令show variables like ‘\%pid_file\%’; 可以查到pid文件位置，例如/home/mysql/xx.pid。但发现在此目录下找不到此pid文件。

背景

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

背景

MySQL 执行查询语句， 对于order by谓词，可能会使用filesort或者temporary。比如explain一条语句的时候，会看到Extra字段中可能会出现，using filesort和using temporary。下面我们就来探讨下两个的区别和适用场景。

测试版本

MySQL5.6.23

测试表：

1
2

create table t1 (a int auto_increment primary key, b int, c int, unique key (b));并发执行SQL：
replace into t1(b,c) values (2,3)  //使用脚本，超过3个会话