北京营销网站建设,十堰h5响应式网站,苏州高新区网页设计,电子商务网站建设与管理实验报告文章目录 一、参数文件二、日志文件三、表结构定义文件四、InnoDB 存储引擎文件1、表空间文件2、重做日志文件 一、参数文件
当 MySQL 实例启动时#xff0c;数据库会先去读一个配置参数文件#xff0c;用来寻找数据库的各种文件所在位置以及指定某些初始化参数。在默认情况… 文章目录 一、参数文件二、日志文件三、表结构定义文件四、InnoDB 存储引擎文件1、表空间文件2、重做日志文件 一、参数文件
当 MySQL 实例启动时数据库会先去读一个配置参数文件用来寻找数据库的各种文件所在位置以及指定某些初始化参数。在默认情况下MySQL 实例会按照一定的顺序在指定的位置读取没有参数文件也可以运行这时所有的参数值取决于编译 MySQL 时指定的默认值和源代码中指定参数的默认值。
但是如果在默认的数据库目录下找不到 mysql 架构则启动同样失败mysql 架构中记录了访问该实例的权限。
可以通过命令**show variables**来查看数据库中的所有参数可以通过 like 来过滤参数名。
MySQL 数据库中的参数可以分为两类
动态参数可以在 MySQL 实例运行中进行更改静态参数在整个实例生命周期内只读不可进行修改
可以通过 set 命令对动态参数进行修改通过global和session来指定是对当前会话进行修改还是对整个实例生命周期都生效。
二、日志文件 错误日志 慢查询日志可以在 MySQL 启动时设置一个阈值将运行时间超过该值的所有 SQL 语句都记录到慢查询日志文件中该阈值可以通过参数 long_query_time 来设置默认为 10 秒。默认情况下不开启慢查询日志可以通过 log_slow_queries 参数来开启 log_queries_not_using_indexes 参数用来开启记录没有使用索引的 SQL 语句log_throttle_queries_not_using_indexes 参数用来表示每分钟允许记录到 slow log 的且未使用索引的 SQL 语句次数默认为 0即没有限制可以通过 mysqldumpslow 命令来方便的查看相关的信息可以通过 log_output 指定慢查询输出的格式默认为 FILE可以将它设置为 TABLE之后就可以查询 mysql 架构下的 slow_log 表 查询日志记录了所有对 MySQL 数据库请求的信息无论请求是否得到了正确的执行甚至包括 Access denied的请求 二进制日志记录了对 MySQL 数据库执行更改的所有操作不包括 SELECT 和 SHOW 这类操作需要使用查询日志
二进制日志文件主要右以下几种作用 恢复某些数据的恢复需要二进制日志 例如在一个数据库全备文件恢复后用户可以通过二进制日志进行 point-in-time 的恢复 复制原理与恢复相似通过复制和执行二进制日志使 slave 数据库与 master 数据库进行实时同步 审计用户可以通过二进制日志中的信息来进行审计判断是否有对数据库进行注入的攻击
**二进制文件在默认情况下并没有启动**需要手动指定参数来启动。开启这个选项会对数据库的整体性能有所影响但是影响十分有限1%。如果使用 InnoDB 存储引擎进行复制并且想得到最大的高可用性建议开启。
在默认情况下二进制日志并不是每次写的时候就同步磁盘因此当数据库所在操作系统发生宕机时可能会有最后一部分数据没有写入二进制日志文件。
sync_binlog1每次提交事务的时候直接使用 fsync 写入磁盘不使用操作系统的缓冲、sync_binlog0默认值每次提交事务的时候都保存到操作系统的 page cache之后由文件系统自己控制缓存的刷新sync_binlog1每次提交事务都先写到 page cache等到积累了 N 个事务之后才 MySQL 调用操作系统刷新操作刷入盘 日志的记录格式有以下三种 STATEMENT记录的是逻辑 SQL 语句 ROW记录的不再是简单的 SQL 语句而是记录行更改情况如果一个update语句修改一百行数据那么这种模式下就会记录100行对应的记录日志 MIXED默认使用 STATEMENT 格式保存一些情况下无法完成主从复制的操作使用 ROW 格式保存 使用了 UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNTS() 等不确定函数使用了 INSERT DELAY 语句使用了用户定义函数使用了临时表
一个 SQL 在不同的时间点执行它们产生的数据变化和影响是不一样的所以这种情况下数据同步或恢复的时候就容易出现不一致的情况因此使用 ROW 可以带来更好的可靠性。
binlog 是二进制文件需要使用 mysqlbinlog 命令查看。
三、表结构定义文件
因为 MySQL 插件式存储引擎的体系结构的关系MySQL 数据的存储是根据表的 每个表都会有与之对应的文件。在 MySQL 8 之前不论表采用何种存储引擎都有一个以 frm 为后缀名的文件记录了该表的表结构定义。MySQL 8之后 InnoDB 存储引擎的表定义结构整合到 ibd 文件中而 MyISAM 的 frm 文件变为 sdi 文件。
四、InnoDB 存储引擎文件
前面的文件都是 MySQL 数据库本身的文件和存储引擎无关。除了这些文件外每个表存储引擎还有自己独有的文件。
1、表空间文件
InnoDB 存储引擎可将所有数据存放于 ibdata* 的共享表空间也可将每张表存放于独立的 .ibd 文件的独立表空间(部分数据)。共享表空间以及独立表空间都是针对数据的存储方式而言的。 共享表空间某一个数据库的所有的表数据索引文件全部放在一个文件中默认这个共享表空间的文件路径在 data 目录下。 默认的文件名为 ibdata1初始大小为 10M。可以使用 innodb_data_file_path 设置一个或者多个文件组成表空间同时可以指定大小属性如果用完文件可以自动增长 其中会包括 undo 信息在事务未提交时数据即已经写入了表空间文件当事务rollback时Undo信息不会被删除但是此空间会被标记后续会以覆盖的方式被重新使用Changebuffer 和 doublewrite buffer 也保存在其中 独立表空间可以通过 innodb_file_per_table ON 来开启独立表空间。开启后每个表都会生成独立的 .ibd 文件来进行存储 包括了单独一个表的数据、索引等内容其余数据仍存放在共享表空间中默认情况下独立表空间的存储位置也是在表的位置之中。
InnoDB 采用将存储的数据按表空间进行存放的设计。在默认配置下会有一个初始大小为 10 MB名为 ibdata1 的文件该文件就是默认的共享表空间文件。
2、重做日志文件
在默认情况下data 目录下会有两个名为 ib_logfile0 和 ib_logfile1的文件。每个 InnoDB 存储引擎至少有一个重做日志文件组每个文件组下至少有 2 个重做日志文件。为了得到更高的可靠性可以设置多个镜像日志组将不同的文件组放在不同的磁盘以此提高重做日志的可用性。
在日志组中每个重做日志文件的大小一致并以循环写入的方式运行。InnoDB 存储引擎险些重做日志文件1当到达文件的最后时会切换至重做日志文件2再当重做日志2也被写满时会再切换到重做日志文件1中。 重做日志文件不能设置的太大否则恢复时可能需要很长的时间也不能设置的太小否则可能导致一个事务的日志需要多次切换重做日志文件并且导致频繁地发生 async checkpoint导致性能的抖动。
与 binlog 的区别
binlog 会记录所有与 MySQL 数据库有关的日志记录包括 InnoDB、MyISAM、Heap 等而 redo log 只记录 InooDB 存储引擎本身的事务日志binlog 记录的是关于一个事务的具体操作内容即该日志是逻辑日志而 redo log 记录的是关于每个页的更改的物理情况binlog 仅在事务提交前进行提交即一个事务只刷盘一次而重做日志条目会在事务进行的过程中不断地写入到重做日志文件中binlog 是可以追加写入的指 binlog 文件写到一定大小后会切换到下一个并不会覆盖以前的日志保存的是全量的日志redo log 是循环写的空间固定会用完只会记录未刷盘的日志已经刷入磁盘的数据都会因为空间有限而在后续被覆盖
虽然 binlog 拥有全量的日志但没有一个标志让 innoDB 判断哪些数据已经刷盘哪些数据还没有。而 redo log 每次刷盘会更新日志文件中的Check Point根据对应的LSN来判断该条操作是否已经落盘。所以redo log具有crash-safe能力
redo log 条目结构
redo_log_type一个字节表示重做日志的类型space表空间的ID采用压缩的方式有可能小于 4 个字节page_no页的偏移量同样采用压缩的方式redo_log_body重做日志的数据部分
重做日志缓冲往磁盘写入时是按 512 个字节也就是一个扇区的大小进行写入。因为扇区时写入的最小单位因此可以保证写入必定是成功的所以重做日志的写入过程中不需要有 doublewrite。
重做日志的写入磁盘的情况 每秒 Master Thread 都会将重做日志缓冲写入磁盘的重做日志文件中不论事务是否已经提交 事务提交时根据 innodb_flush_log_at_trx_commit 参数控制 0 表示提交事务时不将事务的重做日志写入磁盘的日志文件而是等待主线程每秒的刷新 1 表示提交时将重做日志缓冲同步写到磁盘即伴随 fsync 2 表示提交时将重做日志缓冲异步写道磁盘即写道文件系统的缓存中因此不能完全保证在执行 commit 时肯定会写入重做日志文件 设置为 2 时当数据库宕机而操作做系统以及服务器没有发生故障时数据不会丢失
