MySQL索引使用原则
mysql一直了解得都不多，之前写sql准备提交生产环境之前的时候，老员工帮我检查了下sql，让修改了一下存储引擎，当时我使用的是myisam，后面改成innodb了。为什么要改成这样，之前都没有听过存储引擎，于是网上查了一下。
事实上使用不同的存储引擎也是有很大区别的，下面猿友们可以了解一下。
一、存储引擎的比较
注：上面提到的b树索引并没有指出是b-tree和b+tree索引，但是b-树和b+树的定义是有区别的。
在 mysql 中，主要有四种类型的索引，分别为： b-tree 索引， hash 索引， fulltext 索引和 r-tree 索引。
b-tree 索引是 mysql 数据库中使用最为频繁的索引类型，除了 archive 存储引擎之外的其他所有的存储引擎都支持 b-tree 索引。archive 引擎直到 mysql 5.1 才支持索引，而且只支持索引单个 auto_increment 列。
不仅仅在 mysql 中是如此，实际上在其他的很多数据库管理系统中b-tree 索引也同样是作为最主要的索引类型，这主要是因为 b-tree 索引的存储结构在数据库的数据检索中有非常优异的表现。
一般来说， mysql 中的 b-tree 索引的物理文件大多都是以 balance tree 的结构来存储的，也就是所有实际需要的数据都存放于 tree 的 leaf node(叶子节点) ，而且到任何一个 leaf node 的最短路径的长度都是完全相同的，所以我们大家都称之为 b-tree 索引。当然，可能各种数据库（或 mysql 的各种存储引擎）在存放自己的 b-tree 索引的时候会对存储结构稍作改造。如 innodb 存储引擎的 b-tree 索引实际使用的存储结构实际上是 b+tree，也就是在 b-tree 数据结构的基础上做了很小的改造，在每一个leaf node 上面出了存放索引键的相关信息之外，还存储了指向与该 leaf node 相邻的后一个 leafnode 的指针信息（增加了顺序访问指针），这主要是为了加快检索多个相邻 leaf node 的效率考虑。
innodb是mysql的默认存储引擎(mysql5.5.5之前是myisam）
可能对于没有了解过索引的猿友这样看这篇文章十分吃力，这类猿友有必要先对mysql索引有个大体的了解，可以看看另外一篇文章：数据库查询优化——mysql索引http://blog.csdn.net/u013142781/article/details/51424174看完这篇文章我们再回头看看上面的文字说明吧。
接下来我们先看看b-树、b+树的概念。弄清楚，为什么加了索引查询速度会加快？
二、b-树、b+树概念
b树
即二叉搜索树：
1、所有非叶子结点至多拥有两个儿子（left和right）；
2、所有结点存储一个关键字；
3、非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；
如：
b-树
是一种多路搜索树（并不是二叉的）：
1、定义任意非叶子结点最多只有m个儿子；且m>2；
2、根结点的儿子数为[2, m]；
3、除根结点以外的非叶子结点的儿子数为[m/2, m]；
4、每个结点存放至少m/2-1（取上整）和至多m-1个关键字；（至少2个关键字）
5、非叶子结点的关键字个数=指向儿子的指针个数-1；
6、非叶子结点的关键字：k[1], k[2], …, k[m-1]；且k[i] 、 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
2、=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
3、尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录
4、索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
5、尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
三星s8曝还不会启用三星Bixby语音功能，失望嘛
三星将推比小米MIX更惊艳的屏占比达99%的手机
VR技术在医疗领域中该如何应用
探讨负电压浪涌的对策及其效果
没有云储存功能的摄像头都是耍流氓
MySQL索引使用原则
一个基本的pad library设计方案
中国移动便率先在北京开通了4.9GHz频段5G基站
Linux终端工具介绍——WindTerm
硬创早报：DSCC下调2021-2023年全球OLED面板制造设备支出预期
电容器组的作用是什么_电容器组运行注意事项
【节能学院】安科瑞餐饮油烟在线监测系统在云龙湖畔景区大中型餐饮油烟治理中的应用
微雪电子RS485 Board UART转485模块简介
IAR 开发环境下调试从核工程的方法(IAR篇)
S7-1500和S7-1200 F-CPU间Flexible F-Link通信
如何从Altium Designer中连接到我的Workspace？
最快速红外线传感器(Silicon Labs)
测试新唐nuc980串口功能的过程
电磁兼容EMC测试RS485接口的电路设计
刮泥机PLC数据采集远程监控系统
事实上使用不同的存储引擎也是有很大区别的，下面猿友们可以了解一下。
一、存储引擎的比较
注：上面提到的b树索引并没有指出是b-tree和b+tree索引，但是b-树和b+树的定义是有区别的。
在 mysql 中，主要有四种类型的索引，分别为： b-tree 索引， hash 索引， fulltext 索引和 r-tree 索引。
b-tree 索引是 mysql 数据库中使用最为频繁的索引类型，除了 archive 存储引擎之外的其他所有的存储引擎都支持 b-tree 索引。archive 引擎直到 mysql 5.1 才支持索引，而且只支持索引单个 auto_increment 列。
不仅仅在 mysql 中是如此，实际上在其他的很多数据库管理系统中b-tree 索引也同样是作为最主要的索引类型，这主要是因为 b-tree 索引的存储结构在数据库的数据检索中有非常优异的表现。
一般来说， mysql 中的 b-tree 索引的物理文件大多都是以 balance tree 的结构来存储的，也就是所有实际需要的数据都存放于 tree 的 leaf node(叶子节点) ，而且到任何一个 leaf node 的最短路径的长度都是完全相同的，所以我们大家都称之为 b-tree 索引。当然，可能各种数据库（或 mysql 的各种存储引擎）在存放自己的 b-tree 索引的时候会对存储结构稍作改造。如 innodb 存储引擎的 b-tree 索引实际使用的存储结构实际上是 b+tree，也就是在 b-tree 数据结构的基础上做了很小的改造，在每一个leaf node 上面出了存放索引键的相关信息之外，还存储了指向与该 leaf node 相邻的后一个 leafnode 的指针信息（增加了顺序访问指针），这主要是为了加快检索多个相邻 leaf node 的效率考虑。
innodb是mysql的默认存储引擎(mysql5.5.5之前是myisam）
可能对于没有了解过索引的猿友这样看这篇文章十分吃力，这类猿友有必要先对mysql索引有个大体的了解，可以看看另外一篇文章：数据库查询优化——mysql索引http://blog.csdn.net/u013142781/article/details/51424174看完这篇文章我们再回头看看上面的文字说明吧。
接下来我们先看看b-树、b+树的概念。弄清楚，为什么加了索引查询速度会加快？
二、b-树、b+树概念
b树
即二叉搜索树：
1、所有非叶子结点至多拥有两个儿子（left和right）；
2、所有结点存储一个关键字；
3、非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；
如：
b-树
是一种多路搜索树（并不是二叉的）：
1、定义任意非叶子结点最多只有m个儿子；且m>2；
2、根结点的儿子数为[2, m]；
3、除根结点以外的非叶子结点的儿子数为[m/2, m]；
4、每个结点存放至少m/2-1（取上整）和至多m-1个关键字；（至少2个关键字）
5、非叶子结点的关键字个数=指向儿子的指针个数-1；
6、非叶子结点的关键字：k[1], k[2], …, k[m-1]；且k[i] 、 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
2、=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
3、尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录
4、索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
5、尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
三星s8曝还不会启用三星Bixby语音功能，失望嘛
三星将推比小米MIX更惊艳的屏占比达99%的手机
VR技术在医疗领域中该如何应用
探讨负电压浪涌的对策及其效果
没有云储存功能的摄像头都是耍流氓
MySQL索引使用原则
一个基本的pad library设计方案
中国移动便率先在北京开通了4.9GHz频段5G基站
Linux终端工具介绍——WindTerm
硬创早报：DSCC下调2021-2023年全球OLED面板制造设备支出预期
电容器组的作用是什么_电容器组运行注意事项
【节能学院】安科瑞餐饮油烟在线监测系统在云龙湖畔景区大中型餐饮油烟治理中的应用
微雪电子RS485 Board UART转485模块简介
IAR 开发环境下调试从核工程的方法(IAR篇)
S7-1500和S7-1200 F-CPU间Flexible F-Link通信
如何从Altium Designer中连接到我的Workspace？
最快速红外线传感器(Silicon Labs)
测试新唐nuc980串口功能的过程
电磁兼容EMC测试RS485接口的电路设计
刮泥机PLC数据采集远程监控系统