文件——MySQL技术内幕 InnoDB存储引擎
参数文件
my.cnf文件。
mysql --help | grep my.cnf命令显示了读取的顺序
参数类型
SHOW VARIABLES查看所有参数，一直到我这个版本一共有610个参数
参数分为运行期可以改变的动态参数和运行期不能改变的静态参数。通过SET可以设置这些参数。
@@global设置的参数在全局范围内生效，@@session设置的参数在本次会话范围内生效。使用SET时如果不指定范围，则默认是会话范围。
有些参数只能在会话范围内修改，比如autocommit；有些参数只能在全局范围内修改，比如什么缓冲区大小，有些则可以在两个范围内修改。
日志文件
错误日志
记录所有错误信息的日志，也记录了一些警告信息和正确信息。
慢查询日志
慢查询日志可以记录系统中消耗时间过长的查询，从而针对性的进行优化。
这个参数指定了超过十秒钟，不包含10秒钟的查询会被认为是慢查询
这两个参数指定了男查询是否开启，并记录到哪个文件中。
在稍老一些的版本中，这两个参数名字可能不同。
这还有一个用来记录没有使用索引的查询的参数。
查询日志
查询日志记录了所有的查询。
默认是没有开启的，如果我们不需要，就不用开启占用IO性能。这里开启了。
二进制日志
记录对数据库进行更改的所有操作，有几个用处：
- 方便宕机后数据恢复
- 方便两台服务器进行数据同步
- 审计是否有对数据库进行注入攻击的SQL语句
查看当前binlog文件
尝试修改
修改已经被记录
二进制日志文件只会带来1%的IO性能损耗，这是因为它并不是修改时直接写入磁盘，而是先写入到一个会话范围内的binlog_cache_size中，等事务提交时再写入。
这是binlog的缓冲区大小
使用缓冲的代价就是容忍宕机时一部分数据丢失的风险。可以使用sync_binlog=1设置每次同步写二进制日志。
binlog_format参数指定二进制日志文件的格式
有三种取值
- STATEMENT：记录造成内容修改的SQL语句
- ROW：记录被更改的行整行的情况
- MIXED：混用前面两者
使用STATEMENT的好处就是它占用空间少，因为它只记录SQL语句，缺点就是如果语句中使用了UUID这类随机或依赖环境的函数，那么当需要通过二进制日志复制时就会出现数据不一致的问题。
使用ROW的好处就是它不会出现数据不一致问题，还有什么启用这个就可以开启已提交读隔离级别，因为它相当于在日志中记录了整行修改后的快照。缺点就是占用空间极大。
使用MIXED会在必要的时候使用ROW记录，其他时候使用STATEMENT记录。必要时候包括：
套接字文件
在unix下使用套接字连接MySQL需要建立的一个套接字文件。
pid文件
MySQL启动后会向这个文件中写入自己的进程ID。
可以去data目录中找
表定义文件
表定义文件存储在datadir中对应数据库下，扩展名为.frm。每个表对应一个。这个文件记录了表的结构。视图也有一个.frm文件。
MySQL8.0开始取消了.frm文件，这个文件被写入到.idb文件内部。
InnoDB存储引擎文件
表空间文件
InnoDB可以将所有的表数据存储在一个datadir下名为ibdata1的表空间文件中。默认大小是10MB，用完会自动增长。
可以通过参数innodb_data_file_path对其进行设置，可以设置两个表空间文件并分配到不同的磁盘上，使磁盘负载均衡。
InnoDB也可以为每一个表单独建立一个.idb格式的表空间，并且在我的8.x版本下，这是默认的行为。这个参数控制了是否为每个表单独建立一个表空间文件。
单独表空间文件仅存放表的数据、索引和插入缓冲Bitmap，其余的还是在共享表空间文件中。
重做日志文件
默认在数据目录下有两个InnoDB重做日志文件，它们记录了InnoDB存储引擎所执行的事务，所以在数据库异常宕机时，它们是InnoDB用来恢复数据库完整性和一致状态的文件。
InnoDB的重做日志以两个为一组，比如默认的两个。
InnoDB会先写组内的第一个文件，满了换成第二个，第二个满了再换成第一个。
重做日志文件太大会带来很长的恢复时间，太小可能会让一个事务多次切换重做日志文件，还会频繁的发生async checkpoint，造成性能抖动。
如果最后的检查点超过了日志文件的容量，那么就需要将脏页列表中的数据刷回磁盘。
InnoDB的重做日志文件只记录和InnoDB引擎相关的事务日志，它记录的不是更新修改的状态，而是每个页的物理情况。
重做日志缓冲写入磁盘时不需要doublewrite，因为它采用每次写入512字节（扇区最小单位），能够保证写入成功。
innodb_flush_log_at_trx_commit这个参数用于指定重做日志刷新到磁盘的时机（除了Master中刷入的之外）。
为0代表不会主动刷入，等待Master线程刷入，为1代表事务提交时同步写入磁盘，为2代表事务提交时异步写入磁盘。
只有1能完全保证数据库的持久性。
