mysql性能优化专题-mysql

2.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

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());

INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei', 23,'dev',NOW());

INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());

Mysql如何选择合适的索引

mysql> EXPLAIN select * from employees where name > 'a';

如果用name索引需要遍历name字段联合索引树，然后还需要根据遍历出来的主键值去主键索引树里再去查出最终数据，成本比全表扫描还高，可以用覆盖索引优化，这样只需要遍历name字段的联合索引树就能拿到所有结果，如下：

mysql> EXPLAIN select name,age,position from employees where name > 'a' ;

mysql> EXPLAIN select * from employees where name > 'zzz' ;

对于上面这两种 name>'a' 和 name>'zzz' 的执行结果，mysql最终是否选择走索引或者一张表涉及多个索引，mysql最终如何选择索引，我们可以用trace工具来一查究竟，开启trace工具会影响mysql性能，所以只能临时分析sql使用，用完之后立即关闭

trace工具用法：

mysql> set session optimizer_trace="enabled=on",end_markers_in_json=on;  --开启trace

mysql> select * from employees where name > 'a' order by position;

mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;

查看trace字段：

{

  "steps": [

    {

      "join_preparation": {    --第一阶段：SQL准备阶段

        "select#": 1,

        "steps": [

          {

            "expanded_query": "/* select#1 */ select `employees`.`id` AS `id`,`employees`.`name` AS `name`,`employees`.`age` AS `age`,`employees`.`position` AS `position`,`employees`.`hire_time` AS `hire_time` from `employees` where (`employees`.`name` > 'a') order by `employees`.`position`"

          }

        ] /* steps */

      } /* join_preparation */

    },

    {

      "join_optimization": {    --第二阶段：SQL优化阶段

        "select#": 1,

        "steps": [

          {

            "condition_processing": {    --条件处理

              "condition": "WHERE",

              "original_condition": "(`employees`.`name` > 'a')",

              "steps": [

                {

                  "transformation": "equality_propagation",

                  "resulting_condition": "(`employees`.`name` > 'a')"

                },

                {

                  "transformation": "constant_propagation",

                  "resulting_condition": "(`employees`.`name` > 'a')"

                },

                {

                  "transformation": "trivial_condition_removal",

                  "resulting_condition": "(`employees`.`name` > 'a')"

                }

              ] /* steps */

            } /* condition_processing */

          },

          {

            "substitute_generated_columns": {

            } /* substitute_generated_columns */

          },

          {

            "table_dependencies": [    --表依赖详情

              {

                "table": "`employees`",

                "row_may_be_null": false,

                "map_bit": 0,

                "depends_on_map_bits": [

                ] /* depends_on_map_bits */

              }

            ] /* table_dependencies */

          },

          {

            "ref_optimizer_key_uses": [

            ] /* ref_optimizer_key_uses */

          },

          {

            "rows_estimation": [    --预估表的访问成本

              {

                "table": "`employees`",

                "range_analysis": {

                  "table_scan": {     --全表扫描情况

                    "rows": 10123,    --扫描行数

                    "cost": 2054.7    --查询成本

                  } /* table_scan */,

                  "potential_range_indexes": [    --查询可能使用的索引

                    {

                      "index": "PRIMARY",    --主键索引

                      "usable": false,

                      "cause": "not_applicable"

                    },

                    {

                      "index": "idx_name_age_position",    --辅助索引

                      "usable": true,

                      "key_parts": [

                        "name",

                        "age",

                        "position",

                        "id"

                      ] /* key_parts */

                    }

                  ] /* potential_range_indexes */,

                  "setup_range_conditions": [

                  ] /* setup_range_conditions */,

                  "group_index_range": {

                    "chosen": false,

                    "cause": "not_group_by_or_distinct"

                  } /* group_index_range */,

                  "analyzing_range_alternatives": {    --分析各个索引使用成本

                    "range_scan_alternatives": [

                      {

                        "index": "idx_name_age_position",

                        "ranges": [

                          "a < name"      --索引使用范围

                        ] /* ranges */,

                        "index_dives_for_eq_ranges": true,

                        "rowid_ordered": false,    --使用该索引获取的记录是否按照主键排序

                        "using_mrr": false,

                        "index_only": false,       --是否使用覆盖索引

                        "rows": 5061,              --索引扫描行数

                        "cost": 6074.2,            --索引使用成本

                        "chosen": false,           --是否选择该索引

                        "cause": "cost"

                      }

                    ] /* range_scan_alternatives */,

                    "analyzing_roworder_intersect": {

                      "usable": false,

                      "cause": "too_few_roworder_scans"

                    } /* analyzing_roworder_intersect */

                  } /* analyzing_range_alternatives */

                } /* range_analysis */

              }

            ] /* rows_estimation */

          },

          {

            "considered_execution_plans": [

              {

                "plan_prefix": [

                ] /* plan_prefix */,

                "table": "`employees`",

                "best_access_path": {    --最优访问路径

                  "considered_access_paths": [   --最终选择的访问路径

                    {

                      "rows_to_scan": 10123,

                      "access_type": "scan",     --访问类型：为scan，全表扫描

                      "resulting_rows": 10123,

                      "cost": 2052.6,

                      "chosen": true,            --确定选择

                      "use_tmp_table": true

                    }

                  ] /* considered_access_paths */

                } /* best_access_path */,

                "condition_filtering_pct": 100,

                "rows_for_plan": 10123,

                "cost_for_plan": 2052.6,

                "sort_cost": 10123,

                "new_cost_for_plan": 12176,

                "chosen": true

              }

            ] /* considered_execution_plans */

          },

          {

            "attaching_conditions_to_tables": {

              "original_condition": "(`employees`.`name` > 'a')",

              "attached_conditions_computation": [

              ] /* attached_conditions_computation */,

              "attached_conditions_summary": [

                {

                  "table": "`employees`",

                  "attached": "(`employees`.`name` > 'a')"

                }

              ] /* attached_conditions_summary */

            } /* attaching_conditions_to_tables */

          },

          {

            "clause_processing": {

              "clause": "ORDER BY",

              "original_clause": "`employees`.`position`",

              "items": [

                {

                  "item": "`employees`.`position`"

                }

              ] /* items */,

              "resulting_clause_is_simple": true,

              "resulting_clause": "`employees`.`position`"

            } /* clause_processing */

          },

          {

            "reconsidering_access_paths_for_index_ordering": {

              "clause": "ORDER BY",

              "steps": [

              ] /* steps */,

              "index_order_summary": {

                "table": "`employees`",

                "index_provides_order": false,

                "order_direction": "undefined",

                "index": "unknown",

                "plan_changed": false

              } /* index_order_summary */

            } /* reconsidering_access_paths_for_index_ordering */

          },

          {

            "refine_plan": [

              {

                "table": "`employees`"

              }

            ] /* refine_plan */

          }

        ] /* steps */

      } /* join_optimization */

    },

    {

      "join_execution": {    --第三阶段：SQL执行阶段

        "select#": 1,

        "steps": [

        ] /* steps */

      } /* join_execution */

    }

  ] /* steps */

}

结论：全表扫描的成本低于索引扫描，所以mysql最终选择全表扫描

mysql> select * from employees where name > 'zzz' order by position;

mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;

查看trace字段可知索引扫描的成本低于全表扫描，所以mysql最终选择索引扫描

mysql> set session optimizer_trace="enabled=off";    --关闭trace

常见sql深入优化

Order by与Group by优化

Case1：

分析：

利用最左前缀法则：中间字段不能断，因此查询用到了name索引，从key_len=74也能看出，age索引列用在排序过程中，因为Extra字段里没有using filesort

Case 2：

分析：

从explain的执行结果来看：key_len=74，查询使用了name索引，由于用了position进行排序，跳过了age，出现了Using filesort。

Case 3：

分析：

查找只用到索引name，age和position用于排序，无Using filesort。

Case 4：

分析：

和Case 3中explain的执行结果一样，但是出现了Using filesort，因为索引的创建顺序为name,age,position，但是排序的时候age和position颠倒位置了。

Case 5：

分析：

与Case 4对比，在Extra中并未出现Using filesort，因为age为常量，在排序中被优化，所以索引未颠倒，不会出现Using filesort。

Case 6：

分析：

虽然排序的字段列与索引顺序一样，且order by默认升序，这里position desc变成了降序，导致与索引的排序方式不同，从而产生Using filesort。Mysql8以上版本有降序索引可以支持该种查询方式。

Case 7：

分析：

对于排序来说，多个相等条件也是范围查询

Case 8：

可以用覆盖索引优化

优化总结：

1、MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index效率高，filesort效率低。

2、order by满足两种情况会使用Using index。

1) order by语句使用索引最左前列。

2) 使用where子句与order by子句条件列组合满足索引最左前列。

3、尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。

4、如果order by的条件不在索引列上，就会产生Using filesort。

5、能用覆盖索引尽量用覆盖索引

6、group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中的限定条件就不要去having限定了。

Using filesort文件排序原理详解

filesort文件排序方式

• 单路排序：是一次性取出满足条件行的所有字段，然后在sort buffer中进行排序；用trace工具可以看到sort_mode信息里显示< sort_key, additional_fields >或者< sort_key, packed_additional_fields >
• 双路排序（又叫回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行 ID，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段；用trace工具可以看到sort_mode信息里显示< sort_key, rowid >

MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来判断使用哪种排序模式。

• 如果 max_length_for_sort_data 比查询字段的总长度大，那么使用 单路排序模式；
• 如果 max_length_for_sort_data 比查询字段的总长度小，那么使用 双路排序模式。

示例验证下各种排序方式：

查看下这条sql对应trace结果如下(只展示排序部分)：

mysql> set session optimizer_trace="enabled=on",end_markers_in_json=on;  --开启trace

mysql> select * from employees where name = 'zhuge' order by position;

mysql> select * from information_schema.OPTIMIZER_TRACE;

trace排序部分结果：

"join_execution": {    --Sql执行阶段

        "select#": 1,

        "steps": [

          {

            "filesort_information": [

              {

                "direction": "asc",

                "table": "`employees`",

                "field": "position"

              }

            ] /* filesort_information */,

            "filesort_priority_queue_optimization": {

              "usable": false,

              "cause": "not applicable (no LIMIT)"

            } /* filesort_priority_queue_optimization */,

            "filesort_execution": [

            ] /* filesort_execution */,

            "filesort_summary": {                      --文件排序信息

              "rows": 10000,                           --预计扫描行数

              "examined_rows": 10000,                  --参数排序的行

              "number_of_tmp_files": 3,                --使用临时文件的个数，这个值如果为0代表全部使用的sort_buffer内存排序，否则使用的磁盘文件排序

              "sort_buffer_size": 262056,              --排序缓存的大小

              "sort_mode": "<sort_key, packed_additional_fields>"       --排序方式，这里用的单路排序

            } /* filesort_summary */

          }

        ] /* steps */

      } /* join_execution */

mysql> set max_length_for_sort_data = 10;    --employees表所有字段长度总和肯定大于10字节

mysql> select * from employees where name = 'zhuge' order by position;

mysql> select * from information_schema.OPTIMIZER_TRACE;

trace排序部分结果：

"join_execution": {

        "select#": 1,

        "steps": [

          {

            "filesort_information": [

              {

                "direction": "asc",

                "table": "`employees`",

                "field": "position"

              }

            ] /* filesort_information */,

            "filesort_priority_queue_optimization": {

              "usable": false,

              "cause": "not applicable (no LIMIT)"

            } /* filesort_priority_queue_optimization */,

            "filesort_execution": [

            ] /* filesort_execution */,

            "filesort_summary": {

              "rows": 10000,

              "examined_rows": 10000,

              "number_of_tmp_files": 2,

              "sort_buffer_size": 262136,

              "sort_mode": "<sort_key, rowid>"         --排序方式，这里用的双路排序

            } /* filesort_summary */

          }

        ] /* steps */

      } /* join_execution */

mysql> set session optimizer_trace="enabled=off";    --关闭trace

我们先看单路排序的详细过程：

1. 从索引name找到第一个满足 name = ‘zhuge’ 条件的主键 id
2. 根据主键 id 取出整行，取出所有字段的值，存入 sort_buffer 中
3. 从索引name找到下一个满足 name = ‘zhuge’ 条件的主键 id
4. 重复步骤 2、3 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的数据按照字段 position 进行排序
6. 返回结果给客户端

我们再看下双路排序的详细过程：

1. 从索引 name 找到第一个满足 name = ‘zhuge’ 的主键id
2. 根据主键 id 取出整行，把排序字段 position 和主键 id 这两个字段放到 sort buffer 中
3. 从索引 name 取下一个满足 name = ‘zhuge’ 记录的主键 id
4. 重复 3、4 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的字段 position 和主键 id 按照字段 position 进行排序
6. 遍历排序好的 id 和字段 position，按照 id 的值回到原表中取出 所有字段的值返回给客户端

其实对比两个排序模式，单路排序会把所有需要查询的字段都放到 sort buffer 中，而双路排序只会把主键和需要排序的字段放到 sort buffer 中进行排序，然后再通过主键回到原表查询需要的字段。

如果 MySQL 排序内存配置的比较小并且没有条件继续增加了，可以适当把 max_length_for_sort_data 配置小点，让优化器选择使用双路排序算法，可以在sort_buffer 中一次排序更多的行，只是需要再根据主键回到原表取数据。

如果 MySQL 排序内存有条件可以配置比较大，可以适当增大 max_length_for_sort_data 的值，让优化器优先选择全字段排序(单路排序)，把需要的字段放到 sort_buffer 中，这样排序后就会直接从内存里返回查询结果了。

所以，MySQL通过 max_length_for_sort_data 这个参数来控制排序，在不同场景使用不同的排序模式，从而提升排序效率。

注意，如果全部使用sort_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增大sort_buffer(默认1M)，mysql很多参数设置都是做过优化的，不要轻易调整。

3.Mysql索引优化实战二

常见sql深入优化

分页查询优化

示例表：

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

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

drop procedure if exists insert_emp; 

delimiter ;;

create procedure insert_emp()        

begin

  declare i int;                    

  set i=1;                          

  while(i<=100000)do                 

    insert into employees(name,age,position) values(CONCAT('zhuge',i),i,'dev');  

    set i=i+1;                       

  end while;

end;;

delimiter ;

call insert_emp();

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

mysql> select * from employees limit 10000,10;

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

>>常见的分页场景优化技巧：

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

首先来看一个根据自增且连续主键排序的分页查询的例子：

mysql> select * from employees limit 90000,5;

该 SQL 表示查询从第 90001开始的五行数据，没添加单独 order by，表示通过主键排序。我们再看表 employees ，因为主键是自增并且连续的，所以可以改写成按照主键去查询从第 90001开始的五行数据，如下：

mysql> select * from employees where id > 90000 limit 5;

查询的结果是一致的。我们再对比一下执行计划：

mysql> EXPLAIN select * from employees limit 90000,5;

mysql> EXPLAIN select * from employees where id > 90000 limit 5;

显然改写后的 SQL 走了索引，而且扫描的行数大大减少，执行效率更高。

但是，这条 改写的SQL 在很多场景并不实用，因为表中可能某些记录被删后，主键空缺，导致结果不一致，如下图试验所示（先删除一条前面的记录，然后再测试原 SQL 和优化后的 SQL）：

两条 SQL 的结果并不一样，因此，如果主键不连续，不能使用上面描述的优化方法。

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

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

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

再看一个根据非主键字段排序的分页查询，SQL 如下：

mysql> select * from employees ORDER BY name limit 90000,5;

mysql> EXPLAIN select * from employees ORDER BY name limit 90000,5;

发现并没有使用 name 字段的索引（key 字段对应的值为 null），具体原因上节课讲过：扫描整个索引并查找到没索引的行(可能要遍历多个索引树)的成本比扫描全表的成本更高，所以优化器放弃使用索引。

知道不走索引的原因，那么怎么优化呢？

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

mysql> select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;

需要的结果与原 SQL 一致，执行时间减少了一半以上，我们再对比优化前后sql的执行计划：

原 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 AUTO_INCREMENT=10001 DEFAULT CHARSET=utf8;

create table t2 like t1;

往t1表插入1万行记录，往t2表插入100行记录

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

• Nested-Loop Join 算法

• Block Nested-Loop Join 算法

1、 嵌套循环连接 Nested-Loop Join(NLJ) 算法

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

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

从执行计划中可以看到这些信息：

• 驱动表是 t2，被驱动表是 t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会优先选择小表做驱动表。所以使用 inner join 时，排在前面的表并不一定就是驱动表。
• 当使用left join时，左表是驱动表，右表是被驱动表，当使用right join时，右表时驱动表，左表是被驱动表，当使用join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表。
• 使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算法是 NLJ。

上面sql的大致流程如下：

1. 从表 t2 中读取一行数据（如果t2表有查询过滤条件的，会从过滤结果里取出一行数据）；
2. 从第 1 步的数据中，取出关联字段 a，到表 t1 中查找；
3. 取出表 t1 中满足条件的行，跟 t2 中获取到的结果合并，作为结果返回给客户端；
4. 重复上面 3 步。

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

如果被驱动表的关联字段没索引，使用NLJ算法性能会比较低(下面有详细解释)，mysql会选择Block Nested-Loop Join算法。

2、 基于块的嵌套循环连接 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 (Block Nested Loop)说明该关联查询使用的是 BNL 算法。

上面sql的大致流程如下：

1. 把 t2 的所有数据放入到 join_buffer 中
2. 把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比
3. 返回满足 join 条件的数据

整个过程对表 t1 和 t2 都做了一次全表扫描，因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer 里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次。

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

如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。

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

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

对于关联sql的优化

• 关联字段加索引，让mysql做join操作时尽量选择NLJ算法
• 小表驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去mysql优化器自己判断的时间

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一定要慎重，因为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

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字段应建立索引

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

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

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

count(*)查询优化

# 临时关闭mysql查询缓存，为了查看sql多次执行的真实时间

mysql> set global query_cache_size=0;

mysql> set global query_cache_type=0;

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;

四个sql的执行计划一样，说明这四个sql执行效率应该差不多，区别在于根据某个字段count不会统计字段为null值的数据行

count(*) 是例外，mysql并不会把全部字段取出来，而是专门做了优化，不取值，按行累加

count(字段)<count(主键 id)<count(1)≈count(*)

为什么mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高

常见优化方法

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

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

对于innodb存储引擎的表mysql不会存储表的总记录行数，查询count需要实时计算

2、show table status

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

3、将总数维护到Redis里

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

4、增加数据库计数表

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

 

4.深入理解Mysql锁与事务隔离级别

1、锁定义

　　锁是计算机协调多个进程或线程并发访问某一资源的机制。

　　在数据库中，除了传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供需要用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。

2、锁分类

• 从性能上分为乐观锁(用版本对比来实现)和悲观锁
• 从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响

写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁

• 从对数据操作的粒度分，分为表锁和行锁

2.1 表锁

每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；

2.1.1 基本操作

--建表SQL

CREATE TABLE `mylock` (

	`id` INT (11) NOT NULL AUTO_INCREMENT,

	`NAME` VARCHAR (20) DEFAULT NULL,

	PRIMARY KEY (`id`)

) ENGINE = MyISAM DEFAULT CHARSET = utf8;

--插入数据

INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('1', 'a');

INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('2', 'b');

INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('3', 'c');

INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('4', 'd');

• 手动增加表锁

lock table 表名称 read(write),表名称2 read(write);

• 查看表上加过的锁

show open tables;

• 删除表锁

unlock tables;

2.1.2 案例分析(加读锁）

当前session和其他session都可以读该表

当前session中插入或者更新锁定的表都会报错，其他session插入或更新则会等待

2.1.3 案例分析(加写锁）

当前session对该表的增删改查都没有问题，其他session对该表的所有操作被阻塞

2.1.4 案例结论

MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行增删改操作前,会自动给涉及的表加写锁。

1、对MyISAM表的读操作(加读锁) ,不会阻寒其他进程对同一表的读请求,但会阻赛对同一表的写请求。只有当读锁释放后,才会执行其它进程的写操作。

2、对MylSAM表的写操作(加写锁) ,会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进程的读写操作

总结：

简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。

2.2 行锁

每次操作锁住一行数据。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高。

InnoDB与MYISAM的最大不同有两点：

• 支持事务（TRANSACTION）
• 支持行级锁

2.2.1 行锁支持事务

• 事务（Transaction）及其ACID属性

事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。

原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。

一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。

隔离性(Isolation) ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。

持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

• 并发事务处理带来的问题

更新丢失（Lost Update）

　　当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。

脏读（Dirty Reads）

　　一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。

　　一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。

不可重读（Non-Repeatable Reads）

　　一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。

　　一句话：事务A读取到了事务B已经提交的修改数据，不符合隔离性

幻读（Phantom Reads）

　　一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

　　一句话：事务A读取到了事务B提交的新增数据，不符合隔离性

• 事务隔离级别

脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。

同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。

常看当前数据库的事务隔离级别: show variables like 'tx_isolation';

设置事务隔离级别：set tx_isolation='REPEATABLE-READ';

2.2.2 行锁与隔离级别案例分析

CREATE TABLE `account` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `name` varchar(255) DEFAULT NULL,

  `balance` int(11) DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lilei', '450');

INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');

INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lucy', '2400');

1、行锁演示

一个session开启事务更新不提交，另一个session更新同一条记录会阻塞，更新不同记录不会阻塞

　　2、读未提交：

　 （1）打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：

set tx_isolation='read-uncommitted';

　　　　

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

　 （3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

　　　　

（4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

　　　　

（5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成350，居然是400，是不是很奇怪，数据不一致啊，如果你这么想就太天真 了，在应用程序中，我们会用400-50=350，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别

　　3、读已提交

　 （1）打开一个客户端A，并设置当前事务模式为read committed（未提交读），查询表account的所有记录：

set tx_isolation='read-committed';

　　　　

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

　　　　

（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：

　　　　

（4）客户端B的事务提交

　　　　

（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题

　　4、可重复读

　 （1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录

set tx_isolation='repeatable-read';

　　　　

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交

　　　　

（3）在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题

　　　　

（4）在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance没有变成400-50=350，lilei的balance值用的是步骤（2）中的350来算的，所以是300，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。

MVCC机制详解

MVCC主要是为了提高并发的读写性能，不用加锁就能让多个事务并发读写

id     name 	balance		创建事务id	删除事务id	

1	   lilei	450		10		13	

2	   hanmei666	16000		11		空

2	   han666	16000		13		空

对于事务id为12的操作，先查询select * from account(创建了查询快照，记录执行sql这一刻最大的已提交事务id(快照点已提交最大事务id))，对于事务id为13的操作，先删除id=1的记录，然后更新id=2的记录，再提交

对于删除操作，mysql底层会记录好被删除的数据行的删除事务id，对于更新操作mysql底层会新增一行相同数据并记录好对应的创建事务id

在id为12的事务里执行查询操作mysql底层会带上过滤条件，创建事务id <= max(当前事务id(12)，快照点已提交最大事务id），删除事务id> max(当前事务id(12)，快照点已提交最大事务id）

注意：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB 表的语句，事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的

MVCC版本链的实现机制：

（5）重新打开客户端B，插入一条新数据后提交

（6）在客户端A查询表account的所有记录，没有查出新增数据，所以没有出现幻读

(7)验证幻读

在客户端A执行update account set balance=888 where id = 4;能更新成功，再次查询能查到客户端B新增的数据

　　5、串行化

　 （1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：

set tx_isolation='serializable';

mysql> set session transaction isolation level serializable;

Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;

+------+--------+---------+

| id   | name   | balance |

+------+--------+---------+

|    1 | lilei  |   10000 |

|    2 | hanmei |   10000 |

|    3 | lucy   |   10000 |

|    4 | lily   |   10000 |

+------+--------+---------+

4 rows in set (0.00 sec)

（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到。

mysql> set session transaction isolation level serializable;

Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;

Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• Mysql默认级别是repeatable-read，有办法解决幻读问题吗？

间隙锁在某些情况下可以解决幻读问题

要避免幻读可以用间隙锁在Session_1下面执行update account set name = 'zhuge' where id > 18 and id <20;，则其他Session没法在这个范围所包含的间隙里插入或修改任何数据

• 什么是间隙锁？

间隙锁是一个在索引记录之间的间隙上的锁。

• 间隙锁的作用

保证某个间隙内的数据在锁定情况下不会发生任何变化。比如我mysql默认隔离级别下的可重复读（RR）。

当使用唯一索引来搜索唯一行的语句时，不需要间隙锁定。如下面语句的id列有唯一索引，此时只会对id值为10的行使用记录锁。

select * from t where id = 10 for update;// 注意：普通查询是快照读，不需要加锁

如果，上面语句中id列没有建立索引或者是非唯一索引时，则语句会产生间隙锁。

如果，搜索条件里有多个查询条件(即使每个列都有唯一索引)，也是会有间隙锁的。

需要注意的是，当id列上没有索引时，SQL会走聚簇索引的全表扫描进行过滤，由于过滤是在MySQL Server层面进行的。

因此每条记录（无论是否满足条件）都会被加上X锁。但是，为了效率考量，MySQL做了优化，对于不满足条件的记录，

会在判断后放锁，最终持有的，是满足条件的记录上的锁。但是不满足条件的记录上的加锁/放锁动作是不会省略的。

所以在没有索引时，不满足条件的数据行会有加锁又放锁的耗时过程。

• 间隙的范围

根据检索条件向下寻找最靠近检索条件的记录值A作为左区间，向上寻找最靠近检索条件的记录值B作为右区间，即锁定的间隙为（A，B）。

select * from t where number=6;那么间隙锁锁定的间隙为：（5，11），所以你再想插入5到11之间的数就会被阻塞。

更需要你注意的是，当你再执行update t set number = 6 where id = 1也会被阻塞。这是为什么？你想想看，

要保证每次查询number=6的数据行数不变，如果你将另外一条数据修改成了6，岂不会多了一条？所以此时不会允许任何一条数据被修改成6。

• 无索引行锁会升级为表锁：锁主要是加在索引上，如果对非索引字段更新, 行锁可能会变表锁

session1执行：

update account set balance = 800 where name = 'lilei';

session2对该表任一行操作都会阻塞住

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。

• 锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)，例如：select * from test_innodb_lock where a = 2 for update; 这样其他session只能读这行数据，修改则会被阻塞，直到锁定行的session提交

2.2.3 案例结论

　　Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一下，但是在整体并发处理能力方面要远远优于MYISAM的表级锁定的。当系统并发量高的时候，Innodb的整体性能和MYISAM相比就会有比较明显的优势了。

　　但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MYISAM高，甚至可能会更差。

2.2.4 行锁分析

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like'innodb_row_lock%';

对各个状态量的说明如下：

Innodb_row_lock_current_waits: 当前正在等待锁定的数量

Innodb_row_lock_time: 从系统启动到现在锁定总时间长度

Innodb_row_lock_time_avg: 每次等待所花平均时间

Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花时间

Innodb_row_lock_waits:系统启动后到现在总共等待的次数

对于这5个状态变量，比较重要的主要是：

Innodb_row_lock_time_avg （等待平均时长）

Innodb_row_lock_waits （等待总次数）

Innodb_row_lock_time（等待总时长）

尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化计划。

2.2.5 死锁

set tx_isolation='repeatable-read';

Session_1执行：select * from account where id=1 for update;

Session_2执行：select * from account where id=2 for update;

Session_1执行：select * from account where id=2 for update;

Session_2执行：select * from account where id=1 for update;

查看近期死锁日志信息：show engine innodb status\G;

大多数情况mysql可以自动检测死锁并回滚产生死锁的那个事务，但是有些情况mysql没法自动检测死锁

2.2.6 优化建议

• 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
• 合理设计索引，尽量缩小锁的范围
• 尽可能减少检索条件范围，避免间隙锁
• 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
• 尽可能低级别事务隔离