MySQL--触发器、索引、存储引擎、事务、锁机制、日志、优化_序列 触发器 索引

1 MySQL触发器

概述：

• 触发器，就是一种特殊的存储过程。触发器和存储过程一样是一个能够完成特定功能、存储在数据库服务器上的SQL片段，但是触发器无需调用，当对数据库表中的数据执行DML操作时自动触发这个SQL片段的执行，无需手动调用。
• 在MySQL中，只有执行insert,delete,update操作时才能触发触发器的执行。
• 触发器的这种特性可以协助应用在数据库端确保数据的完整性 , 日志记录 ,数据校验等操作。
• 使用别名 OLD 和 NEW来引用触发器中发生变化的记录内容，这与其他的数据库是相似的。现在触发器还只支持行级触发，不支持语句级触发。

特性：

• 什么条件会触发：I、D、U
• 什么时候触发：在增删改前或者后
• 触发频率：针对每一行执行
• 触发器定义在表上，附着在表上

注意事项：

• MYSQL中触发器中不能对本表进行 insert ,update ,delete 操作，以免递归循环触发
• 尽量少使用触发器，假设触发器触发每次执行1s，inserttable 500条数据，那么就需要触发500次触发器，光是触发器执行的时间就花费了500s，而insert 500条数据一共是1s，那么这个insert的效率就非常低了。
• 触发器是针对每一行的；对增删改非常频繁的表上切记不要使用触发器，因为它会非常消耗资源。

1.1 创建触发器

格式：

• 创建只有一个执行语句的触发器

create trigger 触发器名 before|after 触发事件
on 表名 for each row 
执行语句;
1
2
3

• 创建有多个执行语句的触发器

create trigger 触发器名 before|after  触发事件 
on 表名 for each row
begin
     执行语句列表
end;
1
2
3
4
5

示例：

-- 方式1创建触发器trigger_test1
create trigger trigger_test1
after insert on user -- 触发时机：当添加user表数据时触发
for each row
insert into user_logs values(NULL,now(), '有新用户注册');
 
-- 添加数据，触发器自动执行并添加日志代码
insert into user values(1,'张三','123456');

--方式2创建有多个执行语句的触发器 
delimiter $$
create trigger trigger_test2
after update on user  -- 触发时机：当修改user表数据时触发
for each row -- 每一行
begin
insert into user_logs values(NULL,now(), '用户修改发生了修改');
end $$
 
delimiter ;
 
-- 添加数据，触发器自动执行并添加日志代码
update user set password = 'xxxxx' where uid = 1;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

1.2 NEW、OLD

概述：MySQL中定义了 NEW和 OLD，用来表示触发器的所在表中，触发了触发器的哪一行数据，来引用触发器中发生变化的记录内容，具体地：

使用方式：NEW.columnName （columnName为相应数据表某一列名）

示例：

create trigger trigger_test3 after insert
on user for each row
insert into user_logs values(NULL,now(),concat('有新用户添加，信息为:',NEW.uid,NEW.username,NEW.password));
 
-- 测试
insert into user values(4,'赵六','123456');
1
2
3
4
5
6

1.3 查看触发器

show triggers;

1.4 删除触发器

drop trigger [if exists] trigger_name

示例：drop trigger if exists trigger_test1;

2 MySQL索引

概述：索引是通过某种算法，构建出一个数据模型，用于快速找出在某个列中有一特定值的行，不使用索引，MySQL必须从第一条记录开始读完整个表，直到找出相关的行，表越大，查询数据所花费的时间就越多，如果表中查询的列有一个索引，MySQL能够快速到达一个位置去搜索数据文件，而不必查看所有数据，那么将会节省很大一部分时间。索引类似一本书的目录，比如要查找’student’这个单词，可以先找到s开头的页然后向后查找，这个就类似索引。

优点：

• 大大加快数据的查询速度
• 使用分组和排序进行数据查询时，可以显著减少查询时分组和排序的时间
• 创建唯一索引，能够保证数据库表中每一行数据的唯一性
• 在实现数据的参考完整性方面，可以加速表和表之间的连接

缺点：

• 创建索引和维护索引需要消耗时间，并且随着数据量的增加，时间也会增加
• 索引需要占据磁盘空间
• 对数据表中的数据进行增加，修改，删除时，索引也要动态的维护，降低了维护的速度

创建索引的原则：

• 更新频繁的列不应设置索引
• 数据量小的表不要使用索引（毕竟总共2页的文档，还要目录吗？）
• 重复数据多的字段不应设为索引（比如性别，只有男和女，一般来说：重复的数据超过百分之15就不该建索引）
• 首先应该考虑对where 和 orderby 涉及的列上建立索引

索引是存储引擎用来快速查找记录的一种数据结构

• 按照实现方式分类：主要有Hash索引和B+Tree索引
  

• 按照功能划分，索引划为以下分类：

2.1 查看数据库索引

• 查看数据库所有索引

-- select * from mysql.`innodb_index_stats` a where a.`database_name` = '数据库名’; 
select * from mysql.`innodb_index_stats` a where a.`database_name` = 'mydb5';
1
2

• 查看表中所有索引

-- select * from mysql.`innodb_index_stats` a where a.`database_name` = '数据库名' and a.table_name like '%表名%’; 
select * from mysql.`innodb_index_stats` a where a.`database_name` = 'mydb5' and a.table_name like '%student%';
1
2

• 查看表中所有索引

-- 3、查看表中所有索引 
-- show index from table_name; 
show index from student;
1
2
3

2.2 删除索引

格式：

drop index 索引名 on 表名 
-- 或 
alter table 表名 drop index 索引名 
1
2
3

2.3 单列索引

概述：一个索引只包含单个列，但一个表中可以有多个单列索引。

2.3.1 普通索引

概述：MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值，纯粹为了查询数据更快一点。

创建格式：

• 方式1：在创建表示创建索引

create  table student(
    sid int primary key,
    card_id varchar(20),
    name varchar(20)，
    index index_name(name) -- 给name列创建索引
);
1
2
3
4
5
6

• 方式2：直接创建

create index indexname on tablename(columnname);

create index index_gender on student(gender); 
1

• 方式3：修改表结构(添加索引)

alter table tablename add index indexname(columnname)

alter table student add index index_age(age);
1

2.3.2 唯一索引

概述：唯一索引与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。

创建格式：

• 方式1：创建表的时候直接指定

create  table student2(
    sid int primary key,
    card_id varchar(20),
    name varchar(20),
    score double,
    unique index_card_id(card_id) -- 给card_id列创建索引
);
1
2
3
4
5
6
7

• 方式2：直接创建

-- create unique index 索引名 on 表名(列名) 
create unique index index_card_id on student2(card_id);
1
2

• 方式3：修改表结构(添加索引)

-- alter table 表名 add unique [索引名] (列名)
alter table student2 add unique index_phone_num(phone_num)
1
2

2.3.3 主键索引

概述：每张表一般都会有自己的主键，当我们在创建表时，MySQL会自动在主键列上建立一个索引，这就是主键索引。主键是具有唯一性并且不允许为NULL，所以他是一种特殊的唯一索引。

2.4 组合索引

概述：组合索引也叫复合索引，指的是我们在建立索引的时候使用多个字段，例如同时使用身份证和手机号建立索引，同样的可以建立为普通索引或者是唯一索引。复合索引的使用复合最左原则。

创建格式：

create index indexname on table_name(column1(length),column2(length)); 
1

示例：

-- 创建索引的基本语法-- 普通索引
create index index_phone_name on student(phone_num,name);
-- 创建索引的基本语法-- 唯一索引
create  unique index index_phone_name on student(phone_num,name); 
1
2
3
4

重点：依据以上实例，有四种查询情况

select * from student where name = '张三';----------------------------------------1
select * from student where phone_num = '15100046637';----------------------------2
select * from student where phone_num = '15100046637' and name = '张三';----------3
select * from student where name = '张三' and phone_num = '15100046637';----------4
1
2
3
4

• 1是无法用到索引的，因为复合索引最左原则，必须得有phone_num这个条件。
• 3和4虽然顺序不一样，但是由于mysql本身的sql语句优化，可以识别出是哪个索引，因此3和4在mysql中是一样的。

2.5 全文索引

概述：

• 全文索引的关键字是fulltext
• 全文索引主要用来查找文本中的关键字，而不是直接与索引中的值相比较，它更像是一个搜索引擎，基于相似度的查询，而不是简单的where语句的参数匹配。
• 用 like+ % 就可以实现模糊匹配了，为什么还要全文索引？like+ % 在文本比较少时是合适的，但是对于大量的文本数据检索，是不可想象的。全文索引在大量的数据面前，能比like+ % 快 N 倍，速度不是一个数量级，但是全文索引可能存在精度问题。

全文索引的版本、存储引擎、数据类型的支持情况：

• MySQL5.6 以前的版本，只有 MyISAM 存储引擎支持全文索引；
• MySQL5.6 及以后的版本，MyISAM 和 InnoDB 存储引擎均支持全文索引;
• 只有字段的数据类型为char、varchar、text 及其系列才可以建全文索引；
• 在数据量较大时候，先将数据放入一个没有全局索引的表中，然后再用create index创建fulltext索引，要比先为一张表建立fulltext然后再将数据写入的速度快很多；
• 测试或使用全文索引时，要先看一下自己的 MySQL 版本、存储引擎和数据类型是否支持全文索引。

MySQL 中的全文索引，有两个变量，最小搜索长度和最大搜索长度，对于长度小于最小搜索长度和大于最大搜索长度的词语，都不会被索引。通俗点就是说，想对一个词语使用全文索引搜索，那么这个词语的长度必须在以上两个变量的区间内。这两个的默认值可以使用以下命令查看:

show variables like '%ft%';
1

参数解释：

创建格式：

• 方式1：创建表的时候添加全文索引

create table t_article (
     id int primary key auto_increment ,
     title varchar(255) ,
     content varchar(1000) ,
     writing_date date -- , 
     fulltext (content) -- 创建全文检索
);
1
2
3
4
5
6
7

• 方式2：修改表结构添加全文索引

alter table t_article add fulltext index_content(content)；
1

• 方式3：直接添加全文索引

create fulltext index index_content on t_article(content);
1

使用全文索引：和常用的模糊匹配使用 like + % 不同，全文索引有自己的语法格式，使用match 和 against 关键字，格式：

match (col1,col2,...)  against(expr [search_modifier])
1

select * from t_article where match(content) against('yo’); -- 没有结果 单词数需要大于等于3 
select * from t_article where match(content) against('you'); -- 有结果
1
2

2.6 空间索引

概述：

• MySQL在5.7之后的版本支持了空间索引，而且支持OpenGIS几何数据模型
• 空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。
• MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。
• 创建空间索引的列，必须将其声明为NOTNULL。
• 空间索引一般是用的比较少，了解即可。

空间数据类型：

创建格式：

create table shop_info (
  id  int  primary key auto_increment comment 'id',
  shop_name varchar(64) not null comment '门店名称',
  geom_point geometry not null comment '经纬度’,
  spatial key geom_index(geom_point)
);
1
2
3
4
5
6

2.7 索引的原理

概述：

• 一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。
• 这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。
• 换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。

2.7.1 Hash算法

优点：通过字段的值计算的hash值，定位数据非常快。

缺点：不能进行范围查找，因为散列表中的值是无序的，无法进行大小的比较。

2.7.2 二叉树

特性：分为左子树、右子树和根节点，左子树比根节点值要小，右子树比根节点值要大

缺点：有可能产生不平衡，类似于链表的结构 。

2.7.3 平衡二叉树

特点：

• 它的左子树和右子树都是平衡二叉树

• 左子树比中间小，右子树比中间值大

• 左子树和右子树的深度之差的绝对值不超过1

缺点：

• 插入操作需要旋转

• 支持范围查询，但回旋查询效率较低，比如要查找大于8的，会回旋到父节点7、10。

• 如果存放几百条数据的情况下，树高度越高，查询效率会越慢

2.7.4 BTREE树

概述：目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构，Btree结构可以有效的解决之前的相关算法遇到的问题。

• MyISAM引擎使用B+Tree

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。

• uInnoDB引擎使用B+Tree

InnoDB的叶节点的data域存放的是数据，相比MyISAM效率要高一些，但是比较占硬盘内存大小。

3 MySQL存储引擎

概述：

• 数据库存储引擎是数据库底层软件组织，数据库管理系统（DBMS）使用数据引擎进行创建、查询、更新和删除数据。
• 不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。MySQL的核心就是存储引擎。
• 用户可以根据不同的需求为数据表选择不同的存储引擎
• 可以使用 SHOW ENGINES 命令，可以查看Mysql的所有执行引擎我们可以到默认的执行引擎是innoDB 支持事务，行级锁定和外键。

分类：

• MyISAM：Mysql 5.5之前的默认数据库引擎，最为常用。拥有较高的插入，查询速度，但不支持事务

• InnoDB：事务型速记的首选引擎，支持ACID事务，支持行级锁定，MySQL5.5成为默认数据库引擎

• Memory： 所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在MYSQL重新启动是会丢失。

• Archive ：非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive 拥有高效的插入速度，但其对查询的支持相对较差

• Federated ：将不同的 MySQL 服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用

• CSV ：逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个 .csv 文件。这是一种普通文本文件，每个数据行占用一个文本行。CSV 存储引擎不支持索引。

• BlackHole： 黑洞引擎，写入的任何数据都会消失，一般用于记录binlog 做复制的中继

• ERFORMANCE_SCHEMA存储引擎该引擎主要用于收集数据库服务器性能参数。

• Mrg_Myisam Merge存储引擎，是一组MyIsam的组合，也就是说，他将MyIsam引擎的多个表聚合起来，但是他的内部没有数据，真正的数据依然是MyIsam引擎的表中，但是可以直接进行查询、删除更新等操作。

操作：

-- 查询当前数据库支持的存储引擎：
show engines;
 
-- 查看当前的默认存储引擎：
show variables like ‘%storage_engine%’;

-- 查看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎): 
show create table student; 
 
-- 创建新表时指定存储引擎：
create table(...) engine=MyISAM;
 
-- 修改数据库引擎
alter table student engine = INNODB;
alter table student engine = MyISAM;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

修改MySQL默认存储引擎方法

• 关闭mysql服务
• 找到mysql安装目录下的my.ini文件：
• 找到default-storage-engine=INNODB 改为目标引擎， 如：default-storage-engine=MYISAM
• 启动mysql服务

4 MySQL事务

概述：

• 在MySQL中的事务（Transaction）是由存储引擎实现的，在MySQL中，只有InnoDB存储引擎才支持事务。
• 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
• 事务用来管理 DDL、DML、DCL操作，比如 insert,update,delete 语句，默认是自动提交的。

4.1 事务操作

• 开启事务：Start Transaction

任何一条DML语句(insert、update、delete)执行，标志事务的开启

命令：BEGIN 或START TRANSACTION

• 提交事务：Commit Transaction

成功的结束，将所有的DML语句操作历史记录和底层硬盘数据来一次同步

命令：COMMIT

• 回滚事务：Rollback Transaction

失败的结束，将所有的DML语句操作历史记录全部清空

命令：ROLLBACK

注意：之前的所有SQL操作其实也有事务，只是MySQL自动帮我们完成的，每执行一条SQL时MySQL就帮我们自动提交事务，因此如果想要手动控制事务，则必须关闭MySQL的事务自动提交。在MySQL中直接用SET来改变MySQL的自动提交模式：

set autocommit=0 --禁止自动提交 
set autocommit=1 --开启自动提交 
1
2

示例：

-- 设置MySQL的事务为手动提交(关闭自动提交)
select @@autocommit;
set autocommit = 0;
 
-- 模拟账户转账
-- 开启事务 
begin;
update account set money = money - 200 where name = 'zhangsan';
update account set money = money + 200 where name = 'lisi';
-- 提交事务
commit;
 
 
-- 如果转账中的任何一条出现问题，则回滚事务
rollback;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4.2 事务特性

• 原子性：事务是一个不可分的整体，事务开始后的所有操作，要么全部完成，要么全部不做。
• 一致性：系统从一个正确的状态，迁移到另一个正确的状态。
• 隔离性：每个事务的对象对其他事务的操作对象互相分离，事务提交前对其它事务不可见。
• 持久性：事务一旦提交，则结果是永久性的。

4.3 事务隔离级别

原因：如果一个事务正在操作的数据被另一个事务修改或删除了，最后的执行结果可能无法达到预期。如果没有隔离性还会导致其他问题。

隔离级别：

• 读未提交(Readuncommitted)

  A事务可以读取B未提交事务的数据，最低级别，任何情况都无法保证,会造成脏读。

• 读已提交(Readcommitted)

  A事务要等B事务提交后才能读取到修改后的数据,在此之前只能读取到未修改的数据，可避免脏读的发生，会造成不可重复读。

• 可重复读(Repeatableread)

​ 在A事务读取数据（事务开启）时，B事务对数据进行修改操作，但是A事务不会读取到B事务的修改操作，只有当A事务提交之后，才能读取到修改后的数据。可避免脏读、不可重复读的发生，但是会造成幻读。

• 串行(Serializable)

  是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

补充：

• Mysql的默认隔离级别是Repeatable read。
• 脏读：A事务会读取到B事务还未提交的数据，如果那个事务回滚，就会使读取的那个数据不存在。
• 不可重复读：A读取最开始的数据和B事务提交后的数据出现不一致的情况。
• 幻读：事务在提交前和提交后读取的数据不一致。

示例：

-- 查看隔离级别 
show variables like '%isolation%’; 

-- 设置隔离级别
/*
set session transaction isolation level 级别字符串
级别字符串：read uncommitted、read committed、repeatable read、serializable
*/
-- 设置read uncommitted
set session transaction isolation level read uncommitted;
 
-- 设置read committed
set session transaction isolation level read committed;
 
-- 设置repeatable read
set session transaction isolation level repeatable read;
 
-- 设置serializable
set session transaction isolation level serializable;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

5 MySQL锁机制

概述：

• 锁是计算机协调多个进程或线程并发访问某一资源的机制（避免争抢）。
• 在数据库中，除传统的计算资源（如 CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

分类：

• 从对数据操作的粒度分：

  表锁：操作时，会锁定整个表。

  行锁：操作时，会锁定当前操作行。

• 从对数据操作的类型分：

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

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

锁机制：相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。下表中罗列出了各存储引擎对锁的支持情况：

锁的特性：

• 表级锁：偏向MyISAM存储引擎，开销小，加锁快，不会出现死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低。

• 行级锁：偏向InnoDB存储引擎，开销大，加锁慢，会出现死锁，锁定粒度下，发生锁冲突的概率最低，并发度最高。

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；

而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并查询的应用，如一些在线事务处理（OLTP）系统。

InnoDB 与MyISAM的最大的不同：一是支持事务，二是采用了行级锁。

5.1 MyISAM 表锁

概述：MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用 LOCK TABLE 命令给 MyISAM 表显式加锁。

加读锁 ： lock table table_name read; 

加写锁 ： lock table table_name write；
1
2
3

特点：

• 对MyISAM 表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
• 对MyISAM 表的写操作，则会阻塞其他用户对同一表的读和写操作；

简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁，则既会阻塞读，又会阻塞写。此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主的表的存储引擎的原因。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞。

MyISAM 表创建：

create table `tb_book` (
  `id` int(11) auto_increment,
  `name` varchar(50) default null,
  `publish_time` date default null,
  `status` char(1) default null,
  primary key (`id`)
) engine=myisam default charset=utf8 ;
1
2
3
4
5
6
7

5.2 InnoDB行锁

概述：

InnoDB 实现了以下两种类型的行锁。

• 共享锁（S）：又称为读锁，简称S锁，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
• 排他锁（X）：又称为写锁，简称X锁，排他锁就是不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。

对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；

对于普通SELECT语句，InnoDB不会加任何锁；

给记录集加共享锁或排他锁：

共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 
排他锁（X) ：SELECT * FROM table_name WHERE ... FOR UPDATE
1
2

6 MySQL日志

概述：在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的方方面面，以帮助数据库管理员追踪数据库曾经发生过的各种事件。MySQL也不例外。

分类：错误日志、二进制日志、查询日志、慢查询日志。

6.1 错误日志

概述：

• 错误日志是MySQL 中最重要的日志之一，它记录了当MySQL启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，可以首先查看此日志。
• 该日志是默认开启的， 默认存放目录为 mysql的数据目录,默认的日志文件名为 hostname.err（hostname是主机名）。

查看日志位置指令：

show variables like 'log_error%';
1

6.2 二进制日志

概述：

• 二进制日志（BINLOG）记录了所有的DDL（数据定义语言）语句和DML（数据操纵语言）语句，但是不包括数据查询语句。此日志对于灾难时的数据恢复起着极其重要的作用，MySQL的主从复制，就是通过该binlog实现的。
• 二进制日志，MySQl8.0默认已经开启，低版本的MySQL的需要通过配置文件开启，并配置MySQL日志的格式。
• Windows系统：my.ini Linux系统:my.cnf

配置开启binlog日志， 日志的文件前缀为 mysqlbin -> 生成的文件名如: mysqlbin.000001

log_bin=mysqlbin

配置二进制日志的格式

binlog_format=STATEMENT

日志格式：

• STATEMENT

该日志格式在日志文件中记录的都是SQL语句（statement），每一条对数据进行修改的SQL都会记录在日志文件中，通过Mysql提供的mysqlbinlog工具，可以清晰的查看到每条语句的文本。主从复制的时候，从库（slave）会将日志解析为原文本，并在从库重新执行一次。

• ROW

该日志格式在日志文件中记录的是每一行的数据变更，而不是记录SQL语句。比如，执行SQL语句： update tb_book setstatus=‘1’ , 如果是STATEMENT日志格式，在日志中会记录一行SQL文件；如果是ROW，由于是对全表进行更新，也就是每一行记录都会发生变更，ROW 格式的日志中会记录每一行的数据变更。

• MIXED

混合了STATEMENT 和 ROW两种格式。

示例：

-- 查看MySQL是否开启了binlog日志
show variables like 'log_bin';
 
 
-- 查看binlog日志的格式
show variables like 'binlog_format';
 
-- 查看所有日志
show binlog events;
 
-- 查看最新的日志
show master status;
 
-- 查询指定的binlog日志
show binlog events in 'binlog.000010';
select * from mydb1.emp2;
select count(*) from mydb1.emp2;
update mydb1.emp2 set salary = 8000;

-- 从指定的位置开始,查看指定的Binlog日志
show binlog events in 'binlog.000010' from 156;
 
 
-- 从指定的位置开始,查看指定的Binlog日志,限制查询的条数
show binlog events in 'binlog.000010' from 156 limit 2;
--从指定的位置开始，带有偏移，查看指定的Binlog日志,限制查询的条数
show binlog events in 'binlog.000010' from 666 limit 1, 2;
 
-- 清空所有的 binlog 日志文件
reset master
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

6.3 查询日志

概述：

• 查询日志中记录了客户端的所有操作语句，而二进制日志不包含查询数据的SQL语句。
• 默认情况下， 查询日志是未开启的。如果需要开启查询日志，可以设置以下配置 ：

#该选项用来开启查询日志， 可选值 ： 0 或者 1 ； 0 代表关闭， 1 代表开启

general_log=1

#设置日志的文件名， 如果没有指定， 默认的文件名为 host_name.log

general_log_file=file_name

示例：

-- 查看MySQL是否开启了查询日志
show variables like 'general_log';
 
-- 开启查询日志
set global  general_log=1;
 
select * from mydb1.emp2;
select * from mydb6_view.emp;
 
select count(*) from mydb1.emp2;
select count(*) from mydb6_view.emp;
update mydb1.emp2 set salary = 9000;
1
2
3
4
5
6
7
8
9
10
11
12

6.4 慢查询日志

**概述：**慢查询日志记录了所有执行时间超过参数long_query_time 设置值并且扫描记录数不小于min_examined_row_limit 的所有的SQL语句的日志。long_query_time 默认为10 秒，最小为0，精度可以到微秒。

#该参数用来控制慢查询日志是否开启， 可取值： 1 和0 ，1 代表开启，0 代表关闭

slow_query_log=1

该参数用来指定慢查询日志的文件名

slow_query_log_file=slow_query.log

#该选项用来配置查询的时间限制， 超过这个时间将认为值慢查询， 将需要进行日志记录，默认10s

long_query_time=10

7 MySQL优化

概述：在应用的的开发过程中，由于初期数据量小，开发人员写SQL语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多SQL语句开始逐渐显露出性能问题，对生产的影响也越来越大，此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化。

优化方面：

• 从设计上优化
• 从查询上优化
• 从索引上优化
• 从存储上优化

7.1 查看sql执行频率

概述：MySQL客户端连接成功后，通过 show [session|global] status 命令可以查看服务器状态信息。通过查看状态信息可以查看对当前数据库的主要操作类型。

--下面的命令显示了当前 session 中所有统计参数的值
show session status like 'Com_______';  -- 查看当前会话统计结果
show global  status  like 'Com_______';  -- 查看自数据库上次启动至今统计结果
 
show status like 'Innodb_rows_%’;       -- 查看针对Innodb引擎的统计结果
1
2
3
4
5

7.2 定位低效率执行SQL

慢查询日志 :通过慢查询日志定位那些执行效率较低的 SQL 语句。

-- 查看慢日志配置信息 
show variables like '%slow_query_log%’; 

-- 开启慢日志查询 
set global slow_query_log=1; 

-- 查看慢日志记录SQL的最低阈值时间 
show variables like 'long_query_time%’; 

-- 修改慢日志记录SQL的最低阈值时间 
set global long_query_time=4;
1
2
3
4
5
6
7
8
9
10
11

showprocesslist：该命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看SQL 的执行情况，同时对一些锁表操作进行优化。

show processlist; 
1

结果解释：

1） id列，用户登录mysql时，系统分配的"connection_id"，可以使用函数connection_id()查看

2） user列，显示当前用户。如果不是root，这个命令就只显示用户权限范围的sql语句

3） host列，显示这个语句是从哪个ip的哪个端口上发的，可以用来跟踪出现问题语句的用户

4） db列，显示这个进程目前连接的是哪个数据库

5） command列，显示当前连接的执行的命令，一般取值为休眠（sleep），查询（query），连接（connect）等

6） time列，显示这个状态持续的时间，单位是秒

7） state列，显示使用当前连接的sql语句的状态，很重要的列。state描述的是语句执行中的某一个状态。一个sql语句，以查询为例，可能需要经过copyingto tmptable、sortingresult、sendingdata等状态才可以完成

8） info列，显示这个sql语句，是判断问题语句的一个重要依据

7.3 explain执行计划

概述：通过以上步骤查询到效率低的SQL 语句后，可以通过 EXPLAIN命令获取 MySQL如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。

格式：explain 查询语句（select）

字段：

字段解释：

• id 表示操作表的顺序

id 相同表示加载表的顺序是从上到下。

explain select * from user u, user_role ur, role r where u.uid = ur.uid and ur.rid = r.rid ;
1

id 不同id值越大，优先级越高，越先被执行。

explain select * from role where rid = (select rid from user_role where uid = (select uid from user where uname = '张飞'))
1

id 有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。

explain select * from role r , (select * from user_role ur where ur.uid = (select uid from user where uname = '张飞')) t where r.rid = t.rid ; 
1

• select_type：表示查询类型

• type：表示连接类型

结果值从最好到最坏依次是：system>const > eq_ref > ref > range > index > ALL

• table：显示这一步所访问数据库中表名称有时不是真实的表名字，可能是简称

• rows：扫描行的数量

• possible_keys：显示可能应用在这张表的索引，一个或多个

• key：实际使用的索引，如果为NULL， 则没有使用索引

• key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下， 长度越短越好

• extra：其他的额外的执行计划信息，在该列展示

7.4 ushow profile分析SQL

概述：Mysql从5.0.37版本开始增加了对 show profiles 和 show profile 语句的支持。show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

使用说明：

• 通过 have_profiling参数，能够看到当前MySQL是否支持profile：

select @@have_profiling; 
set profiling=1; -- 开启profiling 开关
1
2

• 通过show profile for query query_id 语句可以查看到该SQL执行过程中每个线程的状态和消耗的时间：

show profile for query 8;
1

• 在获取到最消耗时间的线程状态后，MySQL支持进一步选择all、cpu、block io 、context switch、page、faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如，选择查看CPU的耗费时间

show profile cpu for query 133;  
1

7.5 trace分析优化器执行计划

概述：MySQL5.6提供了对SQL的跟踪trace,通过trace文件能够进一步了解为什么优化器选择A计划, 而不是选择B计划

使用说明：

• 打开trace ，设置格式为 JSON，并设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace="enabled=on",end_markers_in_json=on; 
set optimizer_trace_max_mem_size=1000000;
1
2

最后， 检查information_schema.optimizer_trace就可以知道MySQL是如何执行SQL的 ：

select * from information_schema.optimizer_trace\G;
1

7.6 索引优化：

概述：索引是数据库优化最常用也是最重要的手段之一, 通过索引通常可以帮助用户解决大多数的MySQL的性能优化问题。

避免索引失效的优化方法：

• 对于组合索引，通过全值匹配的方式来优化—设置的哪几个列为索引，查询时就将这几个列的条件都写上。

• 对于组合索引，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。意思是必须得写设置的的组合索引列里面最前面设置的那个列。

• 其他原则：

-- 1、范围查询右边的列，不能使用索引 。
-- 根据前面的两个字段name ， status 查询是走索引的， 但是最后一个条件address 没有用到索引。
explain select * from tb_seller where name='小米科技' and status >'1' and address='北京市';
 
-- 2、不要在索引列上进行运算操作， 索引将失效。
explain select * from tb_seller where substring(name,3,2)='科技'
 
-- 3、字符串不加单引号，造成索引失效。 
explain select * from tb_seller where name='小米科技' and status = 1 ;
 
-- 4、尽量使用覆盖索引，避免select *
-- 需要从原表及磁盘上读取数据
explain select * from tb_seller where name='小米科技'  and address='北京市';  -- 效率低
 
-- 从索引树中就可以查询到所有数据
explain select name from tb_seller where name='小米科技'  and address='北京市';  -- 效率高
explain select name,status,address from tb_seller where name='小米科技'  and address='北京市';  -- 效率高
-- 如果查询列，超出索引列，也会降低性能。
explain select name,status,address,password from tb_seller where name='小米科技'  and address='北京市';  -- 效率低

-- 用or分割开的条件， 那么涉及的索引都不会被用到。
explain select * from tb_seller where name='黑马程序员' or createtime = '2088-01-01 12:00:00'; 
explain select * from tb_seller where name='黑马程序员' or address = '西安市';  
explain select * from tb_seller where name='黑马程序员' or status = '1';   
 
-- 以%开头的Like模糊查询，索引失效。
explain select * from tb_seller where name like '科技%'; -- 用索引
explain select * from tb_seller where name like '%科技'; -- 不用索引
explain select * from tb_seller where name like '%科技%';-- 不用索引
-- 弥补不足,不用*，使用索引列
explain select name from tb_seller where name like '%科技%';

--  1、如果MySQL评估使用索引比全表更慢，则不使用索引。
  -- 这种情况是由数据本身的特点来决定的
create index index_address on tb_seller(address);
 
explain select * from tb_seller where address = '北京市'; -- 没有使用索引
explain select * from tb_seller where address = '西安市'; -- 没有使用索引
 
 
--  2、is  NULL ， is NOT NULL  有时有效，有时索引失效。
create index index_address on tb_seller(nickname);
explain select * from tb_seller where nickname is NULL;  -- 索引有效
explain select * from tb_seller where nickname is not NULL; -- 无效
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

7.7 SQL优化

7.7.1 大批量插入数据

概述：当使用load命令导入数据的时候，适当的设置可以提高导入的效率。

对于 InnoDB 类型的表，有以下几种方式可以提高导入的效率：

• 主键顺序插入

  因为InnoDB类型的表是按照主键的顺序保存的，所以将导入的数据按照主键的顺序排列，可以有效的提高导入数据的效率。如果InnoDB表没有主键，那么系统会自动默认创建一个内部列作为主键，所以如果可以给表创建一个主键，将可以利用这点，来提高导入数据的效率。

本地文件导入表的方法：

-- 1、首先，检查一个全局系统变量 'local_infile' 的状态， 如果得到如下显示 Value=OFF，则说明这是不可用的
show global variables like 'local_infile';
 
-- 2、修改local_infile值为on，开启local_infile
set global local_infile=1;
 
-- 3、加载数据 
load data local infile 'D:\\sql_data\\sql1.log' into table tb_user fields terminated by ',' lines terminated by '\n';

1
2
3
4
5
6
7
8
9

• 关闭唯一性校验

  在导入数据前执行 SETUNIQUE_CHECKS=0，关闭唯一性校验，在导入结束后执行SET UNIQUE_CHECKS=1，恢复唯一性校验，可以提高导入的效率。

7.7.2 优化insert语句

• 原始方式

insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');s
insert into tb_test values(3,'Jerry');
1
2
3

• 合并版

insert into tb_test values(1,'Tom'),(2,'Cat')，(3,'Jerry');
1

• 在事务中进行数据插入

begin;
insertinto tb_testvalues(1,'Tom');
insertinto tb_testvalues(2,'Cat');
insertinto tb_testvalues(3,'Jerry');
commit;
1
2
3
4
5

• 数据按照主键有序插入

7.7.3 优化order by

排序方式：

• 第一种是通过对返回数据进行排序，也就是通常说的 filesort 排序，所有不是通过索引直接返回排序结果的排序都叫FileSort 排序。
• 第二种通过有序索引顺序扫描直接返回有序数据，这种情况即为 usingindex，不需要额外排序，操作效率高。

Filesort 的优化：

通过创建合适的索引，能够减少Filesort 的出现，但是在某些情况下，条件限制不能让Filesort消失，那就需要加快 Filesort的排序操作。对于Filesort ， MySQL有两种排序算法：

1） 两次扫描算法 ：MySQL4.1 之前，使用该方式排序。首先根据条件取出排序字段和行指针信息，然后在排序区sort buffer 中排序，如果sort buffer不够，则在临时表 temporary table 中存储排序结果。完成排序之后，再根据行指针回表读取记录，该操作可能会导致大量随机I/O操作。

2）一次扫描算法：一次性取出满足条件的所有字段，然后在排序区 sort buffer 中排序后直接输出结果集。排序时内存开销较大，但是排序效率比两次扫描算法要高。

MySQL通过比较系统变量 max_length_for_sort_data的大小和Query语句取出的字段总大小， 来判定是否那种排序算法，如果max_length_for_sort_data 更大，那么使用第二种优化之后的算法；否则使用第一种。

可以适当提高sort_buffer_size 和 max_length_for_sort_data 系统变量，来增大排序区的大小，提高排序的效率。

7.7.4 优化group by

概述：都于GROUP BY 实际上也同样会进行排序操作，而且与ORDER BY 相比，GROUP BY主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与ORDER BY 一样也可以利用到索引。

如果查询包含group by 但是用户想要避免排序结果的消耗， 则可以执行order by null 禁止排序。如下 ：

drop index idx_emp_age_salary on emp; 
explain select age,count(*) from emp group by age;
explain select age,count(*) from emp group by age order by null;
create index idx_emp_age_salary on emp(age,salary)；
1
2
3
4

7.7.5 优化子查询

概述：使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询是可以被更高效的连接（JOIN）替代。

示例：

explain select * from user where uid in (select uid from user_role ); 
--优化后
explain select * from user u , user_role ur where u.uid = ur.uid;
1
2
3

连接(Join)查询之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上需要两个步骤的查询工作。

7.7.6 优化limit查询

概述：一般分页查询时，通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是
limit 900000,10 ，此时需要MySQL排序前900010 记录，仅仅返回900000~900010的记录，其他记录丢弃，查询排序的代价非常大 。

优化：

方式一：在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。

方式二：该方案适用于主键自增的表，可以把Limit查询转换成某个位置的查询 。

可以适当提高sort_buffer_size 和 max_length_for_sort_data 系统变量，来增大排序区的大小，提高排序的效率。

7.7.4 优化group by

概述：都于GROUP BY 实际上也同样会进行排序操作，而且与ORDER BY 相比，GROUP BY主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与ORDER BY 一样也可以利用到索引。

如果查询包含group by 但是用户想要避免排序结果的消耗， 则可以执行order by null 禁止排序。如下 ：

drop index idx_emp_age_salary on emp; 
explain select age,count(*) from emp group by age;
explain select age,count(*) from emp group by age order by null;
create index idx_emp_age_salary on emp(age,salary)；
1
2
3
4

7.7.5 优化子查询

概述：使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询是可以被更高效的连接（JOIN）替代。

示例：

explain select * from user where uid in (select uid from user_role ); 
--优化后
explain select * from user u , user_role ur where u.uid = ur.uid;
1
2
3

连接(Join)查询之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上需要两个步骤的查询工作。

7.7.6 优化limit查询

概述：一般分页查询时，通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是
limit 900000,10 ，此时需要MySQL排序前900010 记录，仅仅返回900000~900010的记录，其他记录丢弃，查询排序的代价非常大 。

优化：

方式一：在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。

方式二：该方案适用于主键自增的表，可以把Limit查询转换成某个位置的查询 。