混用引擎的问题

在MySQL中，存储引擎是通过插件方式使用的，事务是由存储引擎自己实现，MySQL服务层是不管理事务的，所以在同一个事务中混用不同的存储引擎是不可靠的。

如果混用事务引擎和非事务引擎的话，事务如果正常提交的话，5.5不会有问题，但是5.6版本如果开了 GTID 的话就会报错，因为GTID模式下不允许事务中同时更新事务引擎和非事务引擎（Restrictions on Replication with GTIDs）； 如果事务回滚的话，不管是 5.5 还是 5.6 都会有问题的，因为对非事务引擎表的操作是无法回滚的，这样就会造成数据不一致，因为只有部分操作成功，并且结果不可预知，事务的原子性和一致性被破坏。

在之前的文章中我们知道RocksDB每一次写入，都是先写WAL，然后写Memtable,这次我们就来分析下MemTable的实现.

MemTable

MemTable是一个内存数据结构，它保存了落盘到SST文件前的数据。同时服务于读和写——新的写入总是将数据插入到memtable，读取在查询SST文件前总是要查询memtable，因为memtable里面的数据总是更新的。一旦一个memtable被写满，它会变成不可修改的，并被一个新的memtable替换。一个后台线程会把这个memtable的内容落盘到一个SST文件，然后这个memtable就可以被销毁了。并且在flush的过程中，会完成数据的压缩。

从MySQL 5.6.2/MariaDB 10.0.0版本开始，MySQL/MariaDB针对”ORDER BY …LIMIT n”语句实现了一种新的优化策略。当n足够小的时候，优化器会采用一个容积为n的优先队列来进行排序，而不是排序所有数据然后取出前n条。 这个新算法可以这么描述：（假设是ASC排序）

MySQL的update在执行时需要做read-modify-write：

1. 从底层存储中读取row数据(read row)
2. 对row数据做更改(modify row)
3. 把更改后的数据写回底层存储(write row)

TokuDB　7.5.0大版本已发布，是一个里程碑的版本，这里谈几点优化，以飨存储引擎爱好者们。

问题描述

首先，我们执行下面的TestCase：

1
2
3
4
5
6
7
8
9
10
11
12

--source include/master-slave.inc
--source include/have_binlog_format_row.inc
connection slave;
set global slave_rows_search_algorithms='TABLE_SCAN';
connection master;
create table t1(id int, name varchar(20);
insert into t1 values(1,'a');
insert into t2 values(2, 'b');
......
insert into t3 values(1000, 'xxx');
delete from t1;
---source include/rpl_end.inc

背景

Innodb使用undo log来实现MVCC，这意味着如果一个很老的事务长时间不提交，那么新产生的undo log都无法被及时清理掉。在MySQL 5.5及之前版本中，undo log是存储在ibdata中。从5.6开始可以使用独立的undo log表空间来存储undo。但是直到5.6，一旦undo log膨胀，依然没有任何办法为其 “减肥”。因此我们经常看到ibdata被膨胀到几十上百G。

背景

引入MDL锁的目的，最初是为了解决著名的bug#989，在MySQL 5.1及之前的版本，事务执行过程中并不维护涉及到的所有表的Metatdata 锁，极易出现复制中断，例如如下执行序列：

1

Session 1: BEGIN; Session 1: INSERT INTO t1 VALUES (1); Session 2: Drop table t1; ——–SQL写入BINLOG Session 1: COMMIT; —–事务写入BINLOG 在备库重放 binlog时，会先执行DROP TABLE，再INSERT数据，从而导致复制中断。

背景

MySQL的Master-Slave结构提供了实现High Availability的基础，在实现上面通常使用client-proxy-db的三层架构，proxy不单单完成错误检测、实例切换等高可用功能，还可以实现sharding，即scale out。

MySQL Fabric就是Oracle想大力发展的proxy，这里主要介绍为了完成高可用的功能，MySQL 5.7做了哪些事情，我们是否可以使用，实现自己的proxy？

背景

InnoDB作为事务性引擎，使用write-ahead logging(WAL)机制保证ACID中的Atomicity和Durability，使用undo机制保证ACID中的Consistency和Isolation。

按照WAL和undo的机制，形成以下两个原则：