MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具

InnoDB引擎及MysqlSQL管理工具

  • InnoDB引擎
    • 逻辑存储结构
    • 内存架构
      • 内存结构
      • 磁盘结构
  • 事务原理
      • 重做日志
      • 回滚日志
  • MVCC
    • 基本概念
      • 三个隐式字段
      • undolog版本链
      • readview
        • 案例:RC级别
        • 案例:RR级别
  • MySQL管理
    • 系统数据库
    • 常用工具

InnoDB引擎

逻辑存储结构

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第1张图片

  • 表空间(ibd文件),一个mysql实例可以对应多个表空间,用于存储记录,索引等数据。(文件默认存放位置是MySQL安装目录下的data文件夹)
  • 分为数据段(Leaf node segment)、索引段(Non-leaf node segment)、回滚段(Rollback segment),InnoDB是索引组织表,数据段就是B+树的叶子节点, 索引段即为B+树的非叶子节点。段用来管理多个Extent(区)。
  • 是表空间的单元结构,每个区的大小为1M。 默认情况下, InnoDB存储引擎页大小为16K, 即一个区中一共有64个连续的页。
  • 是InnoDB 存储引擎磁盘管理的最小单元,每个页的大小默认为 16KB。为了保证页的连续性,InnoDB 存储引擎每次从磁盘申请 4-5 个区。
  • InnoDB 存储引擎数据是按行进行存放的。

在行中,默认有两个隐藏字段:

  • Trx_id:每次对某条记录进行改动时,都会把对应的事务id赋值给trx_id隐藏列。
  • Roll_pointer:每次对某条引记录进行改动时,都会把旧的版本写入到undo日志中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息。

内存架构

MySQL5.5 版本开始,默认使用InnoDB存储引擎,它擅长事务处理,具有崩溃恢复特性,在日常开发中使用非常广泛。下面是InnoDB架构图,左侧为内存结构,右侧为磁盘结构。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第2张图片

内存结构

内存结构主要分为: Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer。

缓冲池 Buffer Pool
InnoDB存储引擎基于磁盘文件存储,物理硬盘和内存中访问速度相差很大,为了尽可能弥补这两者之间的I/O效率的差值,就需要把经常使用的数据加载到缓冲池中,避免每次访问都进行磁盘I/O。在InnoDB的缓冲池中不仅缓存了索引页和数据页,还包含了undo页、插入缓存、自适应哈希索引以及InnoDB的锁信息等等。

缓冲池 Buffer Pool是主内存中的一个区域,可以缓存磁盘上经常操作的真实数据,在执行增删改查操作时,先操作缓冲池中的数据(若缓冲池没有数据,则从磁盘加载并缓存),再以一定频率将缓冲池中的数据刷到磁盘中,从而减少磁盘IO,加快处理速度。

缓冲池以Page页为单位,底层采用链表数据结构管理Page。根据状态Page分为三种类型:

  • free page:空闲page,未被使用。
  • clean page:被使用page,数据没有被修改过。
  • dirty page:脏页,被使用page,数据被修改过,但是还没刷新到磁盘,缓冲池中数据与磁盘的数据产生了不一致。

在专用服务器上,通常将多达80%的物理内存分配给缓冲池 。参数设置: show variables like ‘innodb_buffer_pool_size’;

更改缓冲区Change Buffer
Change Buffer,更改缓冲区(针对于非唯一的二级索引页),在执行DML语句时,如果这些数据页不在Buffer Pool中,不会直接操作磁盘,而会将数据变更存缓存在更改缓冲区 Change Buffer中,在将来数据被读取时,再将数据合并恢复到Buffer Pool中,再将合并后的数据刷新到磁盘中。(主键索引和唯一索引不会操作更改缓冲区)

Change Buffer的意义是什么呢?
二级索引的结构图如下:与聚集索引不同,二级索引通常是非唯一的,并且以相对随机的顺序插入二级索引。所以每次删除和更新都可能会影响索引树中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量的磁盘IO。有了ChangeBuffer之后,可以在缓冲池中进行合并处理,减少磁盘IO,提高了效率。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第3张图片

自适应hash索引Adaptive Hash Index
hash索引在不存在hash冲突的情况下只需要一次匹配,效率高,对应B+树,可能需要进行几次匹配,但是hash索引不适合做范围查询、模糊匹配,只适合做等值匹配。MySQL的innoDB引擎中没有直接支持hash索引,但是提供了一自适应hash索引,用于优化对Buffer Pool数据的查询。
InnoDB存储引擎会监控对表上各索引页的查询,如果观察到在特定的条件下hash索引可以提升速度,则自动建立hash索引,称之为自适应hash索引。

自适应哈希索引,无需人工干预,是系统根据情况自动完成。
查看是否开启: show variables ‘%hash_index%’; ON开启
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第4张图片

日志缓冲区Log Buffer
Log Buffer:日志缓冲区,用来保存要写入到磁盘中的log日志数据(redo log 、undo log),默认大小为 16MB,日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务,增加日志缓冲区的大小可以节省磁盘 I/O。

参数:innodb_log_buffer_size:缓冲区大小
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第5张图片

innodb_flush_log_at_trx_commit:日志刷新到磁盘时机,取值主要包含以下三个:

  • 1: 日志在每次事务提交时写入并刷新到磁盘,默认值。
  • 0: 每秒将日志写入并刷新到磁盘一次。
  • 2: 日志在每次事务提交后写入,并每秒刷新到磁盘一次。

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第6张图片

磁盘结构

系统表空间System Tablespace

系统表空间是更改缓冲区的存储区域。如果InnoDB引擎当中每一张表的独立表空间关闭时,所有表的数据和索引都会存储在系统表空间。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)

参数:innodb_data_file_path,系统表空间,默认的文件名叫 ibdata1。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第7张图片
在这里插入图片描述

独立表空间File-Per-Table Tablespaces
每张表的独立表空间包含单个InnoDB表的数据和索引,并存储在文件系统上的单个数据文件中。

开关参数:innodb_file_per_table ,该参数默认开启。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第8张图片

即每创建一个表,都会产生一个表空间文件,如图:
在这里插入图片描述
通用表空间General Tablespaces
通用表空间,需要手动创建,在创建表时,可以指定该表空间。

## 创建表空间
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;

在这里插入图片描述

## 创建表时指定表空间
CREATE TABLE xxx ... TABLESPACE ts_name;

在这里插入图片描述
在这里插入图片描述

撤销表空间Undo Tablespaces

MySQL实例在初始化时会自动创建两个默认的undo表空间(初始大小16M),用于存储undo log日志。
在这里插入图片描述

临时表空间Temporary Tablespaces
InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。

双写缓冲区Doublewrite Buffer Files
innoDB引擎将数据页从Buffer Pool刷新到磁盘前,为了保证数据的安全性,先将数据页写入双写缓冲区文件中,便于系统异常时恢复数据。
在这里插入图片描述
重做日志Redo Log
重做日志用来实现事务的持久性。包含重做日志缓冲(redo logbuffer)和重做日志文件(redo log),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中, 用于在刷新脏页到磁盘时,发生错误时, 进行数据恢复使用。Redo Log不会永久保存,会每隔一段时间清理之前没用的Redo Log,当事务提交之后,就没用了,主要是保证异常时数据恢复,从而保证事务的持久性。

以循环方式写入重做日志文件,涉及两个文件:
在这里插入图片描述

后台线程
内存结构中的数据刷新到磁盘结构中,就需要借助后台线程:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第9张图片
在InnoDB的后台线程分为4类:Master Thread 、IO Thread、Purge Thread、Page Cleaner Thread。

Master Thread
核心后台线程,负责调度其他线程,还负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性,还包括脏页的刷新、合并插入缓存、undo页的回收 。

IO Thread
在InnoDB存储引擎中大量使用了AIO(异步非阻塞IO)来处理IO请求, 这样可以极大地提高数据库的性能,而IOThread主要负责这些IO请求的回调。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第10张图片

通过以下的这条指令,查看到InnoDB的状态信息,其中就包含IO Thread信息。

show engine innodb status \G;

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第11张图片
Purge Thread
主要用于回收事务已经提交了的undo log,在事务提交之后,undo log可能不用了,就用它来回收。

Page Cleaner Thread
协助 Master Thread 刷新脏页到磁盘的线程,它可以减轻 Master Thread 的工作压力,减少阻塞。

事务原理

事务是一组操作的集合,它是一个不可分割的工作单位,事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。

  • 原子性(Atomicity):事务是不可分割的最小操作单元,要么全部成功,要么全部失败。
  • 一致性(Consistency):事务完成时,必须使所有的数据都保持一致状态。
  • 隔离性(Isolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行。
  • 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变就是永久的。

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第12张图片

原子性、一致性、持久化,实际上是由InnoDB中的两份日志来保证的,一份是redo log日志,一份是undo log日志。持久性是通过数据库的锁,加上MVCC来保证的。

重做日志

重做日志redo log,记录的是事务提交时数据页的物理修改,来实现事务的持久性

该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到重做日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用,从而保证事务的持久性

如果没有redolog,可能会存在什么问题的?
1.在InnoDB引擎中的内存结构中,主要的内存区域就是缓冲池,在缓冲池中缓存了很多的数据页。
2. 当一个事务执行多个增删改的操作时,InnoDB引擎会先操作缓冲池中的数据,如果缓冲区没有对应的数据,会通过后台线程将磁盘中的数据加载出来,存放在缓冲区中。
3.然后将缓冲池中的数据修改(磁盘的数据还未修改),修改后的数据页称为脏页。
4.脏页会在一定的时机,通过后台线程刷新到磁盘中,从而保证缓冲区与磁盘的数据一致。
5. 缓冲区的脏页数据并不是实时刷新的,而是一段时间之后将缓冲区的数据刷新到磁盘中,假如刷新到磁盘的过程出错了,而提示给用户事务提交成功,而数据却没有持久化下来,没有保证事务的持久性。

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第13张图片

在InnoDB中提供了一份日志 redo log,通过redolog如何解决这个问题。
1.对缓冲区的数据进行增删改之后,首先会将操作的数据页的变化,记录在redolog buffer中。
2.在事务提交时,会将redo log buffer中的数据刷新到redo log磁盘文件中。
3.过一段时间后,如果刷新缓冲区的脏页到磁盘时,发生错误,此时就可以借助于redo log进行数据恢复,这样就保证了事务的持久性。
4.如果脏页成功刷新到磁盘或者涉及到的数据已经落盘,此时redolog就没有作用了,就可以删除了,所以存在的两个redolog文件是循环写的。

为什么每一次提交事务,要刷新redo log 到磁盘中呢,而不是直接将buffer pool中的脏页刷新到磁盘呢 ?
在业务操作中,操作数据一般都是随机读写磁盘的,而不是顺序读写磁盘。 涉及大量磁盘IO性能是比较低的,而redo log在往磁盘文件中写入数据,由于是日志文件,都是追加的,所以都是顺序写的。顺序写的效率,要远大于随机写。 这种先写日志的方式,称之为 WAL(Write-Ahead Logging)。写入日志之后,过一段时间再将脏页的数据刷新到磁盘当中。

回滚日志

回滚日志undolog,用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和MVCC(多版本并发控制) ,保证事务的原子性。

undo log和redo log记录物理日志(数据内容是什么),它是逻辑日志(每一步执行什么样的操作)。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录(执行update数据之前,数据的样子)。当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

Undo log销毁: undo log在事务执行时产生,事务提交时,并不会立即删除undo log,因为这些日志可能还用于MVCC。

Undo log存储: undo log采用段的方式进行管理和记录,存放在前面介绍的 rollback segment回滚段中,内部包含1024个undo log segment。

MVCC

基本概念

当前读: 读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select … lock in share mode(共享锁),select …for update、update、insert、delete(排他锁)都是一种当前读。

在测试中我们可以看到,即使是在默认的RR(可重复读)隔离级别下,事务A中依然可以读取到事务B最新提交的内容,因为在查询语句后面加上了 lock in share mode 共享锁,此时是当前读操作。当我们加排他锁的时候,也是当前读操作。

快照读: 简单的select(不加锁)就是快照读,快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。

  • Read Committed:每次select,都生成一个快照读。
  • Repeatable Read:开启事务后第一个select语句才是快照读的地方。
  • Serializable:快照读会退化为当前读。
    MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第14张图片

即使事务B提交了数据,事务A中也查询不到。 因为普通的select是快照读,而在当前默认的RR隔离级别下,开启事务后第一个select语句才是快照读的地方,后面执行相同的select语句都是从快照中获取数据,可能不是当前的最新数据,这样也就保证了可重复读。

MVCC:全称 Multi-Version Concurrency Control,多版本并发控制。 指维护一个数据的多个版本,使得读写操作没有冲突,快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。而MVCC + 锁,则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第15张图片

三个隐式字段

当我们创建了上面的这张表,我们在查看表结构的时候,就可以显式的看到这三个字段。 实际上除了这三个字段以外,InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第16张图片
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第17张图片

而上述的前两个字段是肯定会添加的, 是否添加最后一个字段DB_ROW_ID,得看当前表有没有主键,如果有主键,则不会添加该隐藏字段。

查看有主键的表 stu,进入服务器中的 /var/lib/mysql/itcast/ , 查看stu的表结构信息, 通过如下指令:

ibd2sdi stu.ibd

查看到的表结构信息中,有一栏 columns,在其中我们会看到处理我们建表时指定的字段以外,还有额外的两个字段 分别是:DB_TRX_ID 、 DB_ROLL_PTR ,因为该表有主键,所以没有DB_ROW_ID隐藏字段。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第18张图片
查看没有主键的表 employee,建表语句:

create table employee (id int , name varchar(10));

再通过以下指令来查看表结构及其其中的字段信息:

ibd2sdi employee.ibd

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第19张图片
查看到的表结构信息中,有一栏 columns,除了建表时指定的字段以外,还有额外的三个字段 分别是:DB_TRX_ID 、 DB_ROLL_PTR 、DB_ROW_ID,因为employee表是没有指定主键的。

undolog版本链

回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候,产生的undo log日志只在回滚时需要,在事务提交后,可被立即删除。
而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。

undolog版本链
在一张表结构中插入一条数据:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第20张图片

DB_TRX_ID : 代表最近修改事务ID,记录插入这条记录或最后一次修改该记录的事务ID,是自增的。
DB_ROLL_PTR : 由于这条数据是才插入的,没有被更新过,所以该字段值为null。

在并发访问下,有四个并发事务同时在访问这张表:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第21张图片
当事务2执行第一条修改语句时,将数据变更之前的数据记录在undo log日志,再执行更新操作,DB_TRX_ID记录本次操作的事务ID(记录哪个事务最后操作这条数据),当前事务id为2,DB_ROLL_PTR 回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第22张图片
当事务3执行第一条修改语句时,也会记录undo log日志,如上。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第23张图片
当事务4执行第一条修改语句时,也会记录undo log日志,如上。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第24张图片

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

readview

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

ReadView中包含了四个核心字段:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第25张图片

而在readview中就规定了版本链数据的访问规则:trx_id 代表当前undolog版本链对应事务ID。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第26张图片
不同的隔离级别,生成ReadView的时机不同:

  • READ COMMITTED :在事务中每一次执行快照读时生成ReadView。
  • REPEATABLE READ:仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。

案例:RC级别

在事务5中,查询了两次id为30的记录,由于隔离级别为Read Committed,所以每一次进行快照读都会生成一个ReadView,两次生成的ReadView如下:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第27张图片
在进行匹配时,会从undo log的版本链中,从上到下进行挨个匹配

第一次快照读具体的读取过程:
1.先匹配trx_id=4这条记录,将4代入右侧的匹配规则中,①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
2.再匹配trx_id为3这条记录,代入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
3.trx_id为2这条记录,将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配,此次快照读,返回的数据就是版本链中记录的这条数据。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第28张图片
第二次快照读具体的读取过程:
1.匹配trx_id为4的记录,将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
2.匹配trx_id为3的记录,将3带入右侧的匹配规则中。①不满足 ②满足 。终止匹配,此次快照读,返回的数据就是版本链中记录的这条数据。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第29张图片

案例:RR级别

RR隔离级别下,仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。 而RR 是可重复读,在一个事务中,执行两次相同的select语句,查询到的结果是一样的。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第30张图片
在RR隔离级别下,只是在事务中第一次快照读时生成ReadView,后续都是复用该ReadView,那么既然ReadView都一样, ReadView的版本链匹配规则也一样, 那么最终快照读返回的结果也是一样的。

MySQL管理

系统数据库

Mysql数据库安装完成后,自带了一下四个数据库,具体作用如下:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第31张图片

常用工具

mysql: 该mysql不是指mysql服务,而是指mysql的客户端工具

语法 :
		mysql [options] [database]
选项 :
		-u, --user=name #指定用户名
		-p, --password[=name] #指定密码
		-h, --host=name #指定服务器IP或域名
		-P, --port=port #指定连接端口
		-e, --execute=name #执行SQL语句并退出

-e选项可以在Mysql客户端执行SQL语句,而不用连接到MySQL数据库再执行,对于一些批处理脚本,这种方式尤其方便。

示例:

mysql -uroot –p123456 db01 -e "select * from stu";

mysqladmin: 是一个执行管理操作的客户端程序。可以用它来检查服务器的配置和当前状态、创建并删除数据库等。

通过帮助文档查看选项:
mysqladmin --help
语法:
	mysqladmin [options] command ...
选项:
	-u, --user=name #指定用户名
	-p, --password[=name] #指定密码
	-h, --host=name #指定服务器IP或域名
	-P, --port=port #指定连接端口

示例:

mysqladmin -uroot –p1234 drop 'test01';
mysqladmin -uroot –p1234 version;

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

语法 :
	mysqlbinlog [options] log-files1 log-files2 ...
选项 :
	-d, --database=name 指定数据库名称,只列出指定的数据库相关操作。
	-o, --offset=# 忽略掉日志中的前n行命令。
	-r,--result-file=name 将输出的文本格式日志输出到指定文件。
	-s, --short-form 显示简单格式, 省略掉一些信息。
	--start-datatime=date1 --stop-datetime=date2 指定日期间隔内的所有日志。
	--start-position=pos1 --stop-position=pos2 指定位置间隔内的所有日志。

mysqlshow: 客户端对象查找工具,用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引。

语法 :
mysqlshow [options] [db_name [table_name [col_name]]]
选项 :
	--count 显示数据库及表的统计信息(数据库,表 均可以不指定)
	-i 显示指定数据库或者指定表的状态信息
示例:
	#查询test库中每个表中的字段书,及行数
	mysqlshow -uroot -p2143 test --count
	#查询test库中book表的详细情况
	mysqlshow -uroot -p2143 test book --count

示例: 查询每个数据库的表的数量及表中记录的数量

mysqlshow -uroot -p1234 --count

示例:查看数据库hei的统计信息

mysqlshow -uroot -p1234 heimam --count

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第32张图片

示例:查看数据库heima中的stu表的信息

mysqlshow -uroot -p1234 heima stu --count

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第33张图片
示例:查看数据库heima中的stu表的id字段的信息

mysqlshow -uroot -p1234 heima stu id --count

在这里插入图片描述

mysqldump: 客户端工具用来备份数据库或在不同数据库之间进行数据迁移。备份内容包含创建表,及插入表的SQL语句。

语法 :
	mysqldump [options] db_name [tables]
	mysqldump [options] --database/-B db1 [db2 db3...]
	mysqldump [options] --all-databases/-A
连接选项 :
	-u, --user=name 指定用户名
	-p, --password[=name] 指定密码
	-h, --host=name 指定服务器ip或域名
	-P, --port=# 指定连接端口
输出选项:
	--add-drop-database 在每个数据库创建语句前加上 drop database 语句
	--add-drop-table 在每个表创建语句前加上 drop table 语句 , 默认开启 ; 不开启 (--skip-add-drop-table)
	-n, --no-create-db 不包含数据库的创建语句
	-t, --no-create-info 不包含数据表的创建语句
	-d --no-data 不包含数据
	-T, --tab=name 自动生成两个文件:一个.sql文件,创建表结构的语句;一个.txt文件,数据文件

示例:备份db01数据库:

mysqldump -uroot -p12345678 heima > heima.sql

在这里插入图片描述
可以直接打开db01.sql,来查看备份出来的数据到底什么样。

备份出来的数据包含:删除表的语句,创建表的语句,数据插入语句
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第34张图片

在数据备份时,不需要创建表,或者不需要备份数据,只需要备份表结构,都可以通过对应的参数来实现。

备份db01数据库中的表数据,不备份表结构(-t)

mysqldump -uroot -p12345678 -t heima > heima02.sql

打开 heima02.sql ,来查看备份的数据,只有insert语句,没有备份表结构。
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第35张图片
只备份表结构,不备份数据

mysqldump -uroot -p12345678 -d heima > heima03.sql

MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第36张图片
将db01数据库的表的表结构与数据分开备份(-T)

mysqldump -uroot -p1234 -T /root db01 score

执行上述指令会出错,数据不能完成备份,因为所指定的数据存放目录/root,MySQL认为是不安全的,需要存储在MySQL信任的目录下。可以查看一下系统变量 secure_file_priv ,查看信任目录,执行结果如下:
MySQL(六)InnoDB引擎结构,事务原理,MVCC及MysqlSQL管理工具_第37张图片
在这里插入图片描述
在这里插入图片描述
上述的两个文件 score.sql 中记录的就是表结构文件,而 score.txt 就是表数据文件,但是需要注意表数据文件,并不是记录一条条的insert语句,而是按照一定的格式记录表结构中的数据。如下:
在这里插入图片描述
mysqlimport: 是客户端数据导入工具,导入备份的txt文件,用来导入mysqldump 加 -T 参数后导出的文本文件。

语法 :
	mysqlimport [options] db_name textfile1 [textfile2...]
示例 :
	mysqlimport -uroot -p2143 test /tmp/city.txt

出现问题:不信任的目录,默认是当前目录,需要加上目录路径。
在这里插入图片描述
在这里插入图片描述
source: 导入备份的sql文件

source /root/xxxxx.sql

你可能感兴趣的:(mysql,mysql,数据库)