1 存储引擎

1.1 MySQL体系结构

• 存储引擎层：索引是在存储引擎层实现的，因此不同的存储引擎，有不同的索引
• 存储层：存储数据库的相关数据，以及一系列的日志文件等

1.2 存储引擎简介

存储引擎是存储数据、建立索引、更新、查询数据等技术的实现方式。存储引擎是基于表的，而非基于库，因此存储引擎也可以被称为表类型。

-- 查看当前数据库支持的存储引擎
show engines;

默认的存储引擎为InnoDB。

1.3 存储引擎特点

1.3.1 InnoDB

• 介绍

  InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MySQL5.5之后为MySQL默认的存储引擎。

• 特点

  • DML操作遵循事务的ACID原则，支持事务
  • 行级锁，提高事务的并发能力
  • 支持外键foreign key约束，保证数据的完整性和正确性

• 文件

  innoDB引擎的每一张表都会对应一个表空间文件***.ibd，存储该表的表结构、数据和索引

• 逻辑存储结构

1.3.2 MyISAM

① 介绍

MySQL早期的默认存储引擎

② 特点

• 不支持事务，不支持外键
• 支持表锁，但是不支持行锁
• 访问速度比较快

③ 文件

• **.sdi：存储表结构信息
• **.MYD：存储数据
• **.MYI：存储索引

1.3.3 Memory

① 介绍

Memory引擎的表数据是存储在内存中的，由于收到硬件问题，或者断电问题的影响，只能将这些表作为临时表或者缓存使用。

② 特点

• 内存存放
• hash索引[默认]

③ 文件

• **.sdi：存储表结构

1.3.4 三种存储引擎的对比

1.4 存储引擎选择

各种存储引擎适用的场景：

• InnoDB：应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，出具的操作除了插入和查询之外还包含很多的更新和删除
• MyISAM：应用主要以读操作和插入操作为主，只有少量的更新操作和删除操作，并且对事务的完整性和并发性的要求不是很高
• Memory：通常用于临时表以及缓存，Memory的缺陷就是对表的大小有限制，太大的表无法缓存在内存之中，而且无法保证数据的安全性

2 索引

2.1 索引概述

2.1.1 介绍

索引是帮助MySQL高效获取数据的数据结构。在数据结构之外，数据库系统该维护者满足特定查找算法的数据结构，这些数据结构以某种方式引用数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

2.1.2 优缺点

① 优点

• 提高数据的检索效率，降低数据库的IO成本
• 通过索引对数据进行排序，降低数据排序的成本，降低CPU的消耗

② 劣势

• 索引本身也是需要占用空间的
• 索引大大提高了查询效率，同时降低表的更新速度，对表进行增加，删除，更新的时候效率降低

2.2 索引结构

MySQL的索引是在存储引擎层实现的，不同的存储引擎有者不同的结构，主要有：

我们平时所说的索引，在没有特定指明的情况下就是B+树结构的索引。

2.2.1 B树（多路平衡查找树）

2.2.2 B+树

• 所有的元素都会在叶子节点
• 叶子节点形成了一个单项链表

MySQL索引数据结构对经典的B+树做了优化，在原来的B+树上，增加了一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+树，提高区间的访问性能。

2.2.3 哈希索引

哈希索引就是采用哈希算法，将键值换算为新的hash值，映射到对应的槽位上，然后存储在hash表中。

特点

• 只能用于等值匹配，不支持范围查询
• 无法利用索引完成排序操作
• 查询效率比较高，通常只需要一次检索就可以了[不出现哈希碰撞]，效率通常高于B+树

2.2.4 B+树的优势

为什么InnoDB使用B+树索引结构？

• 相较于二叉树，层级更少，搜索效率比较高
• 对于B树，无论是叶子节点还是非叶子结点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，同样要保存大量的数据，只能增加树的高度，导致性能下降

2.3 索引分类

在InnoDB存储引擎中，根据索引的存储形式，可以分为一下两种

• 聚集索引：将数据存储和索引放到一块，索引结构的叶子节点保存了行数据，有且仅有一个
• 二级索引：将数据与索引分开存储，索引结构的叶子结点关联的是对应的主键，可以存在多个

聚集索引选取规则：

• 如果存在主键，主键索引就是聚集索引
• 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引
• 如果没有主键，并且没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

回表查询

2.4 索引语法

2.4.1 创建索引

create [unique|fulltext] index index_name on table_name(index_col_name, ...);
-- 一个索引是可以关联多个字段的
-- 关联一个字段的索引：单列索引
-- 关联多个字段的索引：联合索引

2.4.2 查看索引

show index from table_name;

2.4.3 删除索引

drop index index_name on table_name;

2.5 SQL性能分析

2.5.1 SQL执行频率

MySQL客户端连接成功之后，可以通过show [session|global] status命令可以提供服务器状态信息。通过如下指令可以查看当前增删改查的访问频次：

show global status like 'Com_______';-- 7个下划线

2.5.2 慢查询日志

慢查询日志记录了所有执行时间超过指定参数（long_query_time，默认为10s）的所有sql语句的日志。

MySQL的慢查询日志默认没有开启，需要在MySQL的配置文件中配置如下信息：

# 开启慢查询
slow_query_log=1
long_query_time=2

2.5.3 profile详情

show profiles能够在做sql优化的时候帮助我们了解时间都耗费到哪里去了。通过having_profiling参数能够看到当前MySQL是否支持profile操作。

select @@have_profiling;
-- 开启profiling
set profiling 

2.5.4 explain执行计划

通过explain或者的desc可以获取mysql如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序。

• id：表示查询中操作表的顺序，id值相同的话看，执行顺序从上到下，id值不同，值越大，越先执行
• select_type：表示查询的类型
• type：表示链接类型，性能由好到坏依次是NULL, system, const, eq_ref, ref[非唯一索引], range, index, all
• prossible_key：这张表上可能使用的索引
• key：实际使用的索引
• key_len：使用索引占用的字节数
• rows：执行查询的行数

2.6 索引使用

2.6.1 验证索引效率

2.6.2 最左前缀法则

如果索引引用了多个列【联合索引】，要遵守最左前缀法则。查询从索引的最左列开始，并且不跳过索引中的列。如果跳过某一列，索引将部分失效（后面的字段索引失效）。最左前缀法则和索引出现的位置无关，只和是否出现有关。

2.6.3 范围查询

联合查询中，如果出现范围查询(>, <)，范围查询右侧的索引失效。使用范围查询尽量使用>=的运算。

2.6.4 索引列的运算

不要再索引上进行运算，否则就会出现索引失效的情况。

2.6.5 字符串没有加单引号

字符串没有加单引号会导致索引的失效。

2.6.6 模糊查询

尾部模糊查询，索引不会失效。头部模糊查询，索引一定会失效。

select * from tb_user where profession like '软件%';

2.6.7 or连接的条件

使用or分隔开的条件，如果or前面的条件中的列有索引，而后面的列没有索引，那么涉及的所有索引就不会被用到。

2.6.8 数据分布影响

如果使用索引要比不适用索引的情况还要慢，那么就不会走索引，而是使用全表扫描。

2.6.9 sql提示

sql提示是优化数据库的一个重要手段，简单的来说就是在sql语句中加入一些人为的提示达到优化操作的目的。

• use index：使用某一个索引
• ignore index：忽略某一个索引
• force index：强迫使用某一个索引

2.6.10 覆盖索引

尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中已经能够全部找到），减少select *

2.6.11 前缀索引

当字段类型为字符串的时候，有时候索引需要很长的字符串，这会让索引变得很大，查询的时候浪费磁盘的IO，影响查询的效率。此时可以将字符串的一部分前缀建立索引，这样可以大大提升索引效率。

create index idx_*** on table_name(column(n));

2.7 索引设计原则

• 针对数据量比较大，并且查询频繁的表建立索引
• 针对经常作为查询条件，排序，分组操作的字段建立索引
• 尽量选择区分度比较高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率就越高
• 如果是字符串类型的字段，字段的长度比较长，可以针对字段的特点，建立前缀索引
• 尽量使用联合索引，减少单列索引，查询的时候联合索引 很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
• 控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价就越大，会影响增删改的效率
• 如果索引列不能存储NULL值，在创建表的时候使用NOT NULL约束。

3 SQL优化

3.1 插入数据

① 一般数据的插入

• 批量插入
• 手动事务提交：执行insert语句之前，先开启事务，插入多条语句之后，再提交事务
• 主键顺序插入

② 大批量插入数据

使用MySQL数据库提供的load指令进行插入，操作如下：

-- 客户端连接服务器的时候，加上参数
mysql --local-infile -u root -p
-- 设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;
-- 执行load指令将准备好的数据加载到表结构中
load data local infile '/root/sql.log' into table 'tb_user' fields terminated by ',' lines terminated by '/n'

3.2 主键优化

3.2.1 数据的组织方式

在InnoDB存储引擎中，表的数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表。

页可以为空，也可以填充满，每一个页包含了2-N行数据，如果一行数据过大，就会出现行溢出，根据主键排列。主键乱插入的时候可能会出现页分裂。主键删除的时候会出现页合并。

3.2.2 主键的设计原则

• 满足业务需求的情况下，尽量降低主键的长度
• 插入数据的时候，尽量选择主键的顺序插入，选择使用auto_increment自增主键
• 尽量不要使用uuid或者身份证号或者其他自然主键
• 业务操作的时候，尽量避免主键的修改

3.3 order by 优化

3.3.1 using filesort

通过表的索引或者全表扫描，读取满足条件的数据行，然后再排序的缓冲区完成排序操作，所有不是通过索引直接返回排序结果的排序都叫File sort排序

3.3.2 using index

通过有序索引顺序扫描，直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率比较高。

3.3.3 优化原则

• 根据排序字段建立合适的索引，多字段排序的时候，遵循最左前缀法则
• 尽量使用覆盖索引
• 多字段排序，一个升序，一个降序，注意联合索引在创建时候的规则(asc/desc)
• 如果不可避免出现filesort，大数据量排序的时候，可以适当增加排序缓冲区大小sort_buffer_size，默认的排序缓冲区为256k。

3.4 group by优化

• 在分组操作的时候，可以通过索引来提高效率
• 分组操作的时候，索引的使用也是满足最左前缀法则的

3.5 limit优化

一个非常常见但是头疼的问题就是，limit 2000000, 10， 此时需要MySQL排序前两百万条数据，然后将数据丢弃，仅仅返回在排序区间的数据，其他记录丢弃，查询排序的代价非常之大。

一般分页查询的时候，可以通过创建覆盖索引能够比较好的提高性能，可以通过覆盖索引加子查询的方式进行优化。

3.6 count优化

• MyISAM引擎将一个表的总行数存储在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高；
• InnoDB，在执行count(*)的时候，需要将数据一行一行从引擎中读取出来，然后累积计数。

优化思路：自己计数。

3.6.1 count的几种用法

• count 是一个聚合函数，对返回的结果集一行一行的判断，如果count的参数不是null，累积值就加1，否则就不加，最后返回累计值

• count(*), count(主键), count(field), count(1)
  

3.7 update优化

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

4 视图|存储过程|触发器

4.1 视图

见基础笔记。

4.1.1 介绍

视图是一种虚拟存在的表。属兔中的数据并不是在数据库中真实存在，行和列的数据来自定义视图的查询中使用的表，并且是在使用视图的时候就动态生成的。

视图知识保存了查询的sql的逻辑，不保存查询结果。所以我们在创建视图的时候，主要的工作就是创建sql查询语句上。

4.1.2 基本语法

-- 创建视图
create view view_name as select 查询语句;

-- 查看视图
show create view view_name;
-- 查看视图数据
select * from v_

4.2 存储过程

4.3 存储函数

4.4 触发器

4.4.1 介绍

触发器是指与表有关的数据库对象，指在insert/update/delete之前或者之后，触发并且执行触发器中定义的sql语句集合。

触发器的这种特性可以协助应用在数据库端确保数据的完整性，日志记录，数据校验等操作。

使用别名OLD和NEW来引发触发器中发生变化的记录内容，这和其他数据库是相似的。现在触发器还只是支持行级触发，不支持语句级触发。

4.4.2 触发器的操作

-- 创建触发器
create trigger t_name
before/after insert/update/delete
on tb_name for each row
begin
	trigger statements;
end;

-- 查看触发器
show triggers;

-- 删除指定数据库下的触发器
drop trigger [schema_name] t_name;

4.4.3 案例

-- 通过触发器记录tb_user表的数据变更日志，将变更日志插入到user_logs中，包含增、删、改

-- 插入数据时候的触发器
create trigger tb_user_insert_tri
after insert on tb_user for each row
begin
	insert into user_log(id, operation, operate_time, operate_id, operate_params) valuse
	(null, 'insert', now(), new.id, concat('插入的数据内容为：', new.id, 'name=', new.name, 'email=', new.email, new.profession))
end;

5 锁

5.1 概述

5.1.1 介绍

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

5.1.2 分类

• 全局锁：锁定数据库中所有的表
• 表级锁：每次操作锁定整张表
• 行级锁：每次操作锁住对应的行数据

5.2 全局锁

对整个数据库实例加锁，加锁之后整个实例处于只读状态，后续的DML语句和DDL语句，已经更新操作的事务的提交语句都将会被阻塞。

典型的使用场景就是：全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

5.2.1 操作

-- 添加全局锁
flush tables with read lock;

-- 数据库备份
mysqldump -h 101.35.51.125 -uroot -proot db01 > D:/db01.sql

-- 解锁
unlock tables;

5.2.2 特点

• 如果在主库上备份，那么在备份期间不能执行更新，业务处于停摆状态
• 如果在从库上备份，在备份期间从库不能执行主库同步过来的二进制文件binlog，会导致主从延迟

在InnoDB引擎中，我们可以在备份的时候添加参数 --single-transaction参数来完成不加锁的一致性数据备份。

5.3 表级锁

5.3.1 介绍

每次锁住整张表，锁的粒度比较大，发生锁的冲突的概率最高，并发度最低。应用在MyISAM，InnoDB等存储引擎中。

对于表级锁，主要分为以下三类：

• 表锁
• 元数据锁
• 意向锁

5.3.2 表锁

1）表共享读锁(read loak)

加了读锁之后只能读取数据，而不能修改表中的数据。

2）表独占写锁（write lock）

其他客户端不能读写这张表中的数据，但是本客户端可以读写表中的数据。

3）操作

-- 添加表锁
lock tables tb_name read | write;

-- 释放锁
unlock tables;

5.3.3 元数据锁

meta data lock：加锁过程是系统自动控制的，不需要显式的使用。在访问一张表的时候就会自动加入。MDL锁主要作用就是维护表元数据的数据一致性，在表上有活动的事务的时候，不可以对元数据进行写入操作。

为了避免DML语言和DDL产生冲突，保证读写的正确性。

5.3.4 意向锁

1）介绍

为了避免DML在执行的时候，加的行锁和表锁产生冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行是否有添加行锁，使用意向锁来减少表锁的检查。

意向锁的加锁流程：

• 事务1修改某行数据，添加了一个行锁，并且为这张表添加了一个意向锁
• 事务2想要为整张表添加表锁，先检查表的意向锁
• 如果意向锁和表锁产生冲突，就会进入阻塞状态
• 事务1提交之后，事务2添加表锁成功

2）分类

• 意向共享锁(IS)：由语句select... lock in share mode添加。和表锁中的共享锁兼容，与表锁的排他锁互斥。
• 意向排他锁(IX)：由insert|update|delete|select ... for update添加。与表共享锁和表排他锁都互斥。

5.4 行级锁

5.4.1 介绍

每一次加锁锁住对应的数据行。锁定颗粒度最小，发生锁冲突的概率最低，并发度最高，应用在InnoDB引擎中。

InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录添加的锁。对于行级锁，主要分为以下三类：

• 行锁（reacord lock）：锁定单个行记录的锁， 防止其他业务对此进行update和delete。在RC（读已提交）以及RR（可重复读）隔离级别下都支持。
• 间隙锁（gap lock）：锁定索引记录的间隙，不包含该记录，确保索引的间隙不变，防止其他事务在这个间隙进行insert操作，产生幻读，在RR级别下都支持。
• 临建锁（next-key-lock）：行锁和间隙锁的组合，同时锁住数据，并锁柱数据前面的间隙gap,在RR隔离级别下支持

5.4.2 行锁

InnoDB实现了两种类型的行锁：

• 共享锁(S)：允许一个事务去读取一行，阻止其他事务获得相同数据集的排他锁
• 排他锁(X)：允许获取排他锁的事务更新数据，阻止其他事务获取相同数据集的共享锁和排他锁

常见操作添加锁的类型：

默认情况下，InnoDB事务在RR级别下运行，InnoDB使用next-key锁进行搜索和索引的扫描

• 针对唯一索引进行检索的时候，对已经存在的记录进行等值匹配的时候，将自动优化为行锁
• InnoDB的行锁是针对索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录添加锁，此时就会升级为表锁
• 索引上的等值查询（唯一索引），给不存在的记录添加锁的时候，优化为间隙锁
• 索引上的等只查询（普通索引），向右遍历的时候最后一个值不满足查询条件时，net-key lock退化为间隙锁
• 索引上范围查询（唯一索引），会访问到不满足条罪案的第一个值为止

间隙锁唯一目的就是防止其他事务进行插入操作，间隙锁可以共存，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。

6 InnoDB引擎

6.1 逻辑存储结构

• 表空间：生成一个ibd文件，一个mysql实例可以对应多个表空间，用于存储记录，索引等数据
• 段：分为数据段、索引段、回滚段。InnoDB是索引组织表，因此数据段就是树的叶子结点，索引段就是树的非叶子结点。
• 区：表空间的单元结构，每个区的大小为1M，一个区中有64个连续的页
• 页：磁盘管理的最小单元，每一个页大小为16K，为了保证页的连续性，InnoDB存储引擎每次从磁盘中申请4-5个区
• 行：InnoDB存储引擎中的数据

6.2 架构

InnoDB架构图：

6.2.1 内存结构

• BufferPool：缓存磁盘中经常使用的真实数据。在执行增删改查操作的时候，先操作缓冲池中的数据，再以一定的频率刷新到磁盘中，减少磁盘IO
  • free page
  • clean page
  • dirty page
• change buffer：更改缓冲区，针对非唯一的耳机索引页。在执行增删改操作的时候，这些数据Page没有在缓冲池中，不会直接操作磁盘，而是将数据变更存在缓冲区change buffer中，在未来数据被读取的时候，将数据合并恢复到buffer pool中，再将合并之后的数据刷新到磁盘中。
• 自适应哈希索引：用于优化对buffer pool当中的数据查询。无需人工干预，系统自己设定
• 日志缓冲区：用来保存将要写入磁盘中的日志数据，16MB，节省磁盘IO。

6.2.2 磁盘结构

• 系统表空间：更改缓冲区的存储区域
• file-per-table tablespaces：每一张表的独立表空间
• 通用表空间：需要通过create tablespace创建通用表空间，在创建表的时候，指定该表空间
• 撤销表空间：用于存储undo日志
• 临时表空间：用来存储用户创建的临时表等数据
• 双写缓冲区：InnoDB将数据页从缓冲池中写入到磁盘之前，现将数据页写入到双写缓冲区文件中，便于系统异常的时候恢复数据
• 重做日志：用来实现事务的持久性。由重做日志缓冲区和重做日志文件组成，前者是在内存中，后者是在磁盘中

6.2.3 后台线程

• master thread：核心后台线程，负责调动其他线程，负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓存，undo页的回收等
• IO thread：InnoDB使用了大量的AIO来处理IO请求，这样可以极大提提高数据库的性能，IO Thread负责这些IO的回调。
• Purge Thread：主要用于回收事务已经提交了的undo log。
• page cleaner thread：协助主线程刷新脏页到磁盘的线程，可以减轻主线程的工作压力，减少阻塞

6.3 事务原理

6.3.1 redolog

重做日志，记录的是事务提交的时候数据页的物理修改，用来实现事务的持久性。

该日志由两部分组成：重做日志缓冲以及重做日志文件，前者是在内存中，后者是在磁盘中。当事务提交之后，会将所有的修改信息都存储到该日志文件中，用于刷新脏页到磁盘上，发生错误的时候，进行数据恢复使用。

6.3.2 undolog

用来保证事务的原子性。

回滚日志，用于记录数据在被修改之前的信息，作用包括两个：提供回滚和MVCC（多版本并发控制）。

undolog是逻辑日志，总是记录和操作相反的一条记录。比如当添加一条记录的时候，它会记录一条对应相反的delete记录。当执行rollback的时候，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

• undolog销毁：undolog在事务执行的时候产生，事务提交的时候，并不会立即删除undolog,因为这些日志可以用于MVCC
• undolog的存储：采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment

6.4 MVCC

6.4.1 概念

① 当前读

读取的记录的最新版本，读取的时候还要保证其他并发事务不能修改当前事务，并且会对读取的记录加锁。我们的日常操作都是一种当前读。

② 快照读

简单的select（不加锁）就是快照读，读取记录的可见版本，有可能是历史数据。

• read committed：每一次select都会产生一个快照
• repeated read：开启事务的第一个select才是快照读的地方
• serializable：快照读会退化为当前读

③ MVCC

维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读的功能。MVCC的具体实现，还需要依赖数据库记录中的三个隐式字段，Undo log日志以及readView。

6.4.2 隐藏字段

• DB_TRX_ID
• DB_ROLL_PTR
• DB_ROW_ID

6.4.3 undo log版本链

不同事务或者相同的事务对相同的数据进行修改，就会导致该记录的undolog生成一条记录版本的链表，链表的头部是最新的旧记录，链表的尾部是最早的旧记录。

6.4.4 readView

readView（读视图）是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。

readView包含的四个核心字段：

版本链数据访问规则：

不同的隔离级别，生成readView的时机也不同：

• READ COMMITTED：在事务中每一次执行快照读的时候生成ReadView
• REPEATABLE READ：在事务第一次执行快照读的时候生成ReadView，后续复用该ReadView

7 MySQL管理

7.1 系统数据库

MySQL安装成功之后，自带了4个数据库。

7.2 常用工具

7.2.1 连接工具

mysql 
-u # 指定用户名
-p # 指定密码
-h # 指定服务器IP或者域名
-P # 指定连接端口
-e # 执行SQL语句并退出 

7.2.2 二进制日志文件

服务器生成的二进制日志以二进制格式保存，所以想要检查这些文本的文本格式，就会使用到mysqlbinlog日志管理工具。

mysqlbinlog [options] log-files
-d # 指定数据库的名称
-o # 忽略掉日志的前n条记录
-r # 将输出的文本格式日志输出到指定的文件
-s # 显示简单格式，省略掉一些信息
--start-datatime=date1 --stop-datetime=date2 # 指定日期间隔之内的所有日志
--start-position=pos1 --stop-position=pos2 # 指定位置间隔内的所有日志

7.2.3 mysqlshow

用来很快查找存在那些数据库，数据库中的表，表中的列或者索引。

mysqlshow [options] [db_name[tab_name[col_name]]]
--count # 显示数据库以及表的统计信息
-i # 显示指定数据库或者指定表的状态信息

7.2.4 mysqlsump

用来备份数据库或者在不同数据库之间进行数据迁移。备份内容包含创建表，以及插入表的SQL语句。

mysqldump [options] db_name [tables]
mysqldump [] --database/-B db1 [db2 db3 ...]
mysqldump [] --all-databases/-A
# 输出选项
--add-drop-database # 在每一个数据创建语句之前加上drop database语句
--add-drop-table # 在创建表的时候添加语句drop table，默认是开启的
-n # 不包含数据库的创建语句
-t # 不包含表的创建语句
-d # 不包含数据
-T # 自动生成两个文件：一个.sql文件，创建表的结构的语句；一个.txt文件，数据文件

7.2.5 数据导入

# 导入文本文件
mysqlimport [options] db_name textfile1

# 导入到sql文件
source /var/lib/mysql-files/***.sql

s
-d # 指定数据库的名称
-o # 忽略掉日志的前n条记录
-r # 将输出的文本格式日志输出到指定的文件
-s # 显示简单格式，省略掉一些信息
–start-datatime=date1 --stop-datetime=date2 # 指定日期间隔之内的所有日志
–start-position=pos1 --stop-position=pos2 # 指定位置间隔内的所有日志

### 7.2.3 mysqlshow

用来很快查找存在那些数据库，数据库中的表，表中的列或者索引。

```sh
mysqlshow [options] [db_name[tab_name[col_name]]]
--count # 显示数据库以及表的统计信息
-i # 显示指定数据库或者指定表的状态信息

7.2.4 mysqlsump

用来备份数据库或者在不同数据库之间进行数据迁移。备份内容包含创建表，以及插入表的SQL语句。

mysqldump [options] db_name [tables]
mysqldump [] --database/-B db1 [db2 db3 ...]
mysqldump [] --all-databases/-A
# 输出选项
--add-drop-database # 在每一个数据创建语句之前加上drop database语句
--add-drop-table # 在创建表的时候添加语句drop table，默认是开启的
-n # 不包含数据库的创建语句
-t # 不包含表的创建语句
-d # 不包含数据
-T # 自动生成两个文件：一个.sql文件，创建表的结构的语句；一个.txt文件，数据文件

7.2.5 数据导入

# 导入文本文件
mysqlimport [options] db_name textfile1

# 导入到sql文件
source /var/lib/mysql-files/***.sql