Mysql索引优化实战二

目录

分页查询优化详解

常见的分页场景优化技巧

根据自增且连续的主键排序的分页查询

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

表JOIN关联原理详解及优化

mysql的表关联常见有两种算法

嵌套循环连接Nested-Loop Join 算法

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

对于关联sql的优化

in和exsits优化

表COUNT查询优化

常见优化方式

查询mysql自己维护的总行数

show table status

将总数维护到Redis里

增加数据库计数表

阿里巴巴MYSQL规范解读

索引规约

SQL语句

MYSQL数据类型选择分析

数值类型

优化建议

日期和时间

优化建议

字符串 

优化建议

ps:INT显示宽度

---

分页查询优化详解

很多时候我们业务系统实现分页功能可能会用如下sql实现

mysql> select * from employees limit 10000, 10;

• 表示从表empoyes中取出从10001行开始的10行记录。看似只查询了10条记录，实际这条SQL是先渎取1010条记录，然后抛弃前1000条记录，然后读到后面10条想要的数据。因此要查询一张大表比较靠后的数据，执行效率是非常低的。

常见的分页场景优化技巧

根据自增且连续的主键排序的分页查询

• 根据自增且连续的主键排序的分页查询的例子 

 

• 该SQL表示查询从第90001开始的五行数据,表示通过主键排序.因为主键是自增并且连续的,所以可以改写成按照主键去查询从90001开始的五行数据 

 

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

 

• 使用explain

• 发现并没有使用name字段的索引(key字段对应的值为null),原因:扫描整个索引树并查找到索引行(可能要遍历多个索引树)的成本比扫描全表的成本高,所以优化器放弃使用索引

  • 如何优化:关键是让排序时返回的字段尽可能少,所以可以让排序和分页操作先查出主键,然后根据主键查到对应的记录,SQL改写如下:

• 由sql执行看出:id为2的先执行,使用了覆盖索引并且排序字段是联合索引的第一个,从而使用索引树的排序

• 对id为1的sql的临时表进行全表扫描

• 因为id为1的sql的连接字段是主键,只能返回一对一所以执行类型是eq_ref

• 效率比直接进行分页的时间少了一半

表JOIN关联原理详解及优化

mysql的表关联常见有两种算法

• Nested-Loop Join 算法

• Block Nested-Loop Join算法

嵌套循环连接Nested-Loop Join 算法

• 一次一行循环的从第一张表(称为驱动表)中读取行,在这行数据中取到关联字段,根据关联字段在另一张表(被驱动表)里取出满足条件的行,然后取出两张表的结果集

• 从执行计划可以看出

  • 驱动表是t2,被驱动表是t1,先执行的是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql);优化器一般会优先选择小表做驱动表,所以使用inner join时,排在前面的表并不一定是驱动表

  • 使用left join时,左表是驱动表,右表是被驱动表;使用right join时,右表是驱动表,左表是被驱动表;当使用join时,mysql会选择数据量小的作为驱动表,大表作为被驱动表

  • 使用了Nested-Loop Join 算法,一般join语句中,如果执行计划Extra中未出现Using join buffer则表示使用join算法是NLJ

• sql的大致执行流程

  • 从t2中读取一行数据(如果t2表中有查询过滤条件,会从过滤结果中取出一行数据)

  • 从第一步的数据中,去除关联字段a,到表t1中查找

  • 取出t1表中满足条件的行,跟t2表中回去到的结果合并,作为结果返回给客户端

  • 重复上面步骤

• 整个过程会读取t2表中的所有数据(100行),然后遍历每行数据中字段a的值,根据t2表中a的值索引扫描t1表中的对应行(扫描100次t1表的索引,1次扫描可以任务最终只扫描t1表一行完整数据,也就是总共t1表也扫描了100行,因此整个过程扫描了200行);如果被驱动表的关联字段没索引,使用Nested-Loop Join算法性能会比较低,mysql会选择Block Nested-Loop Join算法

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

• 注意b字段不是主键字段

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

  • Extra中的Using join buffer(Block Nested Loop)说明该关联查询使用的是Block Nested-Loop Join算法

• 上面sql的大致流程如下

  • 把t2的所有数据加入到join_buffer中

  • 把表t1中每一行取出来,跟join_buffer中的数据做对比

  • 返回满足join条件的数据

• 整个过程对表t1和t2都做了一次全表扫描,因此扫描的总行数为10000(t1行数)+100(t2行数)=10100.并且join_buffer里的数据是无序的,因此对表t1的每一行,都要做100此判断,所以内存中的判断次数为100*10000=100万次,这个例子里t2才100行,要是t2也是一个大表,join_buffer放不下怎么办

  • join_buffer的大小是由join_buffer_buffer设定的,默认值是256k,如果放不下t2的所有数据的话,会分段放

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

• 被驱动表的关联字段没索引为什么要选择使用BNL算法而不使用Nested-Loop Join呢?

  • 如果上面第二条sql使用Nested-Loop Join，那么扫描行数为100*10000 = 100万次，这个是磁盘扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。

  • 因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用BNL算法。如果有索引一般选择NLJ算法，有索引的情况下NJ算法比BNL算法性能更高

对于关联sql的优化

• 关联字段加索引,让mysq|做join操作时尽量选择NLJ算法

• 小表驱动大表,写多表连接sq时如果明确知道哪张表是小表可以用straight join写法固定连接驱动方式， 省去mysq|优化器自己判断的时间

  • straight join解释: straight join功能同join类似，但能让左边的表来驱动右边的表,能改表优化器对于联表查询的执行顺序。比如: select * from t2 straight join t1 on t2.a = t1.a;代表指定mysql选着t2表作为驱动表。

  • straight join只适用于inner join,并不适用于left join, right join。(因为left join, right join已经代表指定了表的执行顺序)

  • 尽可能让优化器去判断，因为大部分情况mysql优化器是比人要聪明的。使用straight join-定要慎重，因为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

• 对于小表定义的明确

  • 在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤,过滤完成之后，计算参与join的各个字段的总数据量,数据量小的那个表，就是“小表”，应该作为驱动表。

in和exsits优化

原则:小表驱动大表,即小的数据集驱动大的数据集

• in:当B表的数据集小于A表的数据集时，in优于exists

select * from A where id in (select id from B)
#等价于:
for(select id from B){
    select from A where A.id = B.id
}

• exists:当A表的数据集小于B表的数据集时，exists优于in,将主查询A的数据，放到子查询B中做条件验证，根据验证结果(true或false) 来决定主查询的数据是否保留

select * from A where exists (select 1 from B where B.id = A.id)
#等价于:
for(select * from A){
  select * from B where B.id = A.id
}
#A表与B表的ID字段应建立索引

• EXISTS (subquery)只返回TRUE或FALSE,因此子查询中的SELECT *也可以用SELECT 1替换，官方说法是实际执行时会忽略SELECT清单,因此没有区别

• EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比

• EXISTS子查询往往也可以JOIN来代替何种最优需要 具体问题具体分析

表COUNT查询优化

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

• 注意:以上4条sql只有根据某个字段count不会统计字段为null值的数据行

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

• 四个sqI的执行计划-样,说明这四个sq执行效率应该差不多

  • 字段有索引: count(*)≈count(1)>count(字段)>count(主键 id) //字段有索引， count(字段)统计走二级索引，二级索引存储数据比主键索引少,所以count(字段)>count(主键id)

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

  • count(1)跟count(字段)执行过程类似，不过count(1)不需要取出字段统计,就用常量1做统计, count(字段)还需要取出字段放到内存中统计name的个数，所以理论上count(1)比count(字段)会快-点。

  • count(*)是例外, mysql并不会把全部字段取出来,而是专门做了优化,不取值,按行累加,效率很高,所以不需要用count(列名)或count(常量)来替代count( * )

常见优化方式

查询mysql自己维护的总行数

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

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

show table status

• 如果只需要知道表总行数的估计值可以用如下sql查询，性能很高

将总数维护到Redis里

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

增加数据库计数表

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

阿里巴巴MYSQL规范解读

索引规约

• [强制]业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一 索引.

  • 说明:不要以为唯一索引影响了 insert速度,这个速度损耗可以忽略,但提高查找速度是明显的;另外,即使在应用层做了非常完善的校验控制,只要没有唯一索引,根据墨菲定律,必然有脏数据产生。

• [强制]超过三个表禁止join.需要join的字段,数据类型保持绝对一致;多表关联查询时,保证被关联的字段需要有索引。

  • 说明:即使双表join也要注意表索引、SQL性能。

• [强制]在varchar字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度。

  • 说明:索引|的长度与区分度是一对矛盾体, -般对字符串类型数据,长度为20的索引,区分度会高达90% 以上,可以使用count(distinct left(列名,索引长度))/count( *)的区分度来确定。

• [强制]页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决

  • 说明:索引文件具有B-Tree的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索引。

• [推荐]如果有order by的场景,请注意利用索引的有序性。order by最后的字段是组合索引的一部分,并且放在索引组合顺序的最后,避免出现file_ sort 的情况,影响查询性能。

  • 正例: where a=? and b=? order by c;索引:a_ b. _C

  • 反例:索引如果存在范围查询,那么索引有序性无法利用,如: WHERE a> 10 order by b;索引a_b无 法排序。

• [推荐]利用覆盖索引来进行查询操作,避免回表

  • 说明:如果一本书需要知道第11章是什么标题,会翻开第11章对应的那一页吗?目录浏览一下就好 ,这 个目录就是起到覆盖索引的作用。

  • 正例:能够建立索引的种类分为主键索引、唯一索引、普通索引三种,而覆盖索引只是一种查询的一种效 果，用explain的结果, extra列会出现: using index。

• [推荐 ]利用延迟关联或者子查询优化超多分页场景

  • 说明: MySQL并不是跳过offset行,而是取offset+N行,然后返回放弃前offset行,返回N行,那当offset特别大的时候,效率就非常的低下,要么控制返回的总页数,要么对超过特定阈值的页数进行SQL改写。

    • 正例:先快速定位需要获取的id段,然后再关联: SELECT a.* FROM表1 a, (select id from 表1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

• [推荐] SQL性能优化的目标?至少要达到range 级别,要求是ref级别,如果可以是最好。

  • 说明:

    • consts 单表中最多只有一个匹配行(主键或者唯一 索引) ,在优化阶段即可读取到数据。

    • ref 指的是使用普通的索引( normal index )。

    • range 对索引进行范围检索。

  • 反例: explain表的结果, type=index ,索引物理文件全扫描,速度非常慢,这个index级别此较range 还低,与全表扫描是小巫见大巫。

• [推荐]建组合索引的时候,区分度最高的在最左边。

  • 正例:如果wherea=?a and b=? , a列的几乎接近于唯一值,那么只需要单建idx_ _a 索引即可。

  • 说明:存在非等号和等号混合判断条件时, 在建索引时,请把等号条件的列前置。如: where c>? and d=?那么即使C的区分度更高,也必须把d放在索引的最前列,即建立组合索引idx_ d_ C。

• [推荐]防止因字段类型不同造成的隐式转换,导致索引失效。

• [参考]创建索引时避免有如下极端误解:

  • 索引宁滥勿缺。认为一个查询就需要建一个索引。

  • 吝啬索引的创建。认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度。

  • 抵制惟一 索引。认为惟一 索引- -律需要在应用层通过"先查后插”方式解决。

SQL语句

• [强制] 不要使用count(列名)或count(常量)来替代count( * ) , count(*)是SQL92定义的标准统计行数的语法,跟数据库无关,跟NULL和非NULL无关。

  • 说明: count(*)会统计值为NULL的行,而count(列名)不会统计此列为NULL值的行。

• [强制] count(distinct col)计算该列除NULL之外的不重复行数注意count(distinct col1,col2)如果其中-列全为NULL ,那么即使另一列有不同的值,也返回为0。

• [强制] 当某一列的值全是 NULL时, count(col)的返回结果为0 ,但sum(col)的返回结果为 NULL ,因此使用sum()时需注意NPE问题。

  • 正例:可以使用如下方式来避免sum的NPE问题: SELECT IFNULL(SUM(column), 0) FROM table;

• [ 强制]使用 ISNULL() 来判断是否为NULL值。

  • 说明: NULL与任何值的直接比较都为NULL。

    • NULL<> NULL的返回结果是NULL ,而不是false。

    • NULL=NULL的返回结果是NULL ,而不是true.

    • NULL<>1的返回结果是NULL ,而不是true.

  • 反例:在SQL语句中,如果在null前换行,影响可读性。select * from table where column1 is null and column3 is not null; 而ISNULL(column)是一个整体,简洁易懂。从性能数据上分析,ISNULL(column)执行效率更快些。

• [强制]代码中写分页查询逻辑时,若count为0应直接返回,避免执行后面的分页语句。

• [强制]不得使用外键与级联,一切外键概念必须在应用层解决。

  • 说明: (概念解释)学生表中的student id 是主键,那么成绩表中的student_ id则为外键。如果更新学生表中的student id ,同时触发成绩表中的student id更新,即为级联更新。外键与级联更新适用于单机低并发,不适合分布式、高并发集群;级联更新是强阻塞,存在数据库更新风暴的风险;外键影响数据库的插入速度。

• [强制]禁止使用存储过程,存储过程难以调试和扩展,更没有移植性。

• [强制]数据订正(特别是删除或修改记录操作)时,要先select ,避免出现误删除,确认无误才能执行更新语句。

• [ 强制]对于数据库中表记录的查询和变更,只要涉及多个表,都需要在列名前加表的别名(或表名)进行限定。

  • 说明:对多表进行查询记录、更新记录、删除记录时,如果对操作列没有限定表的别名(或表名) , 并且操作列在多个表中存在时,就会抛异常。

    • 正例: select t1.name from table_ first as t1 , table second as t2 where t1 .id=t2.id;

    • 反例:在某业务中,由于多表关联查询语句没有加表的别名(或表名)的限制,正常运行两年后,最近在 某个表中增加一个同名字段,在预发布环境做数据库变更后,线上查询语句出现出1052异常: Column 'name' in field list is ambiguous。

• [推荐] SQL语句中表的别名前加as ,并且以t1、t2、 t3...的顺序依次命名。

  • 说明:

    • 别名可以是表的简称,或者是根据表出现的顺序，以t1. t2、 t3 的方式命名。

    • 别名前加as 使别名更容易识别。 正例: select t1.name from table_ first as t1, table_ second as t2 where t1.id=t2.id;

• [推荐] in操作能避免则避免,若实在避免不了,需要仔细评估in后边的集合元素数量,控制在1000个之内。

  • in后面的元素太多或者太少都不一定走索引

• [参考]因国际化需要,所有的字符存储与表示,均采用utf8字符集,那么字符计数方法需要注意。

  • 说明:

    • SELECT LENGTH("轻松工作");返回为12

    • SELECT CHARACTER_ LENGTH("轻松工作");返回为4.

    • 如果需要存储表情,那么选择utf8mb4来进行存储,注意它与utf8编码的区别。

• [ 参考] TRUNCATE TABLE 比DELETE 速度快,且使用的系统和事务日志资源少,但TRUNCATE 无事务且不触发trigger ,有可能造成事故,故不建议在开发代码中使用此语句。

  • 说明: TRUNCATE TABLE在功能上与不带WHERE子句的DELETE语句相同。

MYSQL数据类型选择分析

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

• 确定合适的大类型:数字、字符串、时间、二进制;

• 确定具体的类型:有无符号、取值范围、变长定长等。

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

数值类型

优化建议

• 如果整形数据没有负数，如ID号，建议指定为UNSIGNED无符号类型，容量可以扩大- -倍。

• 建议使用TINYINT代替ENUM、BITENUM、 SET。

• 避免使用整数的显示宽度(参看文档最后)，也就是说，不要用INT(10)类似的方法指定字段显示宽度,直接用INT。

• DECIMAL最适合保存准确度要求高，而且用于计算的数据，比如价格。但是在使用DECIMAL类型的时候，注意长度设置。

• 建议使用整形类型来运算和存储实数，方法是,实数乘以相应的倍数后再操作。

• 整数通常是最佳的数据类型,因为它速度快，并且能使用AUTO_ INCREMENT.

日期和时间

优化建议

• MySQL能存储的最小时间粒度为秒。

• 建议用DATE数据类型来保存日期。MySQL 中默认的日期格式是yyy-mm-dd.

• 用MySQL的内建类型DATE、TIME、 DATETIME来存储时间，而不是使用字符串。

• 当数据格式为TIMESTAMP和DATETIME时，可以用CURRENT_TIMES TAMP作为默认(MySQL5.6以后)MySQL会自动返回记录插入的确切时间

• TIMESTAMP是UTC时间戳，与时区相关。|

• DATETIME的存储格式是一个YYYYMMDD HH:MM:SS的整数,与时区无关,你存了什么,读出来就是什么。

• 除非有特殊需求，一般的公司建议使用TIMESTAMP,它比DATETIME更节约空间，但是像阿里这样的公司一般会用DATETIME,因为不用考虑TIMESTAMP将来的时间，上限问题。

• 有时人们把Unix的时间戳保存为整数值,但是这通常没有任何好处，这种格式处理起来不太方便,我们并不推荐它。

字符串 

优化建议

• 字符串的长度相差较大用VARCHAR;字符串短，且所有值都接近一个长度用CHAR。

• CHAR和VARCHAR适用于包括人名、邮政编码、电话号码和不超过255个字符长度的任意字母数字组合。那些要用来计算的数字不要用VARCHAR类 型保存，因为可能会导致一些与计算相关的问题。 换句话说，可能影响到计算的准确性和完整性。

• 尽量少用BLOB和TEXT,如果实在要用可以考虑将BLOB和TEXT字段单独存一张表， 用id关联。

• BLOB系列存储二进制字符串，与字符集无关。TEXT系列存储非二进制字符串，与字符集相关。

• 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。