线上MySQL在大促时遇到并发压力大导致threads_running（并发执行query的线程数目）飙升，MySQL出现性能抖动问题甚至hang住，虽然在InnoDB层有innodb_thread_concurrency限制同时进入InnoDB存储层读写数据的线程数，但是这个参数不是一个硬限制（线程在锁等待结束后强制进入InnoDB层），而且代码路径比较靠后，作用有限，于尝试在server层限制并发数来解决这个问题，通过不断地优化和测试，开发完成了一个高水位限流/低水位优化的patch
这个patch是在之前thread running control的基础上优化的，将之前位于同一个函数中两个功能独立出来并将之前低水位限流实现从基于sleep-retry的机制优化成基于FIFO的cond-wait/signal机制
[……]
赶在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执行过程中被打断的位置尽可能的多，这样复现问题的可能性也高一些，经过多轮尝试，终于重现了：[……]
10月忙得像shi一样，不管怎样，忙里偷闲在这个月结束之前写上一篇，介绍InnoDB读写锁的实现
1. 读与读之间不冲突，读与写，写与写之间冲突，这个是读写锁最基本的特征
2. 申请写锁时，如果锁被读持有，将发生写锁等待，该写锁之后的所有读锁会等待该写锁成功获取后才能申请成功，这保证了公平：写锁请求不会被饿死
sync_array_struct: 保存用于线程同步结构的数组，数组成员类型为sync_cell_struct
sync_cell_struct: 一个线程同步结构体，部分代码：[……]
死锁检测一般采用Wait-For-Graph算法，这个不是非常复杂或者新奇的内容，cs课程中一般都会交代，本文从代码层面解析InnoDB锁系统及死锁检测实现，一方面给自己阅读代码做做笔记，另一方面希望也能够为一些有疑惑的朋友提供帮助
1. InnoDB中锁在是怎样表示和维护的
2. 死锁检测发生在什么时候
3. InnoDB中的Wait-For-Graph是如何实现的
4. InnoDB通常在哪些情况下可能发生死锁
[……]
MySQL可以作为一个embedded server执行，这时它就充当了一个与应用紧密耦合的轻量级数据中心，适合资源有限、应用需要连接很少（通常1个）的场景，使用方便，编译后就可以随应用一起启动，具有部署方便，速度更快的优点，当然它有很多限制，如：不支持UDF，不支持主备复制，InnoDB层不支持多个连接等，更多请参考 libmysqld, the Embedded MySQL Server Library.
因为DRC团队在使用embedded server的过程中遇到了执行prepared statment时内存泄露的问题，为了定位并fix问题，分析了这部分逻辑
[……]
线上遇到一起死锁问题，一条DELETE语句与一条UPDATE语句产生了死锁，经过和印风的讨论分析找到原因：DELETE语句通过二级索引删除记录，加锁顺序：二级索引（WHERE使用到二级索引）–>主键索引 –> 所有其它二级索引，UPDATE语句的加锁顺序：二级索引（WHERE条件使用二级索引）–>主键索引 –>包含更新字段的其它二级索引，由于DELETE操作更新了UPDATE语句WHERE条件使用到的索引，这导致DELETE与UPDATE加锁顺序相反，导致死锁
为了进一步研究InnoDB update操作加锁流程，进行了下列实验（update操作为inplace-update），关于mysql update的上层调用可以参考: MySQL update语法SQL解析源码分析 和 Oracle/PostgreSQL UPDATE…RETURNING…在MySQL中的实现
[……]
这个特性是twitter开发的，点击查看详情，目前已经backport到AliMySQL中，正在测试中，首先简单介绍一下功能
1）statement timemout特性中，SELECT必须是top-level，不能是子查询或者union中的除第一个SELECT之外的SELECT
2）语句级别：为SELECT增加一个hint: max_statement_time指定查询最大执行时间，当执行时间超过max_statement_time后，查询自动中断（连接不中断）
3）session级别：允许超级用户grant其它用户一个指定的max_statement_time，该用户连接后默认使用该值（用户可在session中临时修改），每个SELECT执行时间都不会超过max_statement_time
4）没有grant max_statement_time或grant max_statement_time 0的用户，除非在query中指定max_statement_time hint，否则查询执行时间不受限制
[……]
产品DBA在做日常SQL REVIEW时，遇到一个问题：一个包含子查询的query，使用order by(order by query)竟然比不使用order by(normal query)执行时间更短，而且是在order by无法使用index排序的情况下（使用filesort），这个问题不好解释，只能借助一些工具以及跟踪代码寻找原因
现象在Percona 5.5.18和Oracle MySQL 5.1.48上都存在，本文数据和分析基于Percona 5.5.18
[……]
