MySQL优化：order by和limit

order by和limit一起使用，避免引起全表扫描和数据排序是非常重要的，因此借助合适的索引提高查询效率。

in的参数个数为1个，联合索引生效，大于1个，索引失效。所以使用了强制索引使联合索引生效。

原因分析：

第一、取决于B树的数据结构，单参数的IN只会得到一颗基于model子树，该子树的code本身是有序的，所以索引生效，查询效率高；多参数的IN会得到多颗基于model的子树，每颗子树的code字段是有序的，但是总体上可能不是有序的，所以索引失效，查询效率低。

第二、使用强制索引后，理论上无法保证order by的顺序，但是如果数据本身的特性，比如时间递增的这类数据，总体上还是有序的，笔者试过多中途径想要迫使强制索引得到错误的结果，结果都对了。强制索引需进一步研究。

此时，通过子查询优化limit，效果如下：

以上数据来自一张超过2000万的MySQL单表，仅供参考，能够说明子查询明显能够提升效率，笔者开始尝试把子查询的order by去掉，发现查询效率又提升2倍，但是对比发现数据不正确，explain后发现查询优化器给出的子查询索引并不是id（此表建有多个索引，id是主键，区分度最高），这一点比较困惑。

ps：在sql语句中，limt关键字是最后才用到的。以下条件的出现顺序一般是：where->group by->having-order by->limit

当然这种结构就不要追求什么效率了。如果要效率高的，只能改表结构。

1：select p2.id from table p1 ,table p2 where p1.id=p2.pid and p1.id=0

2：假设表名是tree

SQL codeselect distinct a.id from tree as a inner join tree as b on (a.pid = b.pid) where b.pid >=0

select distinct a.id from tree as a inner join tree as b on (a.pid = b.pid) where b.pid >=2

3.通过程序或数据库的store procedure来实现了。 在mySQL中无法以一句SQL实现。

    二叉树：当不平衡时，单边增长，可能退化为线性

    红黑树：数据量大时，深度不可控

    AVL树：相比较与红黑树，严格平衡，但是增删情况下，通过旋转再平衡的开销过大，适合查找场景多的应用

    Hash： 不支持范围查找

    平衡的多路查找树，一个结点存放多个元素。

与红黑树相比，在相同的的节点的情况下，一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上 *** 作的时间通常由存取磁盘的时间和CPU计算时间这两部分构成，而CPU的速度非常快，所以B树的 *** 作效率取决于访问磁盘的次数，关键字总数相同的情况下B树的高度越小，磁盘I/O所花的时间越少。

    m阶：节点中，子节点数的最大值（子节点数，不是结点存放元素）

1. 树中每个结点最多m个子树（最多m-1个关键字，两个子树夹一个关键字）

2. 根节点最少有1个关键字

3. 非根结点最少m/2个子树（m/2 - 1个关键字）

4. 每个关键字排序

5. 所有的叶子结点位于同一层

6. 每个结点都存有索引和数据

（1）简介

B+树是应文件系统所需而产生的一种B树的变形树（文件的目录一级一级索引，只有最底层的叶子节点（文件）保存数据）非叶子节点只保存索引，不保存实际的数据，数据都保存在叶子节点中。所有的非叶子节点都可以看成索引部分！

（2）B+树的性质(下面提到的都是和B树不相同的性质)

1. b+树有两种类型的结点：

1.1 内部结点（索引结点，非叶结点）： 只存索引，不存数据

1.2 叶子结点 （存数据）

2. 内部结点 和 叶子结点的 key递增排序

3. 每个叶结点存有相邻叶结点的指针

4. 父结点存有右孩子第一个元素索引

1.磁盘io代价低：b+树的非叶结点只存储索引，不存储数据，单一结点能存放的索引数更多，树更矮胖

2. b+树查询效率稳定：所有查询必须到叶节点

3. b+树叶子节点为有序表，效率更高，支持范围查询。

---