网站建设便宜开源程序做网站任务

网站建设便宜,开源程序做网站任务,建网站收费吗,仿网站工具1.什么是MYSQL日志 MySQL日志是指 MySQL 数据库系统中记录的重要事件、查询、错误和性能信息的文件。 日志是数据库管理和诊断的重要工具#xff0c;能够帮助管理员监控、排查问题、优化性能、以及进行故障恢复。 2.MYSQL的日志文件分类 ①错误日志#xff08;Error…1.什么是MYSQL日志MySQL日志是指 MySQL 数据库系统中记录的重要事件、查询、错误和性能信息的文件。 日志是数据库管理和诊断的重要工具能够帮助管理员监控、排查问题、优化性能、以及进行故障恢复。2.MYSQL的日志文件分类①错误日志Error Log记录 MySQL 服务器启动、运行或停止时出现的问题。②慢查询日志Slow Query Log记录执行时间超过long_query_time值的所有SQL语句。这个时间值是可配置的默认情况下慢查询日志功能是关闭的。可以用来识别和优化慢SQL。③一般查询日志General Query Log记录所有 MySQL 服务器的连接信息及所有的 SQL 语句不论这些语句是否修改了数据。④二进制日志Binary Log记录了所有修改数据库状态的 SQL 语句以及每个语句的执行时间如 INSERT、UPDATE、DELETE 等但不包括 SELECT 和 SHOW 这类的操作。以及两个 InnoDB 存储引擎特有的日志文件⑤重做日志Redo Log记录了对于 InnoDB 表的每个写操作不是 SQL 级别的而是物理级别的主要用于崩溃恢复。⑥回滚日志Undo Log或者叫事务日志记录数据被修改前的值用于事务的回滚。支持事务回滚可以用来实现 MVCC即多版本并发控制。3.binlog3.1.什么是binlogbinlog是一种物理日志会在磁盘上记录下数据库的所有修改操作以便进行数据恢复和主从复制。当发生数据丢失时binlog 可以将数据库恢复到特定的时间点。主服务器master上的二进制日志可以被从服务器slave读取从而实现数据同步。默认没启动要启动需要去配置文件配置参数。3.2.binlog和redolog的区别1bin log会记录所有与数据库有关的日志记录包括InnoDB、MyISAM等存储引擎的日志而redo log只记InnoDB存储引擎的日志。2记录的内容不同bin log记录的是关于一个事务的具体操作内容即该日志是逻辑日志。而redo log记录的是关于每个页Page的更改的物理情况。3写入的时间不同bin log仅在事务提交前进行提交也就是只写磁盘一次。而在事务进行的过程中却不断有 redo ertry 被写入redo log中。4写入的方式也不相同redo log是循环写入和擦除bin log是追加写入不会覆盖已经写的文件。4.更新语句的执行操作4.1.执行流程1执行器先找引擎获取 ID2 这一行。ID 是主键存储引擎检索数据找到这一行。如果 ID2这一行所在的数据页本来就在内存中就直接返回给执行器否则需要先从磁盘读入内存然后再返回。2执行器拿到引擎给的行数据把这个值加上 1比如原来是 N现在就是 N1得到新的一行数据再调用引擎接口写入这行新数据。3引擎将这行新数据更新到内存中同时将这个更新操作记录到 redo log 里面此时 redo log 处于 prepare 状态。然后告知执行器执行完成了随时可以提交事务。4执行器生成这个操作的 binlog并把 binlog 写入磁盘。5执行器调用引擎的提交事务接口引擎把刚刚写入的 redo log 改成提交commit状态更新完成。4.2.为什么要两段提交1先写入 redo log后写入 binlog在写完 redo log 之后数据此时具有crash-safe能力数据库崩溃后仍保持数据安全因此系统崩溃数据会恢复成事务开始之前的状态。但是若在 redo log 写完时候binlog 写入之前系统发生了宕机。此时binlog没有对上面的更新语句进行保存导致当使用 binlog 进行数据库的备份或者恢复时就少了上述的更新语句。从而使得id2这一行的数据没有被更新。2先写入 binlog后写入 redo log写完 binlog 之后所有的语句都被保存所以通过 binlog 复制或恢复出来的数据库中 id2 这一行的数据会被更新为 a1。但是如果在 redo log 写入之前系统崩溃那么 redo log 中记录的这个事务会无效导致实际数据库中id2这一行的数据并没有更新。4.3.redo.logredo log是一种物理日志记录了对数据页的物理更改。当事务进行写操作时InnoDB 首先会写入 redo log并不会立即修改数据文件。这种写入方式被称为“write-ahead logging”先写日志。当 redo log 填满或在某些其他情况下InnoDB 会异步将这些更改刷新到数据文件中。系统崩溃时由于数据可能还没有被真正写入数据文件但已经在 redo log 中因此系统可以在启动时使用这些日志来重新执行或“重做”这些更改确保数据的持久性。即使数据库在事务提交后立即崩溃由于事务的更改已经记录在 redo log 中这些更改在数据库恢复时仍然是安全的。4.4.redolog刷入磁盘redo log的写入不是直接落到磁盘而是在内存中设置了一片称之为redo log buffer的连续内存空间也就是redo 日志缓冲区。什么时候会刷入磁盘在如下的一些情况中log buffer 的数据会刷入磁盘1log buffer 空间不足时log buffer的大小是有限的如果不停的往这个有限大小的 log buffer 里塞入日志很快它就会被填满。如果当前写入 log buffer 的 redo 日志量已经占满了 log buffer 总容量的大约一半左右就需要把这些日志刷新到磁盘上。2事务提交时在事务提交时为了保证持久性会把 log buffer 中的日志全部刷到磁盘。注意这时候除了本事务的可能还会刷入其它事务的日志。3后台线程输入有一个后台线程大约每秒都会刷新一次log buffer中的redo log到磁盘。4正常关闭服务器时5触发 checkpoint 规则4.5.check point规则重做日志缓存、重做日志文件都是以块block的方式进行保存的称之为重做日志块redo log block,块的大小是固定的 512 字节。我们的 redo log 它是固定大小的可以看作是一个逻辑上的 log group由一定数量的log block 组成。它的写入方式是从头到尾开始写写到末尾又回到开头循环写。其中有两个标记位置write pos是当前记录的位置一边写一边后移写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint是当前要擦除的位置也是往后推移并且循环的擦除记录前要把记录更新到磁盘。当write_pos追上checkpoint时表示 redo log 日志已经写满。这时候就不能接着往里写数据了需要执行checkpoint规则腾出可写空间。所谓的checkpoint 规则就是checkpoint触发后将buffer中日志页都刷到磁盘。