数据库-移动完成
一.mysql
学习mysql发现的一篇比较不错的博客：
抽空阅读一下，作为本篇笔记的完善，本篇笔记记录的mysql的知识点并不全
1.索引
（1）了解索引原理需要掌握的一些知识点
（i）索引为什么会增加速度
DB在执行一条Sql语句的时候，默认的方式是根据搜索条件进行全表扫描，
遇到匹配条件的就加入搜索结果集合。如果我们对某一字段增加索引，查询时
就会先去索引列表中一次定位到特定值的行数，大大减少遍历匹配的行数，所
以能明显增加查询的速度。
（ii）了解索引需要知道的一些细节
索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定
位到章，然后定位到该章下的一个小节，然后找到页数。相似的例子还有：查
字典，查火车车次，飞机航班等。本质都是：通过不断地缩小想要获取数据的
范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，
有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。数据库也是
一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、
between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方
式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段
查 询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二
段，201到300分成第三段......这样查第250条数据，只要找第三段就可以了，一
下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有
算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但
这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑
的。而数据库实现比较复杂，一方面数据是保存在磁盘上的，另外一方面为了提
高性能，每次又可以把部分数据读入内存来计算，因为我们知道访问磁盘的成本
大概是访问内存的十万倍左右，所以简单的搜索树难以满足复杂的应用场景。
（iii） 磁盘IO与预读
考虑到磁盘IO是非常高昂的操作，计算机操作系统做了一些优化，当一次IO时，
不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内，因
为局部预读性原理告诉我们，当计算机访问一个地址的数据的时候，与其相邻
的数据也会很快被访问到。每一次IO读取的数据我们称之为一页(page)。具体
一页有多大数据跟操作系统有关，一般为4k或8k，也就是我们读取一页内的数
据时候，实际上才发生了一次IO，这个理论对于索引的数据结构设计非常有帮
助。
（2）mysql索引
mysql索引数据结构有B+Tree和Hash索引两种，索引在mysql中也叫做键
（1）B+Tree
下面文章摘子如下两个博客
https://www.jianshu.com/p/8b653423c586（B-tree，读B树）
https://blog.csdn.net/qq_26222859/article/details/80631121(b+tree)
（a）B-Tree
B+Tree是B-tree的变种，先了解以下B-Tree。一颗m阶的B-Tree有如下特征：
-- 根结点至少有两个子女。
-- 每个中间节点都包含k-1个元素和k个孩子，其中 m/2 <= k <= m
-- 每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m
-- 所有的叶子结点都位于同一层。
-- 每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域分划。
例如一个3阶的B-Tree
这颗树中，我们来看(2,6)节点，该节点有两个元素(2,6)，又有三个元素(1,(3,5),8) ，其中
1小于元素2，(3,5)在元素(2,6)之间，2大于(8,5)。正好复合刚才所列的几个特征。
B-Tree主要用于文件索引和部分数据库索引，比如著名的非关系型数据库mongodb
（i）B-Tree的查询过程
单行查询：
假如我们要查询的数值是5
第一次磁盘IO：
在内存中定位（和9比较）：
在内存中定位（和2，6比较）：
第3次磁盘IO：
在内存中定位（和3，5比较）：
范围查询，查3到11的元素
自顶向下，查找到范围的下限（3）
中序遍历到元素6：
中序遍历到元素8：
中序遍历到元素9
中序遍历到元素11，遍历结束
（ii）B-Tree的插入操作
假如我们要插入的值是4
自顶向下查找4的节点位置，发现4应当插入到节点元素3，5之间。
节点3，5已经是两元素节点，无法再增加。父亲节点 2， 6 也是两元素节点，也无法
再增加。根节点9是单元素节点，可以升级为两元素节点。于是拆分节点3，5与节点2，
6，让根节点9升级为两元素节点4，9。节点6独立为根节点的第二个孩子。
（iii）B-Tree的删除过程
比如我们要删除元素11
自顶向下的查找元素11的位置
删除11后，节点12只有一个孩子，不符合B树规范。因此找出12,13,15三个节点的中位数13，取
代节点12，而节点12自身下移成为第一个孩子。（这个过程称为左旋）
（b）B+Tree
一个m阶的B+树具有如下几个特征：
-- 有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索
引，所有数据都保存在叶子节点。
-- 所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依
关键字的大小自小而大顺序链接。
-- 所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
B+Tree有如下特征：
-- 每一个父节点中的元素都出现在子节点中，是子节点中最大或最小的元素
-- 叶子节点包含全部的数据信息
-- 每一个叶子节点都包含指向下一个节点的指针，形成一个有序链表
-- 只有叶子节点带有卫星数据
（i）B+Tree的查询
-- 单行查询
单行查询时B+Tree会自顶向下逐层查询节点，最终找到匹配的叶子节点，比如我门要
查找的元素3。
第一次磁盘IO：
第二次磁盘IO：
第三次磁盘IO：
-- B+Tree的范围查找
查询3到11的元素
自顶向下查找到范围下限3
通过链表指针，遍历到元素6, 8：
过链表指针，遍历到元素9, 11，遍历结束：
扩展1：MongoDB为什么使用B-Tree而不是B+Tree（也就是说B-Tree的优势）
-- B-Tree读做B树
-- B+Tree更适合通过外部存储设备获取数据（整体IO次数少）；
B-Tree单次比较的成功率高。
想看详细看文章：https://blog.csdn.net/ahjxhy2010/article/details/80339510
扩展2：叶子节点存什么
首先要了解聚集索引和非聚集索引
下面这些内容来源于博客：https://blog.csdn.net/ufo___/article/details/80522453
mysql聚集索引
索引和数据放在同一个文件里面，聚集索引索引树的叶子节点直接存储数据（全部列的
数据），这就是聚集索引（聚合索引）。如果未定义主键，MySQL取第一个唯一 索引而且
只含非空列作为主键，InnoDB使用它作为聚簇索引。
聚集索引只有innoDB存储引擎支持，而且还仅限于其主键索引。
mysql非聚集索引
非聚集索引，也叫做二级索引，索引树的叶子节点是个索引节点，索引树的叶子节点
保存对应主键（MyISAM非聚集索引存的是数据的地址），并且包含了引用行的主键id值。
除去上面描述的聚集索引，剩下的都是非聚集索引（二级索引）
举例说明聚集索引和非聚集索引
假设table表 有主键id和name（name列已经建立了索引）：
对创建name列创建索引
create index idx_name on ti(name);
下面这张图就表现了在InnoDB聚集索引和非聚集索引是如何工作的：
可以看到在主键索引的叶子节点上直接存储了对应的数据，数据和索引在一起，聚合索
引。而且其他的索引树的叶子节点对应的是该行数据的主键id，如果以name进行查找，先在
name的索引树上找到对应的主键id，再通过得到的id进行查找。这样是为什么innoDB查询的
时候比MyISAM慢的原因之一，innoDB必须涉及到主键索引，既占用内存又直接多了一次主
键索引树的查找。
结论一：
主键索引（聚餐索引）查询效率比非主键索引查询效率更高。如果能使用主键查找的，
就尽量使用主键索引进行查找。
结论二：
主键定义的长度越小，二级索引的大小就越小，这样每个磁盘块存储的索引数据越多，
查询效率就越高。
这里顺便解释一个问题：为什么推荐用自增id作为主键？
第一：数字类型的比较速度更快。
自增的id，这个id一定是数字类型，相对于字符串而言，数字的比较速度快于
字符串（字符串需要一个字母一个字母进行比较），在B+树中，值的插入、查找、
删除都要进行比较，这样的话用数字作为主键比用字符串做为主键在比较速度上更
有优势。
第二：B树分裂更简单，可以更合理的利用磁盘空间，避免造成磁盘碎片。
自增的id对比乱序的UUID有什么优势呢，可以看到乱序的UUID在B+树中的插
入位置是非常随机的，而自增id每次都往B+树的最右边进行插入，这样B+树的分裂
操作更简单，而且底层分配空间是分配一段连续的空间，这样每次都像往数组的最
后插入数据，可以更合理的利用连续分配的空间，以免造成碎片过多。
第三：数字类型的索引更节约空间。
索引也是非常占用磁盘空间的，对字段小的列建索引更节约磁盘空间，比如
对数字型的列建索引就比字符串的列建索引更加节省磁盘空间。
下面这张图就表现了MyISAM在非聚集索引是如何工作的：
信息量非常大，我来一一说明：这个索引树是以建立索引的列的所有数据组织起
来的，可以看出索引十分消耗存储空间，而且叶子节点存储的是对应的那行数据的地
址，查找的时候先通过索引树找到对应数据的地址，再通过地址找到真正的数据。这
也就是为什么不把全部的索引一次性载入内存的原因，索引太大了。
扩展：MySql复合索引是如何组织树的
表：
下图显示其如何组织数据存储的
（iii）B+Tree的性质
下面的性质得出结论索引字段要尽量的小
先看一种简单说法：
每次IO读取一个磁盘块，一个磁盘磁盘块可以存多项数据，数
据越大，磁盘块存的数据项越小，所以树的高度越高。
在看网络上的说法，比较难懂
通过上面的分析，我们知道IO次数取决于b+树的高度h，假设
当前数据表的数据为N，每个磁盘块的数据项的数量是m，则
有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；
m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个
数据页的大小，是固定的，如果数据项占的空间越小，数据项
的数量越多，树的高度越低。这就是为什么每个数据项，即索
引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。
这也是为什么b+树要求把真实的数据放到叶子节点而不是内
层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，
导致树增高。当数据项等于1时将会退化成线性表。
扩展，块是什么鬼（本节参考文章：
https://www.i3geek.com/archives/1275
还有簇的概念，有空在看）
块、扇区的一些概念
扇区
首先搞清楚扇区一些单位大小关系
一个磁盘按层次分为磁盘组合 -> 单个磁盘 -> 某一盘面
-> 某一磁道 -> 某一扇区
现在在说扇区是什么
每个磁盘有多条同心圆似的磁道，磁道被分割成多个部
分。每部分的弧长加上到圆心的两个半径，恰好形成一
个扇形，这就是扇区。扇区是磁盘中最小的物理存储单
位。通常情况下每个扇区的大小是512字节。（由于不
断提高磁盘的大小，部分厂商设定每个扇区的大小是
4096字节）
磁盘块
磁盘块属于逻辑层面，是操作系统虚拟出来的， 块是操作系
统中最小的逻辑存储单位。操作系统与磁盘打交道的最小单
位是磁盘块，磁盘的读写基本单位是块。
扇区和磁盘块的关系以及为什么要有磁盘块
由于扇区的数量比较小，数目众多在寻址时比较困难，所以
操作系统就将相邻的扇区组合在一起，形成一个块，再对块
进行整体的操作。扇区和磁盘块的关系，通过射磁盘块来映
射。磁盘块和扇区大小的基本关系：
一个块大小=一个扇区大小*2的n次方（这个值只是个例子，
并不是固定的，由操作系统自己决定）
复合索引为什么要满足最左匹配原则
联合索引的内部结构，从本质上来说，联合索引也是一棵B+树，不同的是联合索引的键值的数量不是l，而是大于等于
2。其结构如图5-22
从图5．22可以观察到多个键值的B+树情况。其实和之前讨论的单个键值的B+树并没有什么不同，键值都是排序的，通
过叶子节点可以逻辑上顺序地读出所有数据，就上面的例子来说，即（1,1)、（1,2）、（2,1)、（2,4）、（3,1)、（3,2）。
数据按(a,b)的顺序进行了存放。
因此，对于查询SELECT * FROM TABLE WHERE a=xxx and b=xxx，显然是可以使用(a，b）这个联合索引的（因为索
引是通过排序确认查找方向）。对于单个的a列查询SELECT * FROM TABLE WHERE a=xxx，也可以使用这个(a，b）索引。
但对于b列的查询SELECT* FROM TABLE WHERE b=xxx，则不可以使用这棵B+树索引。可以发现叶子节点上的b值为1、2、
1、4、1、2，显然不是排序的，因此对于b列的查询使用不到(a,b)的索引。
为了加深理解，在啰嗦一段，当复合索引是(name,age,sex)的时候，b+树是按照从左到右的顺序来建立搜索树的，比如
当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和
sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索
树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检
索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性
别是F的数据了，这个是非常重要的性质，即索引的最左匹配特性。
学习最左匹配原则的时候复习一下这幅个表格
复合索引的第二个好处是已经对第二个键值进行了排序处理。例如，在很多情况下应用程序都需要查询某个用户的购物情
况，并按照时间进行排序，最后取出最近三次的购买记录，这时使用联合索引可以避免多一次的排序操作，因为索引本身在叶
子节点已经排序了。
| 语句 | 索引是否发挥作用 |
| where a=3 | 是 |
| where a=3 and b=5 | 是 |
| where a=3 and b=5 and c=4 | 是 |
| select * from mytable where c=4 and b=6 and a=3; |
本来按理说是不可以的，但是网上说mysql会进行优化，所以和上一句一样，用到了索引 |
| where b=3 | 否 |
| where c=4 | 否 |
| where a=3 and c=4 | a列能用到索引,c不能 |
| where a=3 and b>10 and c=7 | a能,b能,c不能，这个的地方b用的是范围查询，也算断点，不过自身能用到索引 |
| where a>4 and b=7 and c=9 | a能、b不能、c不能，理由同上 |
| select * from mytable where a=3 order by b; | a用到了索引，b在结果排序中也用到了索引的效果 |
| select * from mytable where a=3 order by c; | a用到了索引，但是这个地方c没有发挥排序效果，因为中间断点了 |
| where a=3 and b like 'xxx%' and c=7 | a能,b能,c不能 |
（iv）覆盖索引（索引覆盖，重点，全看）
我们知道MySQL的B+Tree索引是用我们字段的数据来建立索引的，比
如说我们的主键id字段，就是用所有的id来组织这颗索引树，如果我们再对
name字段建立索引的话，这个二级索引就是用name字段的数据来组织这
颗索引树。那么问题就来了，我们知道对于二级索引而言他的叶子节点存
储了对应数据行的id，也就是说最后我们的查询还是要通过主键id来进行
查询获取数据。如果我们只需要name这个字段呢？比如说
select name from table where name>'aaa'; 我们这个二级索引上保存了的
name字段的所有数据，那么就没有必要再通过id去访问数据行了，直接从
索引上获取数据即可。称之为覆盖索引，有的也翻译为索引覆盖。
我们可以通过expalin来判断查询是否覆盖索引，主要看extra字段是
否有using index 。
比如说：我们有以下表：
对name字段建立索引：
执行sql 【explain select name from tb where name>'w'】;
可以看到我们使用上了索引idx_name，而且extra字段也出现了using index，
说明我们这次查询是覆盖索引的。
把sql稍微修改一下：【explain select id,name from tb where name>'w'】;
可以看到这次查询还是覆盖索引，因为我们二级索引树的叶子节点就保存了
对应数据行的id，所以对于二级索引而言，查询的时候加不加id都不影响是
否是覆盖索引，id也在二级索引树上。
我们再把sql修改一下：【explain select name,age from tb where name>'w'】;
我们对name字段建立的索引上并没有保存age这个字段的数据，也就无法从
索引上来获取数据了，只能访问数据表了。extra字段也没有出现
using index（MySQL查询优化器会在执行查询前判断是否有一个索引能够
进行覆盖。如果索引覆盖了where条件中的字段，但不是整个查询的字段，
则会使用回表方式读取数据 ） 。那么我们的业务需求就是经常的查询name
和age字段咋办呢？
为了再次提高效率我们可以对name和age字段建立复合索引。
例如：
我们再次执行【explain select name,age from tb where name>'w'】
发现我们的新索引并没有使用上，因为我们MySQL优化器认为不值得调用
这个复合索引，因为索引也占空间，在当前就10条数据量，表就三个字段
（id，name，age）的情况下，他认为多一次主键查询比从复合索引上获
取数据的效果更好，而且也使用上了对name字段建立的单值索引。
我们把索引idx_name删掉，在次执行：
【explain select name,age from tb where name>'w'】
这个时候MySQL乖乖用上了我们建立的复合索引，而且extra字段也出现
了using index 。在一个系统应用当中除非特别情况，否则我们也一般也
是建立复合索引。
注：能够使用索引覆盖的情形
-- 查询二级索引中的字段+主键字段。因为二级索引的叶子节点包含了主键的值
-- 查询语句的所有字段都包括在一个复合索引里面，且与字段顺序无关，比如我
有一个复合索引
idx_payment_date（paymnet_date,amount,last_update）
则SQL语句
select amount,last_update,payment_date from payment
select amount,payment_date from payment
都将进行索引覆盖查询
而SQL语句
select customer_id,payment_date from payment
将不使用覆盖索引，因为customer_id字段不在那个索引里面
在举一个列子，延时关联
原Sql：
SELECT store_ids,film_id FROM sakila.inventory where actor='SEAN CARREY'
and title like '%APOLLO%'
对(actor, title, prod_id)，建立索引，然后按如下方式进行查询
EXPLAIN SELECT *
FROM products
join (
SELECT prod_id
from products
WHERE actor='SEAN CARREY'
and title like '%APOLLO%'
) tl ON (T1.prod_id-products.prod_id )
我们把这种方式叫做延迟关联(deferredjoin),因为延迟了对列的访
问。在查询的第一阶段MySQL可以使用覆盖索引，在FROM子句
的子查询中找到匹配的prod_id，然后根据这些prod_id值在外层
查询匹配获取需要的所有列值。虽然无法使用索引覆盖整个查询，
但总算比完全无法利用索引覆盖的好。
（v）mysql锁会通过索引锁定
-- 行锁有时候会锁大于返回记录的行
InnoDB只有在访问行的时候才会对其加锁，而索引能够减
少 InnoDB访问的行数，从而减少锁的数量。但这只有当
InnoDB在存储引擎层能够过滤掉所有不需要的行时才有效。如
果索引无法过滤掉无效的行，那么在InnoDB检索到数据并返回
给服务器层以后，MySQL服务器才能应用WHERE子句。这时
已经无法避免锁定行了：InnoDB已经锁住了这 些行，到适当的
时候才释放。在MySQL5.1和更新的版本中，InnoDB可以在服
务器端过滤掉行后就释放锁，但是在早期的MySQL版本中，
InnoDB只有在事务提交后才能释放锁。
这个查询仅仅会返回2~4之间的行，但是实际上获取了1~4之
间的行的排他锁。InnoDB会锁住第1行，这是因为MySQL为该查
询选择的执行计划是索引范围扫描：
换句话说，底层存储引擎的操作是“从索引的开头开始获取
满足条件actor_id < 5的记录“，服务器并没有告诉InnoDB可以
过滤第1行的WHERE条件。注意到EXPLAIN的Extra列出现了
”Using where“，这表示 MySQL服务器将存储引擎返回行以后
再应用WHERE过滤条件。下面的第2个查询就能证明第1行确
实已经被锁定了，尽管第1个查询的结果中并没有这个第1行。
保持第1个连接打开，然后开启第2个连接并执行如下查询：
就像这个例子显示的，即使使用了索引，InnoDB也可能锁
定一些不需要的数据。如果不能使用索引查找和锁定行的话问题
可能会更糟糕，MySQL会做全表扫描并锁住所有的行，而不管
是不是需要。关于InnoDB、索引和锁有一些很少有人知道的细
节：
InnoDB在二级索引上使用共享（读）锁，但访问主键索引
需要排他（写）锁。这消除了使用覆盖索引的可能性，并且使
得SELECT FOR UPDATE比LOCK IN SHAREMODE或非锁定
查询要慢得多。
-- 因为锁索引引起的死锁
案例一：
tab_test 结构如下：
id：主键;
state：状态;
time：时间;
索引：idx_1(state，time)
出现死锁的2条sql语句：
update tab_test set state=1064,time=now() where
state=1061
and time < date_sub(now(), INTERVAL 30 minute);
update tab_test set state=1067,time=now ()
where id in (9921180)
原因分析：
当“update tab_test set state=1064,time=now() where
state=1061 and time < date_sub(now(), INTERVAL 30 minute)”
执行时，MySQL会使用idx_1索引，因此首先锁定相关
的索引记录，因为idx_1是非主键索引，为执行该语句，
MySQL还会锁定主键索引。假设
“update tab_test set state=1067,time=now () where
id in (9921180)”几乎同时执行时，本语句首先锁定主键
索引，由于需要更新state的值，所以还需要锁定idx_1
的某些索引记录。这样第一条语句锁定了idx_1的记录，
等待主键索引，而第二条语句则锁定了主键索引记录，
而等待idx_1的记录，这样死锁就产生了。在第一条语
句给主键加锁前，第二条语句已经给主键加了锁，所以
在高并发的数据操作时，死锁的情况就容易产生InnoDB
会自动检测一个事务的死锁并回滚一个或多个事务来防
止死锁。Innodb会选择代价比较小的事务回滚，此次
事务（1）解锁并回滚，语句（2）继续运行直至事务结
束。
解决方案：
拆分第一条sql，先查出符合条件的主键值，再按照
主键更新记录：
select id from tab_test where state=1061 and time <
date_sub(now(), INTERVAL 30 minute);
update tab_test state=1064,time=now() where id in(......);
其它死锁情况参见：https://www.cnblogs.com/phpfans/p/4649883.html
（2）Hash索引
简单地说，哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检
索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法
即可立刻定位到相应的位置，速度非常快。
Hash索引的示意图如下：
（a）Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，
不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多
次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。但是当
Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索
引高。对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存
在大量记录指针信息存于同一个 Hash值相关联。这样要定位某一条记
录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。
（c）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。
由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能
用于等值的过滤，不能用于基于范围的过滤，因为经过相应的Hash算
法处理之后的Hash 值的大小关系，并不能保证和Hash运算前完全一
样。
（d）Hash 索引无法被用来避免数据的文件排序操作。
由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash
值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无
法利用索引的数据来避免任何排序运算；
（e）Hash 索引不能利用组合索引部分索引键查询。
对于组合索引，Hash 索引在计算Hash 值的时候是组合索引键合并后再
一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前
面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
（f）有大量键重复，hash碰撞频繁，效率也不高
（3）B+Tree索引和Hash索引比较
（a）如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次
算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如
果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后
扫描，直到找到相应的数据。
（b）从示意图中也能看到，如果是范围查询检索，这时候哈希索引就毫无用
武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连
续的了，就没办法再利用索引完成范围查询检索；
（c）同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部
分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
（d）哈希索引也不支持多列联合索引的最左匹配规则；
（e）B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有
大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈
希碰撞问题。
2.mysql索引的分类
（1）普通索引（normal）
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
（a）直接创建索引
CREATE INDEX index_name ON table(column(length))
（b）修改表结构的方式添加索引
ALTER TABLE table_name ADD INDEX index_name ON (column(length))
（c）创建表的时候同时创建索引
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER NOT NULL ,
`content` text CHARACTER NULL ,
`time` int(10) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
INDEX index_name (title(length))
)
（d）删除索引
DROP INDEX index_name ON table
（2）唯一索引（unique）
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有
空值。如果是组合索引，则列值的组合必须唯一。
（a）创建唯一索引
CREATE UNIQUE INDEX indexName ON table(column(length))
（b）修改表结构
ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))
（c）创建表的时候直接指定
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER NOT NULL ,
`content` text CHARACTER NULL ,
`time` int(10) NULL DEFAULT NULL ,
UNIQUE indexName (title(length))
);
（3）主键索引
是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是
在建表的时候同时创建主键索引：
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) NOT NULL ,
PRIMARY KEY (`id`)
);
（4）组合索引
指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个
字段，索引才会被使用。使用组合索引时遵循最左前缀集合。
ALTER TABLE `table` ADD INDEX name_city_age (name,city,age);
组合索引的生效规则：
多列索引发挥作用，需要满足左前缀要求。
以index(a,b,c)为例：
| 语句 | 索引是否发挥作用 |
| where a=3 | 是 |
| where a=3 and b=5 | 是 |
| where a=3 and b=5 and c=4 | 是 |
| where b=3 | 否 |
| where c=4 | 否 |
| where a=3 and c=4 | a列能用到索引,c不能 |
| where a=3 and b>10 and c=7 | a能,b能,c不能 |
| where a=3 and b like 'xxx%' and c=7 | a能,b能,c不能 |
注意：对复合索引的非最左前缀字段进行 OR 运算，是无法使用到复合索
引的。
比如：
SELECT * FROM tbl_name WHERE (key_col1 > 10 OR key_col2 = 20) AND nonkey_col=30;
其中key_col1和key_col2建立复合索引，但是却无法使用到索引（
因为key_col2不是最左前缀，key_col2是否生效不知道，有环境测
试一下）。
其原因是，MySQL中的索引，使用的是B+tree, 也就是说他是：
先按照复合索引的 第一个字段的大小来排序，插入到 B+tree
中的，当第一个字段值相同时，在按照第二个字段的值比较来
插入的。那么如果我们需要对：OR key_col2 = 20 这样的条件
也使用复合索引，那么该怎么操作呢？应该要对复合索引进行
全扫描，找出所有 key_col2 =20 的项，然后还要回表去判断
nonkey_col=30，显然代价太大了。所以一般而言
OR key_col2 = 20 这样的条件是无法使用到复合索引的。如果
一定要使用索引，那么可以在 col2 上单独建立一个索引。
（5）全文搜索索引（full textl）
从3.23.23版开始支持全文索引和全文检索，FULLTEXT 用于搜索很长一
篇文章的时候，效果最好。主要用来查找文本中的关键字，而不是直接与
索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索
引擎，而不是简单的where语句的参数匹配。fulltext索引配合
match against操作使用，而不是一般的where语句加like。它可以在
create table，alter table ，create index使用，不过目前只有char、varchar，
text 列上可以创建全文索引。值得一提的是，在数据量较大时候，现将数
据放入一个没有全局索引的表中，然后再用CREATE index创建fulltext索
引，要比先为一张表建立fulltext然后再将数据写入的速度快很多。
（a）创建表的适合添加全文索引
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER NOT NULL ,
`content` text CHARACTER NULL ,
`time` int(10) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
FULLTEXT (content)
);
（b）修改表结构添加全文索引
ALTER TABLE article ADD FULLTEXT index_content(content)
（c）直接创建索引
CREATE FULLTEXT INDEX index_content ON article(content)
3.索引优化，避免索引失效
（1）哪些列上适合建索引
（a）索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引
（b）在经常需要搜索的列上，可以加快搜索的速度；
（c）主键和外键
（d）在经常用于连接两张表的列上
（e）在经常使用在WHERE子句中的列上面创建索引
（f）在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其
指定的范围是连续的；
（g）在经常需要排序（order by）的列上创建索引，因为索引已经排序，
这样查询可以利用索引的排序，加快排序查询时间；
（h）数据量超过300的表应该有索引
（i）更新频繁的字段不适合创建索引，不会出现在 where 子句中的字段不
应该创建索引
（2）避免索引失效和写出高性能sql总结
（a）应尽量避免在 where 子句中对字段进行 null 值判断
（b）应尽量避免在 where 子句中使用!=或<>操作符
（c）应尽量避免在 where 子句中使用 or 来连接条件
（d）in 和 not in 也要慎用，否则可能会导致全表扫描（in字段少的时候会走索引，
所以不是in的就一定不走索引）
（e）下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
但是如果是这样： select id from t where name like 'abc%'
索引是可以生效的
（f）如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在
运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到
运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计
划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面
语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
（g）应尽量避免在 where 子句中对字段进行运算、表达式、函数这将导
致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
（h）应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃
使用索引而进行全表扫描
（i）隐式转换导致索引失效，例如表的字段tu_mdn定义为varchar2(20)，
但在查询时把该字段作为number类型以where条件传给Oracle，这样
会导致索引失效。
错误的例子：select * from test where tu_mdn=13333333333;
正确的例子：select * from test where tu_mdn='13333333333';
（j）并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化
的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如
一表中有字段sex，male、female几乎各一半，那么即使在sex上建
了索引也对查询效率起不了作用。
关于性别字段不适合建索引原因：
因为你访问索引需要付出额外的IO开销，你从索引中拿到的只
是地址，要想真正访问到数据还是要对表进行一次IO。假如你要从表
的100万行数据中取几个数据，
那么利用索引迅速定位，访问索引的这IO开销就非常值了。但如果你
是从100万行数
据中取50万行数据，就比如性别字段，那你相对需要访问50万次索引，
再访问50万次表，加起来的开销并不会比直接对表进行一次完整扫描
小。
（k）很多时候用 exists 代替 in 是一个好的选择
例子：
select a.id, a.workflowid,a.operator,a.stepid from dbo.[[zping.com]]] a inner join workflowbase b on a.workflowid=b.id and operator='4028814111ad9dc10111afc134f10041' 替换为 select a.id,a.workflowid,a.operator ,a.stepid from dbo.[[zping.com]]] a where exists (select 'X' from workflowbase b where a.workflowid=b.id) and operator='4028814111ad9dc10111afc134f10041'
（l）用exists替换DISTINCT
适用于类似这种情况：当提交一个包含一对多表信息(比如部门表和雇
员表)的查询时，避免在SELECT子句中使用DISTINCT。一般可以考
虑用EXIST替换，EXISTS使查询更为迅速。
4.mysql语句的执行过程
此节内容摘自文章：https://www.cnblogs.com/yyjie/p/7788428.html
（1）SQL语句的执行顺序
(8) SELECT (9) DISTINCT (11) <TOP_specification> <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}（avg,sum，mysql、oracle貌似没有，先不用关注）
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
即：from->on->join->where->group by->with->having->select->order by
以上每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输
入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最
后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句，将
跳过相应的步骤。
由此可间，join的效率要好于where，网上查mysql是这样，但是有点
不敢轻信，有空自己测试一下
对写sql的一个现象解释：
group by开始才可以使用select中的别名，他返回的是一个游标，而
不是一个虚拟表，所以在where中不可以使用select中的别名，而
having却可以使用。
sql处理的详细介绍：
（a）FROM：对FROM子句中的前两个表执行笛卡尔积(交叉联接)，生成
虚拟表VT1。表名执行顺序是从后往前，所以数据较少的表
尽量放后。
（b）ON：对VT1应用ON筛选器，只有那些使为真才被插入到TV2。
（c）JOIN（OUTER）：如果指定了OUTER JOIN(Left Outer join、
Right Outer join)，保留表中未找到匹配的行将作
为外部行添加到VT2，生成TV3；如果是InnerJoin，
则不添加行，直接生成TV3；如果FROM子句包含
两个以上的表，则对上一个联接生成的结果表和下
一个表重复执行步骤1到步骤3，直到处理完所有的
表位置。
（d） WHERE：对TV3应用WHERE筛选器，只有使为true的行才插入TV4。
执行顺序为从前往后或者说从左到右。
（e）GROUP BY：按GROUP BY子句中的列列表对TV4中的行进行分组，
生成TV5。执行顺序从左往右分组。
（f） CUTE|ROLLUP：把超组插入VT5，生成VT6。
（g）HAVING：对VT6应用HAVING筛选器，只有使为true的组插入到VT7。
Having语句很耗资源，尽量少用。
（h）SELECT：处理SELECT列表，产生VT8。
（i）DISTINCT：将重复的行从VT8中删除，产品VT9。
（j）ORDER BY：将VT9中的行按ORDER BY子句中的列列表顺序，生成一
个游标(VC10)。执行顺序从左到右，是一个很耗资源的语
句。
（h）TOP：从VC10的开始处选择指定数量或比例的行，生成表TV11，并返
回给调用者。
例子：
select 考生姓名, max(总成绩) as max总成绩 from tb_Grade where 考生姓名 is not null group by 考生姓名 having max(总成绩) > 600 order by max总成绩
在上面的示例中 SQL 语句的执行顺序如下：
（a）首先执行 FROM 子句, 从 tb_Grade 表组装数据源的数据
（b） 执行 WHERE 子句, 筛选 tb_Grade 表中所有数据不为 NULL 的数据
（c）执行 GROUP BY 子句, 把 tb_Grade 表按 "学生姓名" 列进行分组(注：
这一步开始才可以使用select中的别名，他返回的是一个游标，而不
是一个表，所以在where中不可以使用select中的别名，而having却可
以使用)
（d） 计算 max() 聚集函数, 按 "总成绩" 求出总成绩中最大的一些数值
（e） 执行 HAVING 子句, 筛选课程的总成绩大于 600 分的.
（f） 执行 ORDER BY 子句, 把最后的结果按 "Max 成绩" 进行排序.
（g）mysql和sql执行顺序基本是一样的, 标准顺序的 SQL 语句为：
（2）Mysql语句的执行顺序
Mysql语句的执行顺序和sql语句的执行顺序基本相同。
5.Mysql的执行计划
什么是执行计划：
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方
案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果
用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查
找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优
化器就会改变方案，采用“全表扫描”方式。同属的说：“模拟Mysql优化
器是如何执行SQL查询语句的，从而知道Mysql是如何处理你的SQL语
句的、分析你的查询语句或是表结构的性能瓶颈”。可见，执行计划并不
是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要。
执行计划需要注意的事项：
* 统一SQL语句的写法
执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的
SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞
在内存里。可想而知，数据库的效率会何等低下。
例如，对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为
是不同的：
select*from dual
select*From dual
其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两
次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任
何地方都一致，多一个空格都不行。
* 不要把SQL语句写得太复杂
我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么
长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句
去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者
都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，
这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化
器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东
西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
* OLTP系统SQL语句必须采用绑定变量
select*from orderheader where changetime >'2010-10-20 00:00:01'
select*from orderheader where changetime >'2010-09-22 00:00:01'
以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。如果采用
绑定变量：
select*from orderheader where changetime >@chgtime
@chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，
这可以大大降低数据库解析SQL语句的负担。一次解析，多次重用，是提高数
据库效率的原则。
绑定变量的注意事项：
事物都存在两面性，绑定变量对大多数OLTP处理是适用的，但是也有例
外。比如在where条件中的字段是“倾斜字段”的时候。“倾斜字段”指该列中的绝
大多数的值都是相同的，比如一张人口调查表，其中“民族”这列，90%以上都
是汉族。那么如果一个SQL语句要查询30岁的汉族人口有多少，那“民族”这列
必然要被放在where条件中。这个时候如果采用绑定变量@nation会存在很大
问题。试想如果@nation传入的第一个值是“汉族”，那整个执行计划必然会选
择表扫描。然后，第二个值传入的是“布依族”，按理说“布依族”占的比例可能只
有万分之一，应该采用索引查找。但是，由于重用了第一次解析的“汉族”的那
个执行计划，那么第二次也将采用表扫描方式。这个问题就是著名的“绑定变量
窥测”，建议对于“倾斜字段”不要采用绑定变量。
注：这里不同性别字段，性别字段不适合建立索引，是因为它大约要取一半的
数据，而民族字段却不同，它有时候取大多数数据，有时候取少量数据，
所以它可以加索引
本节参考文章：
https://blog.csdn.net/wuseyukui/article/details/71512793
https://blog.csdn.net/zhuxineli/article/details/14455029
https://www.cnblogs.com/magialmoon/archive/2013/11/23/3439042.html#Extra
https://www.cnblogs.com/man1s/p/10267669.html
https://segmentfault.com/q/1010000014908005/a-1020000014913547
（1）id：id是一组数字，表示查询中执行select子句或操作表的顺序，如果id相同，则执行顺序
从上至下，如果是子查询，id的序号会递增，id越大则优先级越高，越先会被执行。
分三种情况：
（i）id相同：执行顺序由上至下
select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序。
（ii）id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行，自
己推测，有子查询先执行子查询。
（iii）id相同又不同（两种情况同时存在）：id如果相同，可以认为是一组，从上往下顺
序执行；在所有组中，id值越大，优先级越高，越先执行
关于derived的说明：
详见select_type中的union
（2）select_type
查询的类型，主要是用于区分普通查询、联合查询、子查询等复杂的查询。
（i）SIMPLE：简单的select查询，查询中不包含子查询或者union
（ii）PRIMARY：查询中包含任何复杂的子部分，最外层查询则被标记为primary
（iii）SUBQUERY：在select 或 where列表中包含了子查询
（iv）DERIVED：在from列表中包含的子查询被标记为derived（衍生），mysql
或递归执行这些子查询，把结果放在临时表里
（v）UNION：若第二个select出现在union之后，则被标记为union；若union包含
在from子句的子查询中，外层select将被标记为derived。
<derived N>就表示这个是临时表，后边的N就是执行计划中的id，
表示临时表的结果来自于这个查询产生。如果是尖括号括起来的
<union M,N>，与<derived N>类似，也是一个临时表，表示这个临时表
的结果来自于union查询的id为M和N的结果集。
（vi）UNION RESULT：从union表获取结果的select（通俗的说就是union的结果，
自己猜测，就是如果是select * from (select1 union selet2)
那么就有个序号（id），如果是select1 union select2 由于
最外层没有select，所以就是NULL，没有id。具体什么样
子，有机会装了mysql执行计划在测试）
（3）type
访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >
unique_subquery > index_subquery > range > index > ALL
一般来说，好的sql查询至少达到range级别，最好能达到ref
system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出
现，可以忽略不计。
const：使用唯一索引或者主键，返回记录一定是1行记录的等值where条件时，
通常type是const。其他数据库也叫做唯一索引扫描
eq_ref：唯一性索引扫描（主键或唯一索引），对于每个索引键，表中只有一条
记录与之匹配。常见于主键或唯一索引扫描。
注，与const的区别：
eq_ref是表示的是表和表关联的一行，而const是单表中的一行且通常条
件是个常数。
注意：ALL全表扫描的表记录最少的表如t1表
ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质是也是一种索引访
问，它返回所有匹配某个单独值的行，因此他可能会找到多个符合条件的行，
所以它应该属于查找和扫描的混合体
fulltext：全文索引检索，要注意，全文索引的优先级很高，若全文索引和普通索引
同时存在时，mysql不管代价，优先选择使用全文索引。
ref_or_null ：这种连接类型类似 ref，不同的是增加了对null值的查询。这种连接
类型的优化是从mysql4.1.1开始的，它经常用于子查询。在以下的
例子中，mysql使用ref_or_null 类型来处理ref_table：
select * from ref_table where key_column=expr or key_column is null
index merge： 此节内容内容参考文章：
https://www.cnblogs.com/digdeep/archive/2015/11/18/4975977.html
中文称为“索引合并”。表示查询使用了两个以上的索引，最后取
交集或者并集，常见and ，or的条件使用了不同的索引，官方排
序这个在ref_or_null之后，但是实际上由于要读取所个索引，性
能可能大部分时间都不如range。其执行过程简单的说，其实就
是：对多个索引分别进行条件扫描，然后将它们各自的结果进行
合并。从MySQL5.1开始支持，合并的算法有：intersect，union，
sort_union（交集和并集的各种组合）。
注：索引合并(Index Merge)不适应与全文索引(full-text indexes)
对index merge优化之MySQL 5.6.7：
MySQL在5.6.7之前，使用index merge有一个重要的前提条件：
没有range可以使用。这个限制降低了 MySQL index merge 可
以使用的场景。理想状态是同时评估成本后然后做出选择。如
下例子：
SELECT * FROM t1 WHERE (goodkey1 < 10 OR goodkey2 < 20) AND badkey < 30;
对于这个查询，有两种处理方案：
第一种，索引合并使用条件(goodkey1 < 10 OR goodkey2 < 20)
第二种，范围扫描(range scan)使用条件 badkey < 30优化器可
以选择使用goodkey1和goodkey2做index merge，也
可以使用badkey做range。
因为上面的原则，无论goodkey1和 goodkey2的选择度如何，
MySQL都只会考虑range，而不会使用index merge的访问方式。
5.6.7版本针对此有修复。
索引合并开关配置：
索引合并(Index Merge)的使用取决于optimizer_switch系统变
量的index_merge，index_merge_intersection，
index_merge_union和index_merge_sort_union标志的值。默
认情况下，所有这些标志都打开。 要仅启用特定算法，请将
index_merge设置为关闭，并仅启用其他应允许的其他算法。
* intersect：索引合并Intersection访问算法对所有使用的索引执行同
时扫描，将其结果进行交集运算，即AND。例子如下：
结果进行交集运算，即AND。例子如下：
--例一：条件使用到复合索引中的所有字段或者左前缀字段(对单字段索引也适用) key_part1=const1 AND key_part2=const2 ... AND key_partN=constN
--例二：主键上的任何范围条件 SELECT * FROM innodb_table WHERE primary_key < 10 AND key_col1=20; SELECT * FROM tbl_name WHERE (key1_part1=1 AND key1_part2=2) AND key2=2;
上面只说到复合索引，但是其实单字段索引显然也是一
样的。比如：
select * from tab where key1=xx and key2 =xxx; 也是
有可能进行index intersect merge的。另外上面两种情
况的AND组合也一样可能会进行index intersect merge。
如果查询中使用的所有列都被使用的索引覆盖，则
不会检索完整的表行（EXPLAIN输出包含在这种情况下
在Extra字段中 Using index）。索引合并Intersection访
问算法对所有使用的索引执行同时扫描，并产生从合并
索引扫描中接收到的行序列的交集。如果使用的索引不
包括查询中使用的所有列，则只有满足所有使用的键的
范围条件时才检索完整的行。如果其中一个合并条件是
InnoDB表的主键条件，则不用于行检索，而是用于过
滤使用其他条件检索的行。
* union：简单而言，index uion merge就是多个索引条件扫描，对
得到的结果进行并集运算，即OR运算。下面几种类型的
where 条件，以及他们的组合
可能会使用到 index union merge算法：
第一，条件使用到复合索引中的所有字段或者左前缀字段
（对单字段索引也适用）
第二，主键上的任何范围条件
第三，任何符合 index intersect merge 的where条件
SELECT * FROM t1 WHERE key1=1 OR key2=2 OR key3=3; SELECT * FROM innodb_table WHERE (key1=1 AND key2=2) OR (key3='foo' AND key4='bar') AND key5=5;
解说：第一个例子，就是三个 单字段索引 进行 OR 运算，
所以他们可能会使用 index union merge算法。
第二个例子，复杂一点。(key1=1 AND key2=2) 是
符合index intersect merge;
(key3='foo' AND key4='bar') AND key5=5 也是符合
index intersect merge，所以 二者之间进行 OR 运算，
自然可能会使用 index union merge算法。
* sort_union：多个条件扫描进行 OR 运算，但是不符合
index union merge算法的，此时可能会使用
sort_union算法。官方给出如下两个例子：
SELECT * FROM tbl_name WHERE key_col1 < 10 OR key_col2 < 20; SELECT * FROM tbl_name WHERE (key_col1 > 10 OR key_col2 = 20) AND nonkey_col=30;
索引合并Sort-Union访问算法和索引合并Union访问
算法的区别在于，索引合并Sort-Union访问算法必须
首先为所有行提取行ID，然后在返回任何行之前对其
进行排序（表示没看懂）。
对 index merge 的进一步优化（表示不是很理解，复合索引不就
是intersect吗？有空搞明白）：
index merge使得我们可以使用到多个索引同时进行扫描，然
后将结果进行合并。听起来好像是很好的功能，但是如果出现
了 index intersect merge，那么一般同时也意味着我们的索引
建立得不太合理，因为 index intersect merge 是可以通过建立
复合索引进行更一步优化的。
index merge的局限：
如果我们的条件比较复杂，用到多个 and / or 条件运算，而
MySQL没有使用最优的执行计划，那么可以使用如下的两个
等式将条件进行转换一下：
(x AND y) OR z = (x OR z) AND (y OR z)
(x OR y) AND z = (x AND z) OR (y AND z)
unique_subquery：该类型替换了下面形式的IN子查询的ref：
value IN (SELECT primary_key FROM single_table
WHERE some_expr)
unique_subquery是一个索引查找函数,可以完全替换子查询，
效率更高。
index_subquery：该联接类型类似于unique_subquery。可以替换IN子查询,但只适
合下列形式的子查询中的非唯一索引（子查询可能返回重复值）：
value IN (SELECT key_column FROM single_table WHERE
some_expr)
range： 索引的范围查询。只检索给定范围的行，使用一个索引来选择行。key
列显示使用了那个索引。一般就是在where语句中出现了bettween、
<、>、in等的查询。这种索引列上的范围扫描比全索引扫描要好。只
需要开始于某个点，结束于另一个点，不用扫描全部索引。
index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常为
ALL块，因为索引文件通常比数据文件小。（Index与ALL虽然都是读全
表，但index是从索引中读取，而ALL是从硬盘读取，出现这个如果能优
化也尽量优化，但是如下例，确实是无法优化）
ALL：Full Table Scan，遍历全表以找到匹配的行
（4）possible_keys
查询可能使用到的索引都会在这里列出来
（5）key
查询真正使用到的索引，如果没有索引被选择，键是NULL；查询
中如果使用了覆盖索引，则该索引仅出现在key列表中；如果
select_type为index_merge时，这里可能出现两个以上的索引，其
他的select_type这里只会出现一个。想要让mysql强行使用或者忽
略在 possible_keys字段中的索引列表，可以在查询语句中使用关
键字force index, use index,或 ignore index。如果是myisam 和 bdb
类型表，可以使用 analyzetable 来帮助分析使用使用哪个索引更好。
如果是 myisam类型表，运行命令 myisamchk --analyze也是一样的
效果。详细的可以查看章节"14.5.2.1 analyze tablesyntax"和
"5.7.2 tablemaintenance and crash recovery"（这里没细究，详
情请百度搜索标黑的章节）。
（6）key_len
表示索引中使用的字节数，查询中使用的索引的长度（最大可能长
度），并非实际使用长度，理论上长度越短越好。key_len是根据
表定义计算而得的，不是通过表内检索出的。当key字段的值为
null时，索引就是null。
（7）ref
显示索引的哪一列被使用了，即“哪些字段或者常量被用来和key
配合从表中查询记录出来“。
如果是使用的常数等值查询，这里会显示const，如果是连
接查询，被驱动表的执行计划这里会显示驱动表的关联字段，
如果是条件使用了表达式或者函数，或者条件列发生了内部隐
式转换，这里可能显示为func
补充，什么是驱动表？
通俗的讲就是先从哪个表开始检索，找到好的驱动表语句
的优化就成功一半了。例如：
select * from a,b where a.id = b.id and a.姓名 = '美格瑞恩'
and b.性别 = '女';在a,b表同等数量级的情况下显然用a表做
为驱动表比较好因为姓名相对于性别来说可以过滤掉更多
的数据，所以想办法使你的执行计划扫描a表先再通过
nest loop与b表关连比较理想。
驱动表的定义：
wwh999 在 2006年总结说，当进行多表连接查询时， 驱动表的
定义为：
* 指定了联接条件时，满足查询条件的记录行数少的表为“驱动表”。
* 未指定联接条件时，行数少的表为“驱动表”。
（8）rows
根据表统计信息及索引选用情况，大致估算出找到所需的记录
所需要读取的行数。
（9）Extra
本字段显示了查询中mysql的附加信息
关于Extra的一些例子参看如下博客：
https://www.cnblogs.com/wy123/p/7366486.html
Extra的中只有出现Using filesort， Using temporary才需要优化
* Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
* Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准
的行，就不再搜索了
* Range checked for each
Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一个行组合，
MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用
索引的最慢的连接之一
* Using filesort（需要回表查询）
mysql对数据使用一个外部的索引排序，而不是按照表内的索引
进行排序读取。也就是说mysql无法利用索引完成的排序操作称
为“文件排序”。看到这个的时候，查询就需要优化了。
由于索引是先按email排序、再按address排序，所以查询时如果
直接按address排序，索引就不能满足要求了，mysql内部必须再
实现一次“文件排序”。
MySql中的排序：
MySql中有两种排序，一种是“索引排序”，一种是“文件排
序”，索引排序效率比较高，所以排序字段需要建立索引。
MySql中ORDER BY、GROUP BY都会用到排序，
ORDER BY 一定要建立索引；GROUP BY是否建立索引尚
有争议，有的地方说“需要建立”，有的地方说“视情况而定”，
有空在研究一下。关于MySql的排序，
详见：
https://www.cnblogs.com/cchust/p/5304594.html。
该篇文章因为时间关系我没有看
Group By不加索引的理由：
https://blog.csdn.net/epee/article/details/83169669
* Using temporary
看到这个的时候，查询需要优化了。表示 MySQL 在对查询结果
排序时使用临时表。常见于排序 order by 和分组查询 group by上（这只是
一个比较典型的例子，并不是只有order by和group by才会出现）。
例一：
例二：
EXPLAIN SELECT ads.id FROM ads, city WHERE city.city_id = 8005 AND ads.status = 'online' AND city.ads_id=ads.id ORDER BY ads.id desc
id select_type table type possible_keys key key_len ref rows filtered Extra
------ -------------- ------- ------- -------------------- ------ -------- -------------------------------
1 SIMPLE city ref ads_id,city_id city_id 4 const 2838 100.00 Using temporary; Using filesort
1 SIMPLE ads eq_ref PRIMARY PRIMARY 4 city.ads_id 1 100.00 Using where
这条语句会使用using temporary,而下面这条语句则不会
EXPLAIN SELECT ads.id FROM ads, city WHERE city.city_id = 8005 AND ads.status = 'online' AND city.ads_id=ads.id ORDER BYcity.ads_id desc
id select_type table type possible_keys key key_len ref rows filtered Extra
------ ----------- ------ ------ -------------- ------- ------- -------------------- ------ -------- ---------------------------
1 SIMPLE city ref ads_id,city_id city_id 4 const 2838 100.00 Using where; Using filesort
1 SIMPLE ads eq_ref PRIMARY PRIMARY 4 city.ads_id 1 100.00 Using where这是为什么呢？他俩之间只是一个order by不同，MySQL 表关联的算法是
Nest Loop Join，是通过驱动表的结果集作为循环基础数据，然后一条一条
地通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结
果。EXPLAIN 结果中，第一行出现的表就是驱动表（Important!）以上两个
查询语句，驱动表都是 city，如上面的执行计划所示！对驱动表可以直接排
序，对非驱动表（的字段排序）需要对循环查询的合并结果（临时表）进行
排序因此，order by ads.id desc 时，就要先 using temporary 了！
* Using where（需要回表查询）
Extra列出现Using where表示MySQL服务器将存储引擎
返回服务层以后再应用WHERE条件过滤。
* Using index（不需要回表查询）
表示相应的select操作中使用了覆盖索引（Covering Index），
避免了访问表的数据行，效率高如果同时出现Using where，表
明索引被用来执行索引键值的查找（参考 Using temporary中的
图）如果没用同时出现Using where，表明索引用来读取数据而
非执行查找动作
* Using index condition
这是MySQL 5.6出来的新特性，叫做“索引条件推送”。简单说一
点就是MySQL原来在索引上是不能执行如like这样的操作的，但
是现在可以了，这样减少了不必要的IO操作，但是只能用在二级
索引上，详情点这里。
SQL优化的例子：
例一，根据Type和Extra优化SQL
创建一张表：
CREATE TABLE IF NOT EXISTS `article` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT, `author_id` int(10) unsigned NOT NULL, `category_id` int(10) unsigned NOT NULL, `views` int(10) unsigned NOT NULL, `comments` int(10) unsigned NOT NULL, `title` varbinary(255) NOT NULL, `content` text NOT NULL, PRIMARY KEY (`id`) );
插几条数据：
CREATE TABLE IF NOT EXISTS `class` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `card` int(10) unsigned NOT NULL, PRIMARY KEY (`id`) ); CREATE TABLE IF NOT EXISTS `book` ( `bookid` int(10) unsigned NOT NULL AUTO_INCREMENT, `card` int(10) unsigned NOT NULL, PRIMARY KEY (`bookid`) ); CREATE TABLE IF NOT EXISTS `phone` ( `phoneid` int(10) unsigned NOT NULL AUTO_INCREMENT, `card` int(10) unsigned NOT NULL, PRIMARY KEY (`phoneid`) ) engine = innodb;
然后再分别插入大量数据。插入数据的php脚本：
explain select * from class left join book on class.card = book.card\G
执行结果：
*************************** 1. row *************************** id: 1 select_type: SIMPLE table: class type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20000 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: book type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20000 Extra: 2 rows in set (0.00 sec)
显然第二个 ALL 是需要我们进行优化的。
建立索引：
ALTER TABLE `book` ADD INDEX y ( `card`);
*************************** 1. row *************************** id: 1 select_type: SIMPLE table: class type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20000 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: book type: ref possible_keys: y key: y key_len: 4 ref: test.class.card rows: 1000 Extra: 2 rows in set (0.00 sec)
可以看到第二行的 type 变为了 ref,rows 也变成了
1741*18，优化比较明显。
Left Join的反向测试，左表建立索引，右表不建：
删除原索引：
DROP INDEX y ON book;
建立新索引：
explain select * from class right join book on class.card = book.card;
执行结果：
建立新索引：
ALTER TABLE `book` ADD INDEX y ( `card`);
执行如下代码：
explain select * from class inner join book on class.card = book.card;
执行结果如下：
*************************** 1. row *************************** id: 1 select_type: SIMPLE table: book type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20000 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: class type: ref possible_keys: x key: x key_len: 4 ref: test.book.card rows: 1000 Extra: 2 rows in set (0.00 sec)
执行结果：
*************************** 1. row *************************** id: 1 select_type: SIMPLE table: class type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20000 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: book type: ref possible_keys: y key: y key_len: 4 ref: test.class.card rows: 1000 Extra: *************************** 3. row *************************** id: 1 select_type: SIMPLE table: phone type: ref possible_keys: z key: z key_len: 4 ref: test.book.card rows: 260 Extra: Using index 3 rows in set (0.00 sec)
后 2 行的 type 都是 ref 且总 rows 优化很好，效果不错。
4.MyISAM和InnoDB的区别
参考文章：https://blog.csdn.net/UFO___/article/details/80519309
可见，MyISAM主要用作查询，MyISAM和InnoDB的区别总结如下：
（1）MyISAM不支持事务，而InnoDB支持
（2）InnoDB支持数据行锁定，MyISAM不支持行锁定，只支持锁定整个表
（3）InnoDB支持外键，MyISAM不支持
（4）InnoDB的主键范围更大，最大是MyISAM的2倍。
（5）InnoDB不支持全文索引，而MyISAM支持
（6）没有where的count(*)使用MyISAM要比InnoDB快得多。因为MyISAM内置了一
个计数器，count(*)时它直接从计数器中读，而InnoDB必须扫描全表。
（7）MyISAM支持GIS数据，InnoDB不支持
5. Mysql MVCC
（1）MySql实现MVCC的策略
在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为
空，其实还有一列称为回滚指针，用于事务回滚，不在本文范畴）。每开始新的事务，系统版本
号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本
号进行比较。每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较
来达到数据版本控制的目的。
（2）MVCC下CRUD是怎么工作的？
（a）insert
记录的版本号即当前事务的版本号执行一条数据语句：
insert into testmvcc values(1,"test");
假设事务id为1，那么插入后的数据行如下：
（b）update
在更新操作的时候，采用的是先标记旧的那行记录为已删除，并且删除版本号是事务版本号，
然后插入一行新的记录的方式。
比如，针对上面那行记录，事务Id为2 要把name字段更新
update table set name= 'new_value' where id=1
（c）delete
删除操作的时候，就把事务版本号作为删除版本号。比如
delete from table where id=1;
（d）select
从上面的描述可以看到，在查询时要符合以下两个条件的记录才能被事务查询出来：
（i）删除版本号未指定或者大于当前事务版本号，即查询事务开启后确保读取的行未被删
除。(即上述事务id为2的事务查询时，依然能读取到事务id为3所删除的数据行)
（ii）创建版本号小于或者等于当前事务版本号 ，就是说记录创建是在当前事务中（等于的
情况）或者在当前事务启动之前的其他事物进行的insert。（即事务id为2的事务只能
读取到create version<=2的已提交的事务的数据集）
5.mysql和oracle比较
（1）简单版
https://www.cnblogs.com/jeffen/p/6000198.html
（2）详细了解
https://www.cnblogs.com/wangwangever/p/7809788.html
https://www.cnblogs.com/TaoLeonis/p/7043543.html
然后在百度一些东西。
6.mysql大数据量翻页
（1）问题的产生
假设有一个千万量级的表，取1到10条数据；
select * from table limit 0,10; select * from table limit 1000,10;
这两条语句查询时间应该在毫秒级完成。但是，下面这条语句执行时间
大约要5秒
select * from table limit 3000000,10;
为什么相差这么大？这是因为mysql并没有你想的那么智能，比如你要查
询 300w开始后面10条数据，mysql会读取300w加10条这么多的数据，
只不过过滤后返回最后10条而已。
（2）解决方案
（i）业务解决，比如百度，你翻76页就不让你翻了。
（ii）如果你的table的主键id是自增的，并且中间没有删除和断点，可以
使用如下这种方式——在查询下一页的的时候把上一页的行作为参数
传递给客户端。如下例：
select * from table where id>3000000 limit 10;
这条语句执行也是在毫秒级完成的，id>300w其实就是让mysql直接跳到这
里了，不用依次在扫描全面所有的行。
如果你的table的主键id是自增的，并且中间没有删除和断点，比如100页的
10条数据，如下
select * from table where id>100*10 limit 10;
这种方式因为索引扫描，所以速度会很快。有朋友提出: 因为数据
查询出来并不是按照pk_id排序的，所以会有漏掉数据的情况，只
能用如下方法：
基于索引的在排序：
SELECT * FROM 表名称 WHERE id_pk > (pageNum*10) ORDER BY id_pk ASC LIMIT M
（iii）延迟关联（基于子查询）
我们在来分析一下这条语句为什么慢，慢在哪里
select * from table limit 3000000,10;
玄机就处在这个 * 里面，这个表除了id主键肯定还有其他字段 比如 name、
age之类的，因为select * 所以mysql在沿着id主键走的时候要回行拿数据，
走一下拿一下数据。
如果把语句改成：
select id from table limit 3000000,10;
你会发现时间缩短了一半；然后我们在拿id分别去取10条数据就行了。
语句就改成这样了：
select table.* from table inner join ( select id from table limit 3000000,10 ) as tmp on tmp.id=table.id;
这三种方法最先考虑第一种 其次第二种，第三种是别无选择
（iv）基于索引使用prepare（第一个问号表示pageNum，第二个？表
示每页元组数）
PREPARE stmt_name FROM SELECT * FROM 表名称 WHERE id_pk > (？* ？) ORDER BY id_pk ASC LIMIT M
mysql处理prepare的原理：
https://www.cnblogs.com/justfortaste/p/3920140.html
7.truncate和delete的区别
（1）DELETE语句执行删除的过程是每次从表中删除一行，并且同时将该
行的删除操作作为事务记录在日志中保存以便进行进行回滚操作；
TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的
删除操作记录记入日志保存，删除行是不能恢复的，并且在删除的过
程中不会激活与表有关的删除触发器。执行速度快。
（2）当表被TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大
小；DELETE操作不会减少表或索引所占用的空间。
（3）TRUNCATE 只能对TABLE； DELETE可以是table和view
9.数据库锁
（1）共享锁和排它锁（原文：http://www.cnblogs.com/boblogsbo/p/5602122.html）
mysql锁机制分为表级锁和行级锁
共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于
同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所
并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获
取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可
以对数据就行读取和修改。
共享锁：又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一
数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
排它锁：又称为写锁，独占锁，简称X锁，顾名思义，排他锁就是不能与其
他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不
能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的
事务是可以对数据就行读取和修改。
对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于
排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁
住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排
他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其
他的锁，mysql InnoDB引擎默认的修改数据语句，update，delete，insert
都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型（
网上说默认会加S锁，取决于隔离级别），如果加排他锁可以使用
select ...for update语句，加共享锁可以使用select ... lock in share mode
语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通
过for update和lock in share mode锁的方式查询数据，但可以直接通过
select ...from...查询数据，因为普通查询没有任何锁机制；在加了共享锁的
语句上，可以在加共享锁，但是不能加排它锁。实验如下图：
我们看到是可以查询数据的，但加排他锁就查不到，因为排他锁与共享锁不
能存在同一数据上。
（2）悲观锁和乐观锁
悲观锁：在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，
Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制
的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。
如果一个事务执行的操作都某行数据应用了锁，那只有当这个事
务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发
控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁
保护数据的成本要低于回滚事务的成本的环境中。悲观锁的实现，
往往依靠数据库提供的锁机制。悲观锁的执行流程如下：
（i）在对任意记录进行修改前，先尝试为该记录加上排他锁
（exclusive locking）。
（ii）如果加锁失败，说明该记录正在被修改，那么当前查询
可能要等待或者抛出异常。 具体响应方式由开发者根据
实际需要决定。
（iii）如果成功加锁，那么就可以对记录做修改，事务完成后
就会解锁了。
（iv）其间如果有其他对该记录做修改或加排他锁的操作，都
会等待我们解锁或直接抛出异常。
优点与不足：
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处
理的安全提供了保证。但是在效率方面，处理加锁的机制会让
数据库产生额外的开销，还有增加产生死锁的机会；另外，在
只读型事务处理中由于不会产生冲突，也没必要使用锁，这样
做只能增加系统负载；还有会降低了并行性，一个事务如果锁
定了某行数据，其他事务就必须等待该事务处理完才可以处理
那行数据。
MySQL InnoDB中使用悲观锁：
要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，
因为MySQL默认使用autocommit模式，也就是说，当你执行
一个更新操作后，MySQL会立刻将结果进行提交。
set autocommit=0;
//0.开始事务 begin;/begin work;/start transaction; (三者选一就可以) //1.查询出商品信息 select status from t_goods where id=1 for update; //2.根据商品信息生成订单 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status为2 update t_goods set status=2; //4.提交事务 commit;/commit work;
上面的查询语句中，我们使用了select…for update的方式，这样就通过
开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数
据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这
样我们可以保证当前的数据不会被其它事务修改。
上面我们提到，使用select…for update会把数据给锁住，不过我们
需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于
索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表
级锁把整张表锁住，这点需要注意。
乐观锁：在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，
Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。
它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不
产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每
个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。
如果其他事务有更新的话，正在提交的事务会进行回滚。乐观锁
（ Optimistic Locking ） 是相对悲观锁而言，乐观锁假设认为数据一般情
况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的
冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户
决定如何去做。相对于悲观锁，在对数据库进行处理的时候，乐观锁并不
会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。
数据版本，为数据增加的一个版本标识。当读取数据时，将版本标识
的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交
更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版
本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值
相等，则予以更新，否则认为是过期数据（有点像CAS）。
实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间
戳。
使用版本号实现乐观锁：
1.查询出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根据商品信息生成订单 3.修改商品status为2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};
使用时间戳实现乐观锁：有时间在查。
优点与不足
（3）行锁死锁
死锁分行锁死锁和表锁死锁，常见的是行锁死锁，本节介绍行锁死锁
下一节介绍表锁死锁。
（a）在学习行锁死锁之前要补充两个知识点：
（i）在MySQL中，行级锁并不是直接锁记录，而是锁索引。
索引分为主键索引和非主键索引两种，如果一条sql语句操作
了主键索引，MySQL就会锁定这条主键索引；如果一条语句操
作了非主键索引，MySQL会先锁该非主键索引，然后在定再锁
定相关的主键索引。
（ii）行锁是逐行获取的。
比如表A有50行记录，语句一逐行获取锁，获取了1到50条
的锁，语句2逐条获取锁，获取了100到51条的锁，当语句1要
获取第51条记录的锁，语句2要获取第50条记录 的锁，这个时
候就出现了互相等待的状况。
（iii）除了单个SQL组成的事务外，锁是逐步获取的
（b）四种死锁情况
（i）不同表的相同记录行锁冲突
案例：两个表、两行记录，交叉获得和申请互斥锁
条件：
- 两事务分别操作两个表、相同表的同一行记录
- 申请的锁互斥
- 申请的顺序不一致
（ii）主键索引锁冲突
案例：本文案例，产生冲突在主键索引锁上
条件：
- 两sql语句即两事务操作同一个表、使用不同索引
- 申请的锁互斥
- 操作多行记录
- 查找到记录的顺序不一致
案例：
tab_test 结构如下：
id：主键;
state：状态;
time：时间;
索引：idx_1(state，time)
出现死锁的2条sql语句：
update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute); update tab_test set state=1067,time=now () where id in (9921180)
原因分析：
当“update tab_test set state=1064,time=now()
where state=1061 and
time < date_sub(now(), INTERVAL 30 minute)”
执行时，MySQL会使用idx_1索引，因此首先锁定相关
的索引记录，因为idx_1是非主键索引，为执行该语句，
MySQL还会锁定主键索引。假设“update tab_test set
state=1067,time=now () where id in (9921180)”几乎同
时执行时，本语句首先锁定主键索引，由于需要更新
state的值，所以还需要锁定idx_1的某些索引记录。这
样第一条语句锁定了idx_1的记录，等待主键索引，而
第二条语句则锁定了主键索引记录，而等待idx_1的记
录，这样死锁就产生了。在第一条语句给主键加锁前，
第二条语句已经给主键加了锁，所以在高并发的数据
操作时，死锁的情况就容易产生InnoDB 会自动检测一
个事务的死锁并回滚一个或多个事务来防止死锁。Innodb
会选择代价比较小的事务回滚，此次事务。
解决方案：
拆分第一条sql，先查出符合条件的主键值，再按
照主键更新记录：
select id from tab_test where state=1061 and time <
date_sub(now(), INTERVAL 30 minute);
update tab_test state=1064,time=now() where id in(......);
（iii）主键索引锁与非聚簇索引锁冲突
直接看案例：
teamUser表的表结构如下：
PRIMARY KEY (`uid`,`Id`), KEY `k_id_titleWeight_score` (`Id`,`titleWeight`,`score`), ENGINE=InnoDB
出现死锁的两条SQL语句如下：
insert into teamUser_20110121 select * from teamUser DELETE FROM teamUser WHERE teamId=$teamId AND titleWeight<32768 AND joinTime<'$daysago_1week'
原因分析：
在innodb默认的事务隔离级别下，普通的SELECT是不
需要加行锁的，只有LOCK IN SHARE MODE、
FOR UPDATE及高串行化级别中的SELECT都要加锁。但
是此案例中的，第一条语句这种情况
insert into teamUser_20110121 select * from teamUser会
对表teamUser_20110121（ENGINE= MyISAM）加表锁，
并对teamUser表所有行的主键索引（即聚簇索引）加共享
锁。默认对其使用主键索引。而第二条语句
DELETE FROM teamUser WHERE teamId=$teamId
AND titleWeight<32768 AND joinTime<'$daysago_1week'
为删除操作，会对选中行的主键索引加排他锁。由于此语句
还使用了非聚簇索引
KEY `k_teamid_titleWeight_score` (`teamId`,`titleWeight`,`score`)
的前缀索引，于是，还会对相关行的此非聚簇索引加排他锁。
由于共享锁与排他锁是互斥的，当一方拥有了某行记录的
排他锁后，另一方就不能其拥有共享锁，同样，一方拥有了某
行共享锁后，另一方也无法得到其排他锁（可见，元凶是锁是
逐行获取的，比如teamUser表有50行记录，语句一逐行获取锁，
获取了1到50条的锁，语句2逐条获取锁，获取了100到51条的
锁，当语句1要获取第51条记录的锁，语句2要获取第50条记录
的锁，这个时候就出现了互相等待的状况）。所以两条语句同
时行时，相当于两个事务会同时申请某相同记录行的锁资源，
于是会产生锁冲突。由于两个事务都会申请主键索引，锁冲突
只会发生在主键索引上。
解决方案：
InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力
的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且
也在SELECT语句提供非锁定读。这些特色增加了多用户部署
和性能。但其行锁的机制也带来了产生死锁的风险，这就需
要在应用程序设计时避免死锁的发生。以单个SQL语句组成的
隐式事务来说，建议的避免死锁的方法如下：
-- 如果使用insert…select语句备份表格且数据量较大，在单
独的时间点操作，避免与其他sql语句争夺资源，或使用
select into outfile加上load data infile代替 insert…select，
这样不仅快，而且不会要求锁定
-- 一个锁定记录集的事务，其操作结果集应尽量简短，以免
一次占用太多资源，与其他事务处理的记录冲突。
-- 更新或者删除表格数据，sql语句的where条件都是主键或
都是索引，避免两种情况交叉，造成死锁。对于where子
句较复杂的情况，将其单独通过sql得到后，再在更新语句
中使用。
-- sql语句的嵌套表格不要太多，能拆分就拆分，避免占有资
源同时等待资源，导致与其他事务冲突。
-- 对定点运行脚本的情况，避免在同一时间点运行多个对同
一表进行读写的脚本，特别注意加锁且操作数据量比较大的
语句。
-- 应用程序中增加对死锁的判断，如果事务意外结束，重新运
行该事务，减少对功能的影响。
（iv）锁升级造成锁队列阻塞
提交：
- 两事务操作同一行记录
- 一事务对某一记录先申请共享锁，再升级为排他锁
- 另一事务在过程中申请这一记录的排他锁
例如，用户A查询一条纪录，然后修改该条纪录；这时用户B修
改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升
到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释
放共享锁，于是出现了死锁。这种死锁由于比较隐蔽，但在稍大点
的项目中经常发生。
一般更新模式由一个事务组成，此事务读取记录，获取资源
（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X)
锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新
数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁
的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共
享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以
进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都
等待另一个事务释放共享模式锁，因此发生死锁。
解决方法：
-- 使用乐观锁进行控制
-- 使用悲观锁进行控制
（4）表锁死锁
出现原因：
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B访
问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经
锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A
释放表A才能继续，这就死锁就产生了。
解决方法：
这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的
逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，
尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A
和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，
要保证在任何时刻都应该按照相同的顺序来锁定资源。
（b）并发修改同一记录
（c）参见4中的（2）
（4）mysql行级锁、表级锁、页级锁
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最
高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最
低，并发度也最高。
行锁的死锁：参见4中的（2）
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表
锁和行锁之间，并发度一般。
mysql行锁、表锁一些需要注意的点：
（i）在不通过索引条件查询的时候，InnoDB 确实使用的是表锁，而不是行锁。
（ii）由于 MySQL 的行锁是针对索引加的锁，不是针对记录加的锁，所以虽
然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲
突的。应用设计的时候要注意这一点。
（iii）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，
另外，不论是使用主键索引、唯一索引或普通索引，InnoDB 都会使用行
锁来对数据加锁。
（iv）即便在条件中使用了索引字段,但是否使用索引来检索数据是由 MySQL
通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率
更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB
将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的
执行计划，以确认是否真正使用了索引。
什么时候使用表锁？
对于InnoDB表，在绝大部分情况下都应该使用行级锁，因为事务和行锁往
往是我们之所以选择InnoDB表的理由。但在个别特殊事务中，也可以考虑使用
表级锁。
第一种情况是：事务需要更新大部分或全部数据，表又比较大，如果使用默认
的行锁，不仅这个事务执行效率低，而且可能造成其他事务长
时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该
事务的执行速度。
第二种情况是：事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务
回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避
免死锁、减少数据库因事务回滚带来的开销。
表锁和行锁应用场景：
表级锁使用与并发性不高，以查询为主，少量更新的应用，比如小型的
web应用；而行级锁适用于高并发环境下，对事务完整性要求较高的系
统，如在线事务处理系统。
10.数据库三范式和五大约束
（1）三范式
第一范式（1NF）：当关系模式R的所有属性都不能在分解为更基本的数据单
位时，称R是满足第一范式的，简记为1NF。满足第一范
式是关系模式规范化的最低要求，否则，将有很多基本操
作在这样的关系模式中实现不了。通俗的说就是：
（a）数据表中的每一列（每个字段）必须是不可拆分的最
小单元，也就是确保每一列的原子性；
（b）两列的属性相近或相似或一样，尽量合并属性一样的
列，确保不产生冗余数据。
第二范式（2NF）：如果关系模式R满足第一范式，并且R得所有非主属性都
完全依赖于R的每一个候选关键属性，称R满足第二范式，
简记为2NF。通俗的说是每一行的数据只能与其中一列
相关，即一行数据只做一件事。只要数据列中出现数据重
复，就要把表拆分开来。例如，一个人同时订几个房间，
就会出来一个订单号多条数据，这样子联系人都是重复的，
就会造成数据冗余。我们应该把他拆开来。
第三范式（3NF）：设R是一个满足第一范式条件的关系模式，X是R的任意属
性集，如果X非传递依赖于R的任意一个候选关键字，称R
满足第三范式，简记为3NF。通俗的说就是“数据不能存在
传递关系，即每个属性都跟主键有直接关系而不是间接关
系”。例如，Student表（学号，姓名，年龄，性别，所在
院校，院校地址，院校电话）这样一个表结构，就存在上
述关系。 学号--> 所在院校 --> (院校地址，院校电话)这样
的表结构，我们应该拆开来，如下：（学号，姓名，年龄，
性别，所在院校）--（所在院校，院校地址，院校电话）
（2）五大约束
（a）主键约束（Primay Key Coustraint） 唯一性，非空性
添加主键约束（将stuNo作为主键）
alter table stuInfo
add constraint PK_stuNo primary key (stuNo)
（b）唯一约束 （Unique Counstraint）唯一性，可以空，但只能有一个
添加唯一约束（身份证号唯一，因为每个人的都不一样）
alter table stuInfo
add constraint UQ_stuID unique(stuID)
（c）检查约束 (Check Counstraint) 对该列数据的范围、格式的限制（如：年
龄、性别等）
添加检查约束 （对年龄加以限定 15-40岁之间）
alter table stuInfo
add constraint CK_stuAge check (stuAge between 15 and 40)
（d）默认约束 (Default Counstraint) 该数据的默认值
添加默认约束（如果地址不填 默认为“地址不详”）
alter table stuInfo
add constraint DF_stuAddress default (‘地址不详’) for stuAddress
（e）外键约束 (Foreign Key Counstraint) 需要建立两表间的关系并引用主表
的列
添加外键约束 (主表stuInfo和从表stuMarks建立关系，关联字段stuNo)
alter table stuInfo
add constraint FK_stuNo foreign key(stuNo)references stuinfo(stuNo)
二：数据库的分库分表
1.互联网行业传统架构中分库分表（水平分库分表）
（1）水平分库分表产生的业务场景
对于大型的互联网应用来说，数据库单表的记录行数可能达到千万
级甚至是亿级，并且数据库面临着极高的并发访问。采用Master-Slave
复制模式的MySQL架构，只能够对数据库的读进行扩展，而对数据库的
写入操作还是集中在Master上，并且单个Master挂载的Slave也不可能无
限制多，Slave的数量受到Master能力和负载的限制。
（2）分表
对于访问极为频繁且数据量巨大的单表来说，我们首先要做的就是
减少单表的记录条数，以便减少数据查询所需要的时间，提高数据库的
吞吐，这就是所谓的分表！
在分表之前，首先需要选择适当的分表策略，使得数据能够较为均
衡地分不到多张表中，并且不影响正常的查询！
对于互联网企业来说，大部分数据都是与用户关联的，因此，用户
id是最常用的分表字段。因为大部分查询都需要带上用户id，这样既不
影响查询，又能够使数据较为均衡地分布到各个表中(当然，有的场景
也可能会出现冷热数据分布不均衡的情况)，如下图：
注：拆分后表的数量一般为2的n次方（为什么是2的n次方呢？因为
2的n次方是最小的拆分，最小的正整数是1，1的n次方是1，所以
使用2的n次方分表）。
假设有一张表记录用户购买信息的订单表order，由于order表记
录条数太多，将被拆分成256张表。拆分的记录根据user_id%256取
得对应的表进行存储，前台应用则根据对应的user_id%256，找到对
应订单存储的表进行访问。这样一来，user_id便成为一个必需的查询
条件，否则将会由于无法定位数据存储的表而无法对数据进行访问。
这样一来，user_id便成为一个必需的查询条件，否则将会由于无
法定位数据存储的表而无法对数据进行访问。
举例说明user_id为必须查询的字段
假设表结构为：
create table order_( order_id bigint(20) primary key auto_increment, user_id bigint(20), user_nick varchar(50), auction_id bigint(20), auction_title bigint(20), price bigint(20), auction_cat varchar(200), seller_id bigint(20), seller_nick varchar(50) )
那么分表以后，假设user_id = 257,并且auction_id = 100,需要根
据auction_id来查询对应的订单信息，则对应的SQL语句如下：
select * from order_1 where user_id=257 and auction_id = 100;
其中，order_1是根据257%256计算得出，表示分表之后的第一
张order表。
（3）分库
分表能够解决单表数据量过大带来的查询效率下降的问题，但是，
却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访
问，当数据库master服务器无法承载写操作压力时，不管如何扩展
slave服务器，此时都没有意义了。因此，我们必须换一种思路，对数
据库进行拆分，从而提高数据库写入能力，这就是所谓的分库!
与分表策略相似，分库可以采用通过一个关键字取模的方式，来
对数据访问进行路由，如下图所示：
还是之前的订单表，假设user_id 字段的值为258，将原有的单库
分为256个库，那么应用程序对数据库的访问请求将被路由到第二个
库(258%256 = 2)。
（3）分库分表
（a）为什么要分库分表？
有时数据库可能既面临着高并发访问的压力，又需要面
对海量数据的存储问题，这时需要对数据库既采用分表策略，
又采用分库策略，以便同时扩展系统的发处理能力，以及提升
单表的查询性能，这就是所谓的分库分表。
（b）分库分表策略
注：下面案例中，库的编号是一个自然序列，且从0开始
中间变量=userid%(库的数量*每个库表的数量)
库=“中间变量/每个库的表的数量” 然后在取整 。
表=中间变量%库中的表数量
注意：上面公式的第一步，求的是所有表的自然序列；
第二步，如果库的下标是从0开始，向下取整，
如果库的编号从1开始像上取整。
假设将原来的单库单表order拆分成256个库，每个库包含1024
个表，那么按照前面所提到的路由策略，对于user_id=262145
的访问，路由的计算过程如下：
* 中间变量 = 262145 % (256 * 1024) = 1
* 库 = 取整 (1/1024) = 0
* 表 = 1 % 1024 = 1
结论，user_id=262145 的订单记录的查询和修改，将被路由到
第0个库的第1个order_1表中执行
（4）垂直分表
上面介绍的分表方式是水平的，下面介绍垂直分表。
（a）为什么要垂直分表？
如果一个表的字段非常多，有可能造成数据库的跨页存储，
这就导致了性能的下降，垂直分表正式为了解决这个问题产生
的。
（b）垂直分表
垂直分表就是将一张表中不常用的字段拆分到另一张表中，
从而保证第一章表中的字段较少，避免出现数据库跨页存储的
问题，从而提升查询效率。而另一张表中的数据通过外键与第
一张表进行关联，如下图所示：
2. 微服务架构中的分库（垂直分库）
垂直分库即是将一个完整的数据库根据业务功能拆分成多个独立的数据
库，这些数据库可以运行在不同的服务器上，从而提升数据库整体的数
据读写性能。这种方式在微服务架构中非常常用。微服务架构的核心思
想是将一个完整的应用按照业务功能拆分成多个可独立运行的子系统，
这些子系统称为“微服务”，各个服务之间通过RPC接口通信，这样的结
构使得系统耦合度更低、更易于扩展。垂直分库的理念与微服务的理念
不谋而合，可以将原本完整的数据按照微服务拆分系统的方式，拆分成
多个独立的数据库，使得每个微服务系统都有各自独立的数据库，从而
可以避免单个数据库节点压力过大，影响系统的整体性能，如下图所示
3. 微服务分库（垂直分库）跨库join的几种解决方案
（1）全局表
所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些
表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们
可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常
也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。
（2）字段冗余
这是一种典型的反范式设计，在互联网行业中比较常见，通常是
为了性能来避免join查询。
举个电商业务中很简单的场景：
“订单表”中保存“卖家Id”的同时，将卖家的“Name”字段也冗
余，这样查询订单详情的时候就不需要再去查询“卖家用户表”。
字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场
景也比较有限，比较适合依赖字段较少的情况。最复杂的还是数
据一致性问题，这点很难保证，可以借助数据库中的触发器或者
在业务代码层面去保证。当然，也需要结合实际业务场景来看一
致性的要求。就像上面例子，如果卖家修改了Name之后，是否
需要在订单信息中同步更新呢？
（3）数据同步
定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定
的表做同步。当然，同步本来会对数据库带来一定的影响，需要
性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库
查询。笔者曾经在项目中是通过ETL工具来实施的。
（4）新建链接表
（4）系统层组装
（原文出自博客：https://www.open-open.com/lib/view/open1473820694158.html#articleHeader4
的系统层组装章节中，如果博客被删了，百度“跨库 系统层组装”。
其实（1）、（2）、（3）、（4）点都来自这篇博客）
在系统层面，通过调用不同模块的组件或者服务，获取到数据并
进行字段拼装。说起来很容易，但实践起来可真没有这么简单，尤其
是数据库设计上存在问题但又无法轻易调整的时候。具体情况通常会
比较复杂。下面笔者结合以往实际经验，并通过伪代码方式来描述。
（a）简单的列表查询的情况
伪代码很容易理解，先获取“我的提问列表”数据，然后再根
据列表中的UserId去循环调用依赖的用户服务获取到用户的
RealName，拼装结果并返回。有经验的读者一眼就能看出上诉
伪代码存在效率问题。循环调用服务，可能会有循环RPC，循
环查询数据库…不推荐使用。再看看改进后的：
这种实现方式，看起来要优雅一点，其实就是把循环调用改成
一次调用。当然，用户服务的数据库查询中很可能是In查询，效率
方面比上一种方式更高。（坊间流传In查询会全表扫描，存在性能
问题，传闻不可全信。其实查询优化器都是基本成本估算的，经过
测试，在In语句中条件字段有索引的时候，条件较少的情况是会走
索引的。这里不细展开说明，感兴趣的朋友请自行测试）。
小结
简单字段组装的情况下，我们只需要先获取“主表”数据，
然后再根据关联关系，调用其他模块的组件或服务来获取
依赖的其他字段（如例中依赖的用户信息），最后将数据
进行组装。通常，我们都会通过缓存来避免频繁RPC通信
和数据库查询的开销。
（b）列表查询带条件过滤的情况
- 查出所有的问答数据，然后调用用户服务进行拼装数据，再根据过滤
字段state字段进行过滤，最后进行排序和分页并返回。这种方式能够
保证数据的准确性和完整性，但是性能影响非常大，不建议使用。
- 查询出state字段符合/不符合的UserId，在查询问答数据的时候使用
in/not in进行过滤，排序，分页等。过滤出有效的问答数据后，再调
用用户服务获取数据进行组装。
（c）跨库事务（分布式事务）的问题
按业务拆分数据库之后，不可避免的就是“分布式事务”的问题。以
往在代码中通过spring注解简单配置就能实现事务的，现在则需要花很
大的成本去保证一致性。这里不展开介绍。
4. 跨库翻页
参考文章：https://blog.csdn.net/kai161/article/details/70159079
（1）先介绍万能的终极武器“二次查询法”
“二次查询法”即能够满足业务的精确需要，无需业务折衷，又高性能的
方法。该方法比较复杂，通过例子讲解。
假设一页只有5条数据，查询第200页的SQL语句为
select * from T order by time offset 1000 limit 5；
步骤一：查询改写
将select * from T order by time offset 1000 limit 5
改写为select * from T order by time offset 333 limit 5
并投递给所有的分库。注意，这个offset的333，来自于全局offset
的总偏移量1000，除以水平切分数据库个数3。如果是2个分库，
则可以改写为select * from T order by time offset 500limit 5
假设这三个分库返回的数据(time, uid)如下：
可以看到，每个分库都是返回的按照time排序的一页数据。
步骤二：找到所返回3页全部数据的最小值
第一个库，5条数据的time最小值是1487501123
第二个库，5条数据的time最小值是1487501133
第三个库，5条数据的time最小值是1487501143
故，三页数据中，time最小值来自第一个库，time_min=1487501123，
这个过程只需要比较各个分库第一条数据，时间复杂度很低。
步骤三：查询二次改写
上面第一次改写后的SQL为：
是select * from T order by time offset 333 limit 5
那么，第二次要改写成一个between语句，between的起点是
time_min，between的终点是原来每个分库各自返回数据的最
大值。
第一个分库，第一次返回数据的最大值是1487501523
所以查询改写为select * from T order by time where time
between time_min and 1487501523
第二个分库，第一次返回数据的最大值是1487501323
所以查询改写为select * from T order by time where time
between time_min and 1487501323
第三个分库，第一次返回数据的最大值是1487501553
所以查询改写为select * from T order by time where time
between time_min and 1487501553
相对第一次查询，第二次查询条件放宽了，故第二次查询会返回比
第一次查询结果集更多的数据，假设这三个分库返回的数据
(time, uid)如下：
可以看到：
由于time_min来自原来的分库一，所以分库一的返回结果
集和第一次查询相同（所以其实这次访问是可以省略的）；分
库二的结果集，比第一次多返回了1条数据，头部的1条记录
（time最小的记录）是新的（上图中粉色记录）；分库三的结
果集，比第一次多返回了2条数据，头部的2条记录（time最小
的2条记录）是新的（上图中粉色记录）；
步骤四：找到全局offset
我们在每个结果集中虚拟一个time_min记录，找到time_min在全局
的offset
在第一个库中，time_min在第一个库的offset是333
在第二个库中，(1487501133, uid_aa)的offset是333（根据第一次
查询条件得出的），因为按第二次改写多了一条数据，所以故虚拟
time_min在第二个库的offset是331.
在第三个库中，(1487501143, uid_aaa)的offset是333（根据第一次
查询条件得出的），因为按第二次改写多了两条数据，故虚拟
time_min在第三个库的offset是330综上，time_min在全局的offset是
333+331+330=994。
综上，time_min在全局的offset是333+331+330=994
4. mysql SSL连接
MySQL默认的数据通道是不加密的，在一些安全性要求特别高的场景下，我们需
要配置MySQL端口为SSL，使得数据通道加密处理，避免敏感信息泄漏和被篡改。
当然，启用MySQL SSL之后，由于每个数据包都需要加密和解密，这个对MySQL
的性能是有不小影响的，读者们在使用的时候，要根据实际情况斟酌。
SSL证书：https正是使用的SSL证书，http+ssl=https
MySQL客户端登录服务器时候的密码不是明文传输，有加密策略处理
1.自己比较懵懂的概念
（1）数据库分区
查看：https://blog.csdn.net/xhf852963/article/details/78896427
（2）数据库分片
伪代码很容易理解，先获取“我的提问列表”数据，然后再根
据列表中的UserId去循环调用依赖的用户服务获取到用户的
RealName，拼装结果并返回。有经验的读者一眼就能看出上诉
伪代码存在效率问题。循环调用服务，可能会有循环RPC，循
环查询数据库…不推荐使用。再看看改进后的：
这种实现方式，看起来要优雅一点，其实就是把循环调用改成
一次调用。当然，用户服务的数据库查询中很可能是In查询，效率
方面比上一种方式更高。（坊间流传In查询会全表扫描，存在性能
问题，传闻不可全信。其实查询优化器都是基本成本估算的，经过
测试，在In语句中条件字段有索引的时候，条件较少的情况是会走
索引的。这里不细展开说明，感兴趣的朋友请自行测试）。
