mysql锁、索引及事务杂谈

《mysql锁机制》
先附上大佬的一篇博客。这篇博客写得通俗易懂，墙裂推荐。

要看明白上面这篇博客，建议先去看下b+tree索引结构。

粗略概况mysql加锁影响因素就是：
①mysql版本
②引擎（innodb）
③事务隔离级别，注意mysql事务隔离级别和iOS隔离级别有区别
④索引
⑤sql语句写法

关于索引结构，为何不选复杂度更好的B-tree，而选用B+tree：

首先B-TREE的b是binary的意思，而B+TREE的B是balance的意思；
但是个人认为这两者其实没有本质区别，（当然这说法在面试的时候不能这么说，可能会被一些人嘲讽）为什么说他们差不多？
因为结构上其实大体相同，只是二叉树其实就是个扇出度为2的平衡树；mysql数据库的平衡树扇出度是多少不清楚。（扇出度就是指一个节点指向的下层节点之间的跨度）
扇出度的影响：扇出度越大，遍历效率越低，索引越小。
扇出度大小可能和磁盘页大小及索引条目大小相关
网上说二叉树和平衡树的复杂度都是logN，凭我的直觉目测是个很粗糙的说法！甚至是错误的。
比如说：一亿的数据，200Byte的索引宽度，磁盘页为4kb
假设一个磁盘页留25%的空隙，（留空余空间是为了防止，插入少量数据就导致磁盘页分裂）那就是一个磁盘页放15个索引条目（3kb）
B-TREE索引大小计算：
第一层：1
第二层：2
第三层：4
…
最后一层非叶子叶：5*10^7=五千万(约12.7GB)
它索引的总大小就是等比为2的等比数列求和乘以200byte，求和公式忘了。。。。
B+TREE索引大小计算（假定扇出度为40）：
和上面类似，只是等比为40，最后一层非叶子叶索引条目250万条（约635MB），非叶子叶总大小在700MB的样子。

经过上面精确的计算。。。。应该大致明白二叉树索引和平衡树索引非叶子叶大小的差距了。。。
索引尽量小，数据库就能尽可能的将非叶子叶缓存到内存，这样就减少了磁盘寻道次数，提高了查询效率。
所以选用B+TREE而不用B-TREE的原因其实就是牺牲一点遍历次数，减少磁盘寻道次数，提高总的查询效率！

事务：
①单个数据库事务
②分布式事务

数据库事务本质是基于MVCC和数据库锁实现的。
常见问题一：
业务代码到底是写controller层还是写service层？
这个问题其实就类似代码尽量写synchronized代码块中还是写同步代码块外。在尽可能保证事务的前提下，代码尽量写controller层。因为service往往会启用事务，如果耗时的操作放在service层，就会延长数据库事务时间，也就是说会增加数据库加锁时间！

问题二：
分布式事务保证强一致性为什么会导致效率很差？
这个问题其实和上面这个差不多。分布式事务要保证强一致性往往是利用数据库的XA事务，这种情况下分布式事务的总时间就是多个单个数据库事务的累加（忽略通信时间及其他时间），而单个事务的加锁时长就是分布式事务的时长；另外还有个原因，xa事务更容易导致死锁，所以保证强一致性会导致效率变差！根据cap理论，C：强一致性，A：可用性，P：分区容错性。尽量保证AP。如果非要保证CP，则建议尽量优化每个单体事务，尽量利用唯一索引、主键索引，使用X锁，避免GAP锁，表锁！

事务总是要么失败要么成功，无论单个事务还是分布式事务。
分布式事务根据CAP理论，无法同时保证三样，要么保证CP，要么保证AP.
一、保证CP则需要数据库本身支持XA事务，Java中引入atomikos等Jar包。
二、保证AP，则是利用接口幂等和单个事务来保证整个分布式事务的最终一致性。
其实很多业务都有分布式事务的东西在里面，但是如果每个业务都考虑得很细，会大大增加代码复杂性！

最后留个最近工作中碰到的一个问题：
select max（score） from a for update；
mysql数据库innodb引擎，默认事务隔离级别，score列有普通索引，这句sql会加什么锁？

当然我最后采用了另外一种方式，上面是我最开始想到的，后来发现有问题！
在service层，如果要保证数据库数据同步安全，在只利用数据库锁的情况下，建议尽可能利用一条记录的X锁来做。比如在入口处就给某条记录加X锁（当然要保证Java代码不出现指令重排），因为数据库的二相提交机制，这样就能保证整个事务在一个锁里面完成，否则在某些复杂业务中容易产生同步安全问题！