分页查询：
CREATE TABLE `tb_user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`username` varchar(50) NOT NULL COMMENT '用户名',
`password` varchar(32) NOT NULL COMMENT '密码，加密存储',
`phone` varchar(20) DEFAULT NULL COMMENT '注册手机号',
`email` varchar(50) DEFAULT NULL COMMENT '注册邮箱',
`created` datetime NOT NULL,
`updated` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `name_phone_email` (`username`,`phone`,`email`)
) ENGINE=InnoDB AUTO_INCREMENT=102538 DEFAULT CHARSET=utf8 COMMENT='用户表';
SELECT * from tb_user ORDER BY username LIMIT 90000,10;
根据username 排序排序后取出取出90001行开始的10条记录，实际是先取出90010条记录，抛弃前面的90000条数据，只保留后面的10条数据返给前端。因此查询一张大表时，获取越靠后的数据，查询效率越低。
没有走索引，前面的文档说过，可能优化器觉得通过索引找到符合条件的主键，再利用主键到主键索引中找数据，比直接扫描主键索引的成本还要高；但是使用覆盖索引，绝大情况下会走索引的。
Join关联查询优化：
Mysql表关联常用的两种算法：
- Nested-Loop Join算法
- Block Nested-Loop Join算法
1、嵌套循环连接Nested-Loop Join（NLJ）算法
一般索引字段关联的使用此算法
一次一行的从驱动表中取出数据行，用这行数据的关联字段查询被驱动表的满足条件的数据，然后合并表的结果集。
图中user表只有两条数据，tb_user有十万条数据；从执行计划中可以看出user表是驱动表，优化器一般会选择小表作为驱动表；
当使用left join时，指定了左表是驱动表；但使用right join时，指定了右表是驱动表；当使用inner join时，使用小表做为驱动表。
一般join语句，执行计划中Extra中未出现using join buffer则表示使用的join算法是NLJ算法。
上面sql的执行流程如下：
1、取出user表中满足条件的一行数据
2、从上步取出关联的字段id到tb_user中查找
3、取出tb_user表中满足条件的数据，跟user表中取出的数据合并；放在结果集中
4、重复上面的步骤，直到user表取不到数据为止，最后把结果集中的数据返给客户端。
2、基于块的嵌套循环连接Block Nested-Loop Join（BNJ）算法
如果被驱动表关联字段不是索引，则会使用此算法
把驱动表的数据读到join buffer中，然后把被驱动表中的数据一行行取出来和join buffer中的数据做对比，保留符合条件的数据到结果集中。
上面sql执行的大致流程如下：
1、先从user表中取出所有满足条件的数据到join buffer中
2、把tb_user表中的每一行取出来和join buffer中的数据做对比
3、把对比满足条件的数据放在结果集中
4、返回结果集给前端。
对于关联sql的优化：
1、被驱动表的关联字段尽量使用索引，让使用NLJ算法
2、小表驱动大表：确定哪张表是小表，可以用straight_join来指定左边的表作为驱动表，省去mysql优化器判断的时间。
in和exsits优化：
小表驱动大表的优化原则，即小的数据集驱动大的数据集
in：当B表的数据集小于A表时，in优于exsits
select * from A where id in (select id from B);
等价于：
for(select id from B ){
select * from A where A.id=B.id;
}
exsits:当B表的数据大于A表时，exsits优于in
select * from A where exsits (select 1 from B where B.id=A.id );
等价于：
for(select id from A){
select * from B where B.id=A.id;
}
1、exists(条件) 只返回true和false，因此select *和select 1没有区别，官方说会忽略查询字段；
2、exists子语句查询可以使用join查询来代替，需要根据具体情况来优化
补充：MySQL数据类型选择
在MySQL中，选择正确的数据类型，对于性能至关重要。一般应该遵循下面两步：
（1）确定合适的大类型：数字、字符串、时间、二进制；
（2）确定具体的类型：有无符号、取值范围、变长定长等。
在MySQL数据类型设置方面，尽量用更小的数据类型，因为它们通常有更好的性能，花费更少的硬件资源。并且，尽量
把字段定义为NOT NULL，避免使用NULL。
1、数值类型
优化建议
- 如果整形数据没有负数，如ID号，建议指定为UNSIGNED无符号类型，容量可以扩大一倍。
- 建议使用TINYINT代替ENUM、BITENUM、SET。
- 避免使用整数的显示宽度(参看文档最后)，也就是说，不要用INT(10)类似的方法指定字段显示宽度，直接用 INT。
- DECIMAL最适合保存准确度要求高，而且用于计算的数据，比如价格。但是在使用DECIMAL类型的时候，注意 长度设置。
- 建议使用整形类型来运算和存储实数，方法是，实数乘以相应的倍数后再操作。
- 整数通常是最佳的数据类型，因为它速度快，并且能使用AUTO_INCREMENT。
2、日期和时间
优化建议
- MySQL能存储的最小时间粒度为秒。
- 建议用DATE数据类型来保存日期。MySQL中默认的日期格式是yyyy-mm-dd。
- 用MySQL的推荐类型DATE、TIME、DATETIME来存储时间，而不是使用字符串。
- 当数据格式为TIMESTAMP和DATETIME时，可以用CURRENT_TIMESTAMP作为默认（MySQL5.6以后），
MySQL会自动返回记录插入的确切时间。 - TIMESTAMP是UTC时间戳，与时区相关。
- DATETIME的存储格式是一个YYYYMMDD HH:MM:SS的整数，与时区无关，你存了什么，读出来就是什么。
- 除非有特殊需求，一般的公司建议使用TIMESTAMP，它比DATETIME更节约空间，但是像阿里这样的公司一般会用DATETIME，因为不用考虑TIMESTAMP将来的时间上限问题。
- 有时人们把Unix的时间戳保存为整数值，但是这通常没有任何好处，这种格式处理起来不太方便，我们并不推荐它。
3、字符串
优化建议
- 字符串的长度相差较大用VARCHAR；字符串短，且所有值都接近一个长度用CHAR。
- CHAR和VARCHAR适用于包括人名、邮政编码、电话号码和不超过255个字符长度的任意字母数字组合。那些要用来计算的数字不要用VARCHAR类型保存，因为可能会导致一些与计算相关的问题。换句话说，可能影响到计算的准确性和完整性。
- 尽量少用BLOB和TEXT，如果实在要用可以考虑将BLOB和TEXT字段单独存一张表，用id关联。
- BLOB系列存储二进制字符串，与字符集无关。TEXT系列存储非二进制字符串，与字符集相关。
- BLOB和TEXT都不能有默认值。
INT显示宽度
我们经常会使用命令来创建数据表，而且同时会指定一个长度，如下。但是，这里的长度并非是TINYINT类型存储的最大长度，而是显示的最大长度。
CREATE TABLE user(
id TINYINT(2) UNSIGNED
);
这里表示user表的id字段的类型是TINYINT，可以存储的最大数值是255。所以，在存储数据时，如果存入值小于等于 255，如200，虽然超过2位，但是没有超出TINYINT类型长度，所以可以正常保存；如果存入值大于255，如500，那么 MySQL会自动保存为TINYINT类型的最大值255。
在查询数据时，不管查询结果为何值，都按实际输出。这里TINYINT(2)中2的作用就是，当需要在查询结果前填充0时，
命令中加上ZEROFILL就可以实现，如：
id TINYINT(2) UNSIGNED ZEROFILL
这样，查询结果如果是5，那输出就是05。如果指定TINYINT(5)，那输出就是00005，其实实际存储的值还是5，而且存储的数据不会超过255，只是MySQL输出数据时在前面填充了0。
换句话说，在MySQL命令中，字段的类型长度TINYINT(2)、INT(11)不会影响数据的插入，只会在使用ZEROFILL时有用，让查询结果前填充0。