mysql动态的limit查询

在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。

而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。

当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。

而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。

limit x, y：表示跳过x个数据读取y个数据

limit x offset y：表示跳过y个数据读取x个数据，offset表示偏移量

limit x：表示从头开始读取x个数据，相当于limit 0，x

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

---