一、存储引擎概念介绍
MySQL中的数据用各种不同的技术存储在文件中，每一种技术都使用不同的存储机制、索引技巧、锁定水平并最终提供不同的功能和能力，这些不同的技术以及配套的功能在MySQL中称为存储引擎，而存储引擎就是MySQL将数据存储在文件系统中的存储方式或者存储格式。
■MySQL存储引擎是MySQL数据库服务器中的组件，负责为数据库执行实际的数据I/O操作
使用特殊存储引擎的主要优点之一在于， 仅需提供特殊应用所需的特性，数据库中的系统开销较小，具有更有效和更高的数据库性能
MySQL系统中,存储引擎处于文件系统之上，在数据保存到数据文件之前会传输到存储引擎，之后按照各个存储引擎的存储格式进行存储
目前MySQL常用的两种存储引擎
MyISAM
InnoDB
MyISAM的介绍
■MyISAM存储引擎是MySQL关系数据库系统5.5版本之前默认的存储引擎。前身是ISAM，MyISAM管理非事务表，是ISAM的扩展格式，提供ISAM里所没有的索引和字段管理的大量功能，MyISAM使用一种表格锁定的机制，以优化多个并发的读写操作，提供高速存储和检索，以及全文搜索能力，受到web开发的青睐。
ISAM是一个定义明确且历经时间考验的数据表格管理方法，在设计之时就考虑到数据库被查询的次数要远大于更新的次数
ISAM的特点
1：不支持事务处理，不能够容错。
2：表级锁定形式，数据在更新时锁定整个表
3：数据库在读写过程中相互阻塞（会在数据写入的过程阻塞用户数据的读取，也会在数据读取的过程中阻塞用户的数据写入)
4：可通过key_buffer_size来设置缓存索引，提高访问性能，减少磁盘I0的压力(但缓存只会缓存索引文件，不会缓存数据)
5：采用MyISAM存储引擎数据单独写入或读取，速度过程较快且占用资源相对少
6：MyISAM存储引擎它不支持外键约束，只支持全文索引
7：每个MyISAM在磁盘上存储成三个文件,每一个文件的名字以表的名字开始，扩展名指出文件类型
MyISAM在磁盘上存储的文件
● .frm文件存储表定义
●数据文件 的扩展名为.MYD (MYData)
●索引文件 的扩展名是.MYI (MYIndex)
MyISAM适用的生产场景举例
公司业务不需要事务的支持；一般单方面读取数据比较多的业务，或单方面写入数据
比较多的业务；使用读写并发访问相对较低的业务，使用读写并发访问相对较低的业务，数据修改相对较少的业务；对数据业务-致性要求不是非常高的业务，服务器硬件资源相对比较差。
InnoDB特点
支持事务:支持4个事务隔离级别
行级锁定，但是全表扫描仍然会是表级锁定
读写阻塞与事务隔离级别相关
具有非常高效的缓存特性：能缓存索引，也能缓存数据
表与主键以簇的方式存储
支持分区、表空间，类似oracle数据库
支持外键约束，5.5以前不支持全文索引，5.5版本以后支持全文索引
对硬件资源要求还是比较高的场合
InnoDB适用生产场景分析
业务需要事务的支持
行级锁定对高并发有很好的适应能力，但需确保查询是通过索引来完成
业务数据更新较为频繁的场景，如:论坛，微博等
业务数据一致性要求较高，例如:银行业务
硬件设备内存较大，利用Innodb较好的缓存能力来提高内存利用率，减少磁盘IO的压力
企业选择存储引擎依据
需要考虑每个存储引擎提供了哪些不同的核心功能及应用场景
支持的字段和数据类型：所有引擎都支持通用的数据类型，但不是所有的引擎都支持其它的字段类型，如二进制对象
■锁定类型：不同的存储引擎支持不同级别的锁定
表锁定
行锁定
■索引的支持
建立索引在搜索和恢复数据库中的数据的时候能够显著提高性能，不同的存储引擎提供不同的制作索引的技术，但有些存储引擎根本不支持索引。
■事务处理的支持
事务处理功能通过提供在向表中更新和插入信息期间的可靠性
可根据企业业务是否要支持事务选择存储引擎
二、存储引擎 命令配置：
查看表正在使用的存储引擎
方法1: show table status from 库名 where name=‘表名’;
方法2: show create table表名;
修改存储引擎
方法1: alter table修改;
alter table table_name engine=引擎;
方法2:修改my.cnf, 指定默认存储引擎并重启服务
default-storage-engine=InnoDB
方法3: create table创建表时指定存储引擎
create table 表名 (段) engine=引擎
方法4: Mysql_convert_table_format 转化存储引擎
Mysql_convert_table_format --user=root --password=密码 --sock=/tmp/mysql.sock -engine=引擎 库名 表名
三：数据库备份的分类及命令配置
从物理与逻辑的角度，备份可分为
物理备份:对数据库操作系统的物理文件(如数据文件、日志文件等)的备份
物理备份又可以分为脱机备份(冷备份)和联机备份(热备份)
冷备份: 是在关闭数据库的时候进行的
热备份: 数据库处于运行状态，这种备份方法依赖于数据库的日志文件
逻辑备份:对数据库逻辑组件(如表等数据库对象)的备份
逻辑备份中的表 要备份三个：
表的结构文件frm
表的数据文件MYD
表的索引文件MYI
从数据库的备份策略角度,备份可分为
完全备份:每次对数据进行完整的备份
完全备份是对整个数据库的备份、数据库结构和文件结构的备份，完全备份保存的是备份完成时刻的数据库，完全备份是增量备份的基础。
优点：备份与恢复操作简单方便
缺点：数据存在大量的重复；占用大量的备份空间；备份与恢复时间长
差异备份:备份那些自从上次完全备份之后被修改过的文件
增量备份:只有那些在上次完全备份或者增量备份后被修改的文件才会被备份
1: 备份数据库命令
- MySQL数据库的备份可以采用用多种方式：
方法一：直接打包数据库文件夹，如/usr/local/mysql/data
- 使用专用备份工具mysqldump
方法二：mysqldump是MySQL自带的备份工具，相当方便对MySQL进行备份。
通过该命令工具可以将指定的库、表或全部的库导出为SQL脚本，在需要恢复时可进行数据恢复。
<1>: mysqldump命令对单个库进行完全备份
mysqldump -u用户名 -p [密码] [选项] [数据库名] > /备份路径/备份文件名
<2>: mysqldump命令对多个库进行完全备份
mysqldump -u用户名 -p [密码] [选项] --databases 库名1 [库名2]… > /备份路径/备份文件名
<3>: 对所有库进行完全备份
mysqldump -u用户名 -p [密码] [选项] -all-databases > /备份路径/备份文件名
<4> mysqldump 只备份表
在实际生产环境中，存在对某个特定表的维护操作，此时mysqldump同样发挥重大作用
mysqldump -u用户名 -p [密码] [选项] 数据库名 表名 > /备份路径/备份文件名
<5>对表结构进行完整备份
mysqldump -u用户名 -p [密码] [-d] 数据库名 表名 > /备份路径/备份文件名
2: 恢复数据库命令
使用mysqldump命令导出的SQL备份脚本，在进行数据恢复时可使用以下方法：
方法一：source 命令 (登录到数据库中，执行source备份sql脚本路径)
方法二： 使用mysq|命令恢复数据
mysgl _u用户名 -p [密码] < 库备份脚本的路径
恢复表
mysql -u用户名 -p [密码] < 表备份脚本的路径
恢复表时同样可以使用source或者mysql命令进行，source恢复表的操作与恢复库的操作相同，当备份文件中只包含表的备份，而不包括创建库的语句时，必须指定库名，且目标库必须存在
四：MySQL数据库增量备份及恢复
1, MySQL增量备份介绍
使用mysqldump进行完全备份的缺陷：备份数据中有重复数据；备份时间与恢复时间长
增量备份就是备份自上一次备份之后增加或变化的文件或者内容
■增量备份的特点
没有重复数据，备份量不大，时间短
恢复麻烦:需要上次完全备份及完全备份之后所有的增量备份才能恢复，而且要对所有增量备份进行逐个反推恢复
MySQL没有提供直接的增量备份方法，可以通过MySQL提供的二进制日志(binary logs)间接实现增量备份
■MySQL二进制日志对备份的意义
二进制日志保存了所有更新或者可能更新数据库的操作，在启动MySQL服务器后开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件，只需定时执行flush logs方法重新创建新的日志，生成二进制文件序列，并及时把这些旧的日志保存到安全的地方就完成了一个时间段的增量备份。
2, MySQL备份思路
- 定期实施备份，制定备份计划或者策略，并严格遵守除了进行完全备份，开启MySQL服务器的日志功能是很重要的。(完全备份加上日志，可以对MySQL进行最大化还原)
- 使用统一的和易理解的备份文件名称
不要使用backup1、backup2等这样没有意义的名字，推荐使用库名或者表名加上时间的命名规则。
3, MySQL增量恢复方法
mysqlbinlog [--no-defaults] 增量备份文件 | mysqI -u 用户名 -p
<1> 从日志开头截止到某个时间点的恢复
mysqlbinlog [--no defaults] --stop-datetime='年-月-日 小时:分钟:秒'二进制日志|mysql -u用户名 -p密码
<2>从某个时间点到日志结尾的恢复
mysqlbinlog [--no defaults] --start-datetime='年-月-日 小时:分钟:秒'二进制日志|mysql -u用户名 -p密码
就是将某个起始时间的二进制日志导入数据库中，从而跳过某个发生错误的位置点实现数据的恢复
<1> 恢复数据到指定位置
mysqlbinlog --stop-position='操作id' 二进制日志|mysql -u用户名 -p密码
<2> 从指定的位置开始恢复数据
mysqlbinlog --start-position=‘操作id’ 二进制日志|mysql -u用户名 -p密码
mysqlbinlog --start-position='操作id' 二进制日志|mysql -u用户名 -p密码
4，MySQL增量备份恢复配置示例
基于时间点和位置点的恢复
目的：模拟误操作，恢复正常操作的内容，跳过误操作。
方法一：【基于时间点的恢复操作】
（1）首先编译安装mysql ，步骤省略，（搭建LNMP架构里有步骤，不知道的可以看博文）。
（2）添加初始数据记录（创建数据库、表、2条初始数据记录）。
（3）开启二进制日志功能（日志文件000001 在前面已经刷新生成，现在重新刷新生成新的日志文件000002，之后的操作都会记录到000002日志中）。
更改mysql配置文件 # vim /etc/my.cnf
（4）使用mysqldump 命令 对数据库school 进行完整备份。
（5）插入数据记录，并模拟误操作，删除一条数据记录。误删的操作在中间。
（6）再次刷新日志，相当于把上面的操作保存到日志文件000002，生成新日志文件。正常操作和误操作都在02日志文件中
（7）通过解码器可以把日志文件解码到新文件中，下面的增量恢复 需要用到文件里操作命令的位置和时间点。才能基于时间点进行断点恢复。
进入文件#vim /opt/bak.txt 可以查看到时间点和位置
误操作的时间点：200110 15:29:23 --stop-datetime
下一条正常操作的时间点：200110 15:33:15 --start-datetime
（8）模拟误操作，删表。
（9）用source命令 先恢复完整备份的表数据，也就是初始数据，不包括之后插入的数据和误操作。
误操作的时间点：2020-01-10 15:29:23 --stop-datetime
下一条正常操作的时间点：2020-01-10 15:33:15 --start-datetime
（10）基于时间点的恢复。数据从开始恢复到误操作之前，也就是恢复第一条插入语句，命令如下：
（11）基于时间点的恢复。数据从第第二条正常插入语句开始恢复到结束，也就是恢复第二条插入语句，中间的误操作语句被跳过，未执行。命令如下：
方法二：【基于位置的恢复操作】
（1）还原到 已完整备份初始数据库的状态。
进入文件#vim /opt/bak.txt 可以查看到操作语句的时间点和位置
【at 610 --stop-position 数据恢复到610指定位置为止】
【at 714 --start-position 再从指定位置714 开始恢复数据】
（2） 基于位置点的恢复。数据从开始恢复到误操作之前，也就是恢复第一条插入语句，命令如下：
（11）基于位置点的恢复。数据从第二条正常插入语句开始恢复到结束，也就是恢复第二条插入语句，中间的误操作删除语句被跳过，未执行。命令如下：
【一般恢复 操作】
完整数据备份后，在数据库中执行的操作，不指定位置和时间，恢复之后 将都会被执行。如你误删一条数据记录也会被执行。误删的数据就没有了。
（1）再次删除还原到 已恢复 完整备份的初始数据状态。前面基于时间点恢复已恢复过，这里就不重复操作了。
（2）增量恢复数据，不指定sql操作语句的时间和位置，则表示 完整备份后 添加和删除数据记录的sql语句都会被执行 恢复。
（3）恢复命令操作后，再次查看表内容，( 添加lisi、stu03 ，删除stu02 ) 两条添加语句 一条删除语句都被执行。
