MySql优化 二

示例表：
CREATE TABLE `employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
  `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',
  PRIMARY KEY (`id`),
  KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
) EN

分页查询优化

常见的分页场景优化方式

​ 连续自增主键分页的例子:

select * from table limit 10000,10;
当前sql查询10000-10010的数据,当前查询看似只是查询了10条数据,其实这条sql查询了10010条数据,获取到了后面十条数据,抛弃了前面10000条数据.
因此如果需要查询一张非常大的表的时候,效率很低.

mysql> select * from employees limit 90000,5;
查询90000条后面的数据,没有额外的排序和分组.可以优化为
select * from table where id > 90000 limit 5
先查询到大于当前id的值,然后获取后面的5条,id使用了连续的主键ID,所以查询效率很高
改写后的 SQL 走了索引，而且扫描的行数大大减少，执行效率更高。

注意:如果主键不连续，不能使用上面描述的优化方法。

另外如果原 SQL 是 order by 非主键的字段，按照上面说的方法改写会导致两条 SQL 的结果不一致。所以这种改写得满足以下两个条件：

• 主键连续自增且连续
• 结果是按照主键排序

根据非主键字段排序的分页查询

select * from employees ORDER BY name limit 90000,5;
可以看到是使用了文件排序的方式,没有走索引,
可能是因为扫描整个索引并查找到没有索引的行(可能需要遍历多个索引树),
的成本比扫描全表的成本更高(cost成本),所以优化器放弃使用索引

知道不走索引的原因,那么怎么优化呢?

其实关键是让排序时返回的字段尽可能的少,所以可以让排序和分页操作先查出主键,然后根据主键查询对应的记录

select * from table1 e inner join (select id from table order by name limit 90000,5) ed e.id = e.id
语法说明: 先查询出后面5个的id,然后通过id内联到外面查询的表,这样第一个表虽然需要查询90005条数据,然后获取到的5个id关联到了外表,数据量较小,所以还是可以使用索引查询

原 SQL 使用的是 filesort 排序，而优化后的 SQL 使用的是索引排序。

JOIN 关联查询优化

-- 示例表：
CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

create table t2 like t1;

-- 插入一些示例数据
-- 往t1表插入1万行记录
drop procedure if exists insert_t1; 
delimiter ;;
create procedure insert_t1()        
begin
  declare i int;                    
  set i=1;                          
  while(i<=10000)do                 
    insert into t1(a,b) values(i,i);  
    set i=i+1;                       
  end while;
end;;
delimiter ;
call insert_t1();

-- 往t2表插入100行记录
drop procedure if exists insert_t2; 
delimiter ;;
create procedure insert_t2()        
begin
  declare i int;                    
  set i=1;                          
  while(i<=100)do                 
    insert into t2(a,b) values(i,i);  
    set i=i+1;                       
  end while;
end;;
delimiter ;
call insert_t2();

MySql的表关联常见的两种算法

• Nested-Loop Join 算法
• Block Nested-Loop Join 算法

嵌套循环链接 Nested-Loop Join(NLJ)算法

算法说明:一行一行的从第一张表(俗称驱动表)中读取行,然后在这行数据中取到关联字段,根据关联字段在另一张表(被驱动表)去除满足条件的行,然后取出这两张表的结果合集

Explain select t1.* from t1 inner join t2 on t1.id = t2.id

从上面的执行计划中可以看出

• 驱动表是t2,被驱动表是t1,因为驱动表先执行(执行计划的id如果一致的话,那么就会按照从上到下的顺序执行sql),优化器一般会选择小表作为驱动表,用where条件过滤完驱动表,然后在跟被驱动表做关联查询,所以在使用inner join 的时候,左排在前面的表并不一定就是驱动表
• 当使用 left join时,左表是驱动表,当使用right join 时右表是驱动表,左表是被驱动表,当使用 join时,mysql会选择额数据量较小的表作为驱动表,大表做为被驱动表
• 使用了NLJ算法,一般join语句中,如果执行计划extra中未出现Using join buffer标识使用的join算法是NLJ

上面的sql的大致流程如下

• 从T2表中获取过滤完成的数据
• 获取T2表关联的字段,通过当前字段去T1表中的聚簇索引查询符合条件的数据,
• 取出T1表中的数据,跟T2表中的数据合并,返回给客户端
• 重复上面三个步骤

整个过程会读取T2表中的所有数据,然后遍历每一行数据字段a的值,根据t2表中a的值,去索引扫描t1表中的对应行(扫描100次索引,一次扫描可以认为最终只扫描t1表一行完整的数据,也就是总共t1表也扫描了100行),因此整个过程扫描了200行.

如果关联俩表的关联字段没有索引,那么使用NLJ算法性能会比较低下,mysql会选择Block Nested-Loop Join算法

基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法

把驱动表的数据读取到join_buffer中,然后扫描被驱动表,把驱动表每一行取出来跟join_buffer中的数据进行对比

mysql>EXPLAIN select * from t1 inner join t2 on t1.b= t2.b;

extra中出现Using join buffer就说明使用了 BNL算法

上面的sql流程大致如下

• 将驱动表T2(数据量较小的表会被mysql优化器选择为驱动表)的数据读取到join_buffer
• 将表T1中每一行的数据取出来,跟Join_buffer中的数据做对比
• 返回满足join条件的数据

整个过程中T1表和T2表都需要做全表扫描,因此扫描的数据量是T1表＋T2表的所有数量 10010条数据,并且join_buffer中的数据是无序的,因此对表T1中的每一行都有需要做100次判断,所以内存中的判断此时是100*10000=100w次

这个例子里表 t2 才 100 行，要是表 t2 是一个大表，join_buffer 放不下怎么办呢？·

join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。如果放不下表 t2 的所有数据话，策略很简单，就是分段放。

比如 t2 表有1000行记录， join_buffer 一次只能放800行数据，那么执行过程就是先往 join_buffer 里放800行记录，然后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空 join_buffer ，再放入 t2 表剩余200行记录，再次从 t1 表里取数据跟 join_buffer 中数据对比。所以就多扫了一次 t1 表。

被驱动表的关联字段没有索引,为什么要选择使用BNL算法而不是用NLJ算法呢?

如果上面第二条sql选择的是NLJ算法,那么扫描行为是1000*10000=100w次,这个是磁盘扫描.

很显然,用BNL磁盘扫描次数很少,相比于磁盘扫描,NLJ的内存计算会快很多

对于关联查询的优化

• 关联字段加索引,尽量让mysql做join操作时选择BNL算法,驱动表因为需要全部查询出来,索引过滤条件也尽量走索引,避免全表扫描,总之能做索引的过滤条件就尽量都做索引.
• 小表驱动大表,写多表连接的时候,如果明确知道那张表是小表可以使用straight_join的写法来固定连接驱动方式,省去mysql优化器自己判断的时间.

straight_join:功能桶join类似,但能让左边表驱动右边表,能改变优化器对于链表查询的执行顺序

• 只适用于inner join ,不适合left join和right join
• 尽可能的让优化器自动判断,使用straight_join一定要慎重

对于小表明确的定义:决定那张表为驱动表的时候,是依据两张表过滤完之后的数据,计算两个参与的数量,数据量较小的表为驱动表

COUNRT(*) 优化

mysql> EXPLAIN select count(1) from employees;
mysql> EXPLAIN select count(id) from employees;
mysql> EXPLAIN select count(name) from employees;
mysql> EXPLAIN select count(*) from employees;

四个查询语句的执行计划一样,说明查询的效率是差不多的

分为两种情况

• 有索引情况 count(*) ≈count(1)>count(字段)>count(主键id) ,字段有索引,因为字段存在的是2级索引,2级索引存储的只是字段值和主键ID,主键ID存储的是当前行所有的数据,所以COUNT(ID)会比COUNT(字段慢)

• 没有索引情况 count(*) ≈count(1)>>count(主键id) >count(字段),字段没有索引count(字段)统计走不了索引，count(主键 id)还可以走主键索引，所以count(主键 id)>count(字段)

count(1)和count(字段)的执行过程类似,不过count(1)不需要把字段全部取出来,只需要用常亮1做统计,count(字段)还需要去除字段信息,所以理论上count(1)比count(字段)快一点,

count(*)是一个例外,他不会把全部字段取出来,而是抓们优化,不取值,按行累加,效率很高

为什么对于count(id)，mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高，mysql内部做了点优化

常见优化方法

1、查询mysql自己维护的总行数

对于myisam存储引擎的表做不带where条件的count查询性能是很高的，因为myisam存储引擎的表的总行数会被mysql存储在磁盘上，查询不需要计算

对于innodb存储引擎的表mysql不会存储表的总记录行数(因为有MVCC机制，后面会讲)，查询count需要实时计算

2、show table status

如果只需要知道表总行数的估计值可以用如下sql查询，性能很高
3、将总数维护到Redis里

插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难保证表操作和redis操作的事务一致性

4、增加数据库计数表

插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作

补充：MySQL数据类型选择

在MySQL中，选择正确的数据类型，对于性能至关重要。一般应该遵循下面两步：

（1）确定合适的大类型：数字、字符串、时间、二进制；

（2）确定具体的类型：有无符号、取值范围、变长定长等。

在MySQL数据类型设置方面，尽量用更小的数据类型，因为它们通常有更好的性能，花费更少的硬件资源。并且，尽量把字段定义为NOT NULL，避免使用NULL。

数值类型

类型	大小	范围（有符号）	范围（无符号）	用途
TINYINT	1 字节	(-128, 127)	(0, 255)	小整数值
SMALLINT	2 字节	(-32 768, 32 767)	(0, 65 535)	大整数值
MEDIUMINT	3 字节	(-8 388 608, 8 388 607)	(0, 16 777 215)	大整数值
INT或INTEGER	4 字节	(-2 147 483 648, 2 147 483 647)	(0, 4 294 967 295)	大整数值
BIGINT	8 字节	(-9 233 372 036 854 775 808, 9 223 372 036 854 775 807)	(0, 18 446 744 073 709 551 615)	极大整数值
FLOAT	4 字节	(-3.402 823 466 E+38, 1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38)	0, (1.175 494 351 E-38, 3.402 823 466 E+38)	单精度浮点数值
DOUBLE	8 字节	(1.797 693 134 862 315 7 E+308, 2.225 073 858 507 201 4 E-308), 0, (2.225 073 858 507 201 4 E-308, 1.797 693 134 862 315 7 E+308)	0, (2.225 073 858 507 201 4 E-308, 1.797 693 134 862 315 7 E+308)	双精度浮点数值
DECIMAL	对DECIMAL(M,D) ，如果M>D，为M+2否则为D+2	依赖于M和D的值	依赖于M和D的值	小数值

优化建议

1. 如果整形数据没有负数，如ID号，建议指定为UNSIGNED无符号类型，容量可以扩大一倍。
2. 建议使用TINYINT代替ENUM、BITENUM、SET。
3. 避免使用整数的显示宽度(参看文档最后)，也就是说，不要用INT(10)类似的方法指定字段显示宽度，直接用INT。
4. DECIMAL最适合保存准确度要求高，而且用于计算的数据，比如价格。但是在使用DECIMAL类型的时候，注意长度设置。
5. 建议使用整形类型来运算和存储实数，方法是，实数乘以相应的倍数后再操作。
6. 整数通常是最佳的数据类型，因为它速度快，并且能使用AUTO_INCREMENT。

日期和时间

类型	大小(字节)	范围	格式	用途
DATE	3	1000-01-01 到 9999-12-31	YYYY-MM-DD	日期值
TIME	3	‘-838:59:59’ 到 ‘838:59:59’	HH:MM:SS	时间值或持续时间
YEAR	1	1901 到 2155	YYYY	年份值
DATETIME	8	1000-01-01 00:00:00 到 9999-12-31 23:59:59	YYYY-MM-DD HH:MM:SS	混合日期和时间值
TIMESTAMP	4	1970-01-01 00:00:00 到 2038-01-19 03:14:07	YYYYMMDDhhmmss	混合日期和时间值，时间戳

优化建议

1. MySQL能存储的最小时间粒度为秒。
2. 建议用DATE数据类型来保存日期。MySQL中默认的日期格式是yyyy-mm-dd。
3. 用MySQL的内建类型DATE、TIME、DATETIME来存储时间，而不是使用字符串。
4. 当数据格式为TIMESTAMP和DATETIME时，可以用CURRENT_TIMESTAMP作为默认（MySQL5.6以后），MySQL会自动返回记录插入的确切时间。
5. TIMESTAMP是UTC时间戳，与时区相关。
6. DATETIME的存储格式是一个YYYYMMDD HH:MM:SS的整数，与时区无关，你存了什么，读出来就是什么。
7. 除非有特殊需求，一般的公司建议使用TIMESTAMP，它比DATETIME更节约空间，但是像阿里这样的公司一般会用DATETIME，因为不用考虑TIMESTAMP将来的时间上限问题。
8. 有时人们把Unix的时间戳保存为整数值，但是这通常没有任何好处，这种格式处理起来不太方便，我们并不推荐它。

字符串

类型	大小	用途
CHAR	0-255字节	定长字符串，char(n)当插入的字符数不足n时(n代表字符数)，插入空格进行补充保存。在进行检索时，尾部的空格会被去掉。
VARCHAR	0-65535 字节	变长字符串，varchar(n)中的n代表最大字符数，插入的字符数不足n时不会补充空格
TINYBLOB	0-255字节	不超过 255 个字符的二进制字符串
TINYTEXT	0-255字节	短文本字符串
BLOB	0-65 535字节	二进制形式的长文本数据
TEXT	0-65 535字节	长文本数据
MEDIUMBLOB	0-16 777 215字节	二进制形式的中等长度文本数据
MEDIUMTEXT	0-16 777 215字节	中等长度文本数据
LONGBLOB	0-4 294 967 295字节	二进制形式的极大文本数据
LONGTEXT	0-4 294 967 295字节	极大文本数据

优化建议

1. 字符串的长度相差较大用VARCHAR；字符串短，且所有值都接近一个长度用CHAR。
2. CHAR和VARCHAR适用于包括人名、邮政编码、电话号码和不超过255个字符长度的任意字母数字组合。那些要用来计算的数字不要用VARCHAR类型保存，因为可能会导致一些与计算相关的问题。换句话说，可能影响到计算的准确性和完整性。
3. 尽量少用BLOB和TEXT，如果实在要用可以考虑将BLOB和TEXT字段单独存一张表，用id关联。
4. BLOB系列存储二进制字符串，与字符集无关。TEXT系列存储非二进制字符串，与字符集相关。
5. BLOB和TEXT都不能有默认值。

PS：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。