线上遇到一起死锁问题，一条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
[……]
MySQL的XA分为内部XA和外部XA，采用的协议是经典的2PC(2-Phase-Commit)
MySQL内部XA主要用于多个存储引擎之间的事务处理，由binlog作为Transaction Coordinator，事务提交过程中协调各个参与者（事务存储引擎）prepare，commit/rollback，各个事务存储引擎在prepare阶段基本做完了所有的事情（除了写commit标志，释放资源），对于InnoDB存储引擎，提交一个事务的流程如下：（图片来自登博）
[……]
