赶在2014之前，写下2013最后一篇技术博客，介绍一下InnDB的并发控制模型
InnoDB中为什么需要并发控制？要回答这个问题，需要先聊聊context switch，当同时执行的进程/线程超过cpu核心数（超线程的数目）时，cpu以时间片轮转调度执行多个进程的时候就有context switch了，当进程A的时间片用完需要调度另外进程B时，需要将进程A的状态和参数保存在堆栈中，等再次调度到A时，再从堆栈中恢复状态和参数，这个切换的代价就是context switch，context switch的代价根据CPU性能及进程空间大小的不同，开销从几微秒（us）到几毫秒（ms）级别（参考：Quantifying The Cost of Context Switch，how-long-does-it-take-to-make-context），相对于一次内存读写操作（100ns左右），context switch代价不可小视（按照100us计算的话，相当于1000次内存访问）
[……]
好记性不如烂笔头，这篇文章是一个学习和总结，包括linux native aio API介绍以及InnoDB中如何使用native aio
linux上异步io有两套API，posix aio和native aio，其中native aio具有更好的性能，但要求文件打开方式必须是O_DIRECT，简单列下两套API的接口：
[table caption="posix aio" width="500" colwidth="80|420" colalign="left|left" border="1"]
function,desc
aio_read,发起一个异步读请求
aio_write,发起一个异步写请求
aio_return,阻塞等待异步io请求返回
aio_error,检查异步io返回结果
aio_suspend,挂起调用进程，直到一个或多个异步请求已经完成（或失败）
aio_cancel,取消异步io
lio_listio,发起一系列异步io请求
[/table][……]
DBA用脚本发送truncate操作清理MySQL表中数据，脚本执行一段时间使用ctrl+c想取消操作，却导致slave同步binlog后数据不一致，复制中断，之后通过select发现master表中数据依旧存在，但是truncate对应的binlog被记录记录，而slave中的表数据被清理，因为binlog复制过来后truncate操作执行成功
这个问题比较诡异，truncate实际上是失败，但是binlog记录下来，我们知道binlog记录一个完整事务，只有当事务成功执行完才会写binlog，只有问题能够重现才可能找到原因，遂测试truncate发送后马上ctrl+c取消，然而每次truncate都成功，表中数据被清理，binlog也记录下来，后来思考DBA当时使用的是脚本，发送的是多条truncat操作，这样的话可以让truncate执行过程中被打断的位置尽可能的多，这样复现问题的可能性也高一些，经过多轮尝试，终于重现了：[……]
