MySQL日志分类及简介 - 版本历史

Eijux：/* 事务日志 */

2021-04-27T14:02:36Z

事务日志

←上一版本		2021年4月27日 (二) 22:02的版本
第26行：		第26行：
	! style="width: 50%;" \| 与回滚日志（undo log）		! style="width: 50%;" \| 与回滚日志（undo log）
	\|-		\|-
	\| ~~物理日志（存储实际数据）~~		\| 物理日志（存储更新的数据）
	\| ~~逻辑日志（存储SQL语句）~~		\| 逻辑日志（存储SQL操作语句）
	\|-		\|-
	\| 用于：		\| 用于：

Eijux：/* 事务日志 */

2021-04-27T14:01:23Z

事务日志

←上一版本		2021年4月27日 (二) 22:01的版本
第51行：		第51行：
	\|}		\|}
	* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。		* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。
			* 另一说 redo log 属于“Physiological Logging”，见：“'''[[逻辑日志与物理日志]]'''”。

Eijux：/* 关于“事务日志缓存”与“事务日志文件” */

2021-04-27T10:06:52Z

关于“事务日志缓存”与“事务日志文件”

←上一版本		2021年4月27日 (二) 18:06的版本
第88行：		第88行：

	==== 如何将“事务日志缓存写入磁盘”？ ====		==== 如何将“事务日志缓存写入磁盘”？ ====
	为了确保每次日志都能写入到事务日志文件中，在每次将 log buffer 中的日志写入日志文件的过程中都会调用一次操作系统的'''fsync'''操作【即“fsync()~~”系统调用】。~~		为了确保每次日志都能写入到事务日志文件中，在每次将 log buffer 中的日志写入日志文件的过程中都会调用一次操作系统的'''fsync'''操作【即“fsync()”系统调用：'''系统I/O同步函数'''】。
	: 因为 MariaDB/MySQL 是工作在用户空间的，MariaDB/MySQL 的 log buffer 处于用户空间的内存中。要写入到磁盘上的 log file 中，中间还要经过操作系统内核空间的 os buffer，'''调用“fsync()”的作用就是将 OS buffer 中的日志刷到磁盘上的 log file 中'''。		: 因为 MariaDB/MySQL 是工作在用户空间的，MariaDB/MySQL 的 log buffer 处于用户空间的内存中。要写入到磁盘上的 log file 中，中间还要经过操作系统内核空间的 os buffer，'''调用“fsync()”的作用就是将 OS buffer 中的日志刷到磁盘上的 log file 中'''。
	: 从 log buffer 写日志到磁盘的 log file 中，过程如下：		: 从 log buffer 写日志到磁盘的 log file 中，过程如下：

Eijux：/* 事务日志 */

2021-04-27T10:04:23Z

事务日志

←上一版本		2021年4月27日 (二) 18:04的版本
第29行：		第29行：
	\| 逻辑日志（存储SQL语句）		\| 逻辑日志（存储SQL语句）
	\|-		\|-
	~~\| 用于：事务持久化（存储）~~
	\| 用于：		\| 用于：
	# ~~提供回滚；~~		: 事务持久化（存储脏块数据记录）
			\| 用于：
			# 提供回滚；（即对事务原子性提供支持）
	# 实现 MVCC 的数据行快照。		# 实现 MVCC 的数据行快照。
	\|-		\|-
第163行：		第164行：
	==== 作用 ====		==== 作用 ====
	undo log 有两个作用：		undo log 有两个作用：
	# '''提供回滚'''；		# '''提供回滚'''；（对事务原子性提供支持）
	#: 当执行 rollback 时，就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。		#: 当执行 rollback 时，就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。
	# '''多个行版本控制'''（MVCC）。		# '''多个行版本控制'''（MVCC）。

Eijux：/* 事务日志 */

2021-04-27T10:01:45Z

事务日志

←上一版本		2021年4月27日 (二) 18:01的版本
第50行：		第50行：
	\|}		\|}
	* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。		* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。


			'''示例：'''【】
			<syntaxhighlight lang="mysql" highlight="17-19">
			假设有x、y两个数据，值分别为1,2.

			A.事务开始.

			B.记录x=1到undolog.

			C.修改x=3.

			D.记录x=3到redolog.

			E.记录y=2到undolog.

			F.修改y=4.

			G.记录y=4到redolog.

			H.将redolog写入磁盘。

			I.事务提交
			</syntaxhighlight>
			如上：
			# redo log：用于事务持久化
			## 为了保证持久性，必须在事务提交前将 redo log 持久化。
			## 数据不需要在事务提交前写入磁盘，而是缓存在内存中。
			# undo log：提供事务回滚
			## I/O 影响：其中“B”、“D”、“E”、“G”均是内存中 log buffer 的操作，只有“H”进行了I/O操作。

	=== 关于“事务日志缓存”与“事务日志文件” ===		=== 关于“事务日志缓存”与“事务日志文件” ===
第87行：		第117行：
	上述两项变量的设置保证了：每次提交事务都写入二进制日志和事务日志，并在提交时将它们刷新到磁盘中。		上述两项变量的设置保证了：每次提交事务都写入二进制日志和事务日志，并在提交时将它们刷新到磁盘中。

	=== 重做日志（redo log） ===		=== '''重做日志（redo log）''' ===
	----		----
	redo log 包括两部分：		redo log 包括两部分：
第94行：		第124行：

	==== 作用 ====		==== 作用 ====
	# ~~减少事务开销：~~		redo log 有两个作用：
	#: ~~InnoDB 使用~~ redo log ~~来减少提交事务时的开销：因为日志中已经记录了事务，就无须在每个事务提交时把缓冲池的脏块刷新（flush）到磁盘中。~~		# '''事务持久化'''：数据不需要在事务提交前写入磁盘，而是缓存在内存中。'''一旦日志安全写到磁盘，事务就持久化了'''。
	# ~~减少磁盘开销：【？？？】~~		#: 因为日志中已经记录了事务，如果发生异常，InnoDB 可以重放日志并且恢复已经提交的事务。
	#: 事务修改的数据和索引通常会映射到表空间的随机位置，所以刷新这些变更到磁盘需要很多随机I/O。InnoDB 假设使用常规磁盘，随机I/O比顺序I/O昂贵得多，因为一个I/O请求需要时间把磁头移到正确的位置，然后等待磁盘上读出需要的部分，再转到开始位置。		# 减少磁盘I/O：【？？？】
	#~~: 而 InnoDB 用日志把随机I/O变成顺序I/O【？】。~~'''~~一旦日志安全写到磁盘，事务就持久化了~~'''~~，即使断电了，InnoDB 可以重放日志并且恢复已经提交的事务。~~
			==== 记录形式 ====
			redo log 实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此 redo log 实现上采用了'''大小固定，循环写入'''的方式，当写到结尾时，会回到开头循环写日志。如下图：
			* 默认情况下，在磁盘上由名为“ib_logfile0”和“ib_logfile1”的两个文件物理表示（以循环方式写入）.

			: [[File:redo log记录形式.jpg\|400px]]
			如上图：（顺时针）
			# “write pos”表示 redo log 当前记录的 LSN (逻辑序列号)位置；【从“write pos”开始写 redo log】
			# “check point”表示脏块更改记录刷盘后对应 redo log 所处的 LSN (逻辑序列号)位置。【从“check point”开始刷到数据表】
			# “write pos”到“check point”之间的部分是 redo log 空着的部分，用于记录新的记录；
			# “check point”到“write pos”之间是 redo log 待刷新的脏块的更改记录。
			当“write pos”追上“check point”时，会先推动“check point”向前移动，空出位置再记录新的日志。


			'''NOTE：'''
			* 因为 redo log 记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志（如 binlog）要快很多。
			* 启动 InnoDB 的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。
			* 重启 InnoDB 时，首先会检查磁盘中数据页的 LSN ，如果数据页的 LSN 小于日志中的 LSN ，则会从“check point”开始恢复。
			* 若在宕机前正处于“check point”的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的 LSN 大于日志中的 LSN，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。

	==== 参数 ====		==== 参数 ====
第110行：		第158行：
	* '''innodb_flush_log_at_trx_commit'''：【见上面：“何时将‘事务日志缓存写入磁盘’？”】		* '''innodb_flush_log_at_trx_commit'''：【见上面：“何时将‘事务日志缓存写入磁盘’？”】

	=== 回滚日志（undo log） ===		=== '''回滚日志（undo log）''' ===
	undo log 和 redo log 记录物理日志不一样，它是逻辑日志。可以认为当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录，反之亦然，当 update 一条记录时，它记录一条对应相反的 update 记录。		undo log 和 redo log 记录物理日志不一样，它是逻辑日志。可以认为当 delete 一条记录时，undo log 中会记录一条对应的 insert 记录，反之亦然，当 update 一条记录时，它记录一条对应相反的 update 记录。

	==== 作用 ====		==== 作用 ====
	undo log 有两个作用：		undo log 有两个作用：
	# ~~提供回滚；~~		# '''提供回滚'''；
	#: 当执行 rollback 时，就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。		#: 当执行 rollback 时，就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。
	# ~~多个行版本控制（MVCC）。~~		# '''多个行版本控制'''（MVCC）。
	#: 当读取的某一行被其他事务锁定时，它可以从 undo log 中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。		#: 当读取的某一行被其他事务锁定时，它可以从 undo log 中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

Eijux：/* 事务日志 */

2021-04-27T09:22:33Z

事务日志

←上一版本		2021年4月27日 (二) 17:22的版本
第23行：		第23行：
	{\| class="wikitable"		{\| class="wikitable"
	\|+ “redo log”与“undo log”		\|+ “redo log”与“undo log”
	! 重做日志（redo log） !! 与回滚日志（undo log）		! style="width: 50%;" \| 重做日志（redo log）
			! style="width: 50%;" \| 与回滚日志（undo log）
	\|-		\|-
	\| 物理日志（存储实际数据）		\| 物理日志（存储实际数据）
第33行：		第34行：
	# 实现 MVCC 的数据行快照。		# 实现 MVCC 的数据行快照。
	\|-		\|-
	\| 磁盘中：（不属于任何表空间，而是独立的物理文件）		\|
	文件名为：“ib_logfileN”（如：ib_logfile0，iblogfile1... iblogfilen）		# 磁盘中：（不属于任何表空间，而是独立的物理文件）
	* 默认情况下，在磁盘上由名为“ib_logfile0”和“ib_logfile1”的两个文件物理表示（以循环方式写入）		# 文件名为：“ib_logfileN”（如：ib_logfile0，iblogfile1... iblogfilen）
	\| 磁盘中：位于“系统表空间”（System Tablespace）、“撤消表空间”（Undo Tablespace）、“临时表空间”（temporary tablespace）中		:* 默认情况下，在磁盘上由名为“ib_logfile0”和“ib_logfile1”的两个文件物理表示（以循环方式写入）
	文件名为：“.ibd”		\|
	* 撤消日志存在于撤消日志段中，包含在 rollback segments 中。		# 磁盘中：位于“系统表空间”（System Tablespace）、“撤消表空间”（Undo Tablespace）、“临时表空间”（temporary tablespace）中
			# 文件名为：“.ibd”
			:* 撤消日志存在于撤消日志段中，包含在 rollback segments 中。
	\|-		\|-
	\| colspan="2" \|		\| colspan="2" \|
	# 都在内存中具有缓存（“Log Buffer”中），		# 都在内存中具有缓存（“Log Buffer”中），
	# 都在磁盘具有日志文件（但位置不同），		# 都在磁盘具有日志文件（但位置不同），
	都是将日志缓存通过“OS Cache”写入到磁盘日志文件中。		# 都是将日志缓存通过“OS Cache”写入到磁盘日志文件中。
	* 见：“'''[[InnoDB：InnoDB 体系结构]]'''”		:* 见：“'''[[InnoDB：InnoDB 体系结构]]'''”
	\|}		\|}
	* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。		* 在数据修改的时候，不仅记录了 redo log，还记录了相对应的 undo log。

Eijux：/* 事务日志 */

2021-04-27T09:12:21Z

事务日志

显示更改

Eijux：/* 慢查询日志（slow query log） */

2021-04-27T04:44:43Z

慢查询日志（slow query log）

←上一版本		2021年4月27日 (二) 12:44的版本
第308行：		第308行：

	== '''慢查询日志'''（slow query log） ==		== '''慢查询日志'''（slow query log） ==
			慢查询会导致CPU，IOPS，内存消耗过高。当数据库遇到性能瓶颈时，大部分时间都是由于慢查询导致的。开启慢查询日志，可以让MySQL记录下查询超过指定时间的语句，之后运维人员通过定位分析，能够很好的优化数据库性能。
			* '''慢查询'''：（同“查询日志”的“查询”），不仅是执行比较慢的“SELECT”语句，还有“INSERT”，“DELETE”，“UPDATE”，“CALL”等 DML 操作，只要超过了指定时间，都可以称为“慢查询”，被记录到慢查询日志中。


			=== 相关参数 ===
			* '''slow_query_log'''：慢查询开关，表示是否打开慢查询日志。
			*# 通过系统变量设置：（只对当前数据库有效，如果 MySQL 数据库重启后就会失效）
			*#: <syntaxhighlight lang="mysql" highlight="">
			mysql> show variables like "%slow%";
			+---------------------------+-------------------------------------------------+
			\| Variable_name \| Value \|
			+---------------------------+-------------------------------------------------+
			\| log_slow_admin_statements \| OFF \|
			\| log_slow_slave_statements \| OFF \|
			\| slow_launch_time \| 2 \|
			\| slow_query_log \| OFF \|
			\| slow_query_log_file \| /var/lib/mysql/iz2zeaf3cg1099kiidi06mz-slow.log \|
			+---------------------------+-------------------------------------------------+
			5 rows in set (0.00 sec)

			# 打开慢查询
			mysql> set global slow_query_log='ON';
			Query OK, 0 rows affected (0.00 sec)


			mysql> show variables like "slow_query_log";
			+---------------------------+-------------------------------------------------+
			\| Variable_name \| Value \|
			+---------------------------+-------------------------------------------------+ \|
			\| slow_query_log \| ON \|
			\| slow_query_log_file \| /var/lib/mysql/iz2zeaf3cg1099kiidi06mz-slow.log \|
			+---------------------------+-------------------------------------------------+
			2 rows in set (0.00 sec)
			</syntaxhighlight>
			*# 通过配置文件“my.cnf”设置：（永久有效）
			**: <syntaxhighlight lang="mysql" highlight="">
			[mysqld]
			slow_query_log=1
			</syntaxhighlight>
			* '''long_query_time'''：慢查询指定时间设置，表示“多长时间的查询”被认定为“慢查询”，单位是秒（s），默认是'''10s'''，即超过 10s 的查询都被认定为慢查询。
			*: <syntaxhighlight lang="mysql" highlight="">
			mysql> show variables like 'long_query_time';
			+-----------------+-----------+
			\| Variable_name \| Value \|
			+-----------------+-----------+
			\| long_query_time \| 10.000000 \|
			+-----------------+-----------+
			1 row in set (0.00 sec)

			# 设置慢查询时间
			mysql> set global long_query_time=0.05;
			Query OK, 0 rows affected (0.00 sec)
			</syntaxhighlight>
			** 设置 long_query_time 阈值之后，MySQL 数据库会记录运行时间超过该值的所有 SQL 语句，但对于运行时间正好等于 long_query_time 的情况，并不会被记录下。
			** 设置“long_query_time=0”用于捕获所有的查询。
			* '''log_queries_not_using_indexes'''：表示如果运行的 SQL 语句“没有使用到索引”，是否也被当作慢查询语句记录到慢查询记录中（OFF / ON）。
			*: <syntaxhighlight lang="mysql" highlight="">
			mysql> show variables like 'log_queries_not_using_indexes';
			+-------------------------------+-------+
			\| Variable_name \| Value \|
			+-------------------------------+-------+
			\| log_queries_not_using_indexes \| ON \|
			+-------------------------------+-------+
			1 row in set (0.12 sec)
			</syntaxhighlight>
			*:
			**
			* '''slow_query_log_file'''：当使用文件存储慢查询日志时（“log_output”设置为“FILE”或者“FILE,TABLE”时），制定慢查询日志存储在哪个文件中。
			*: 默认的文件名是“主机名-slow.log”，存储目录为数据目录。
			*: <syntaxhighlight lang="mysql" highlight="">
			mysql> show variables like "log_output";
			+---------------+-------+
			\| Variable_name \| Value \|
			+---------------+-------+
			\| log_output \| FILE \|
			+---------------+-------+
			1 row in set (0.19 sec)
			</syntaxhighlight>
			** MySQL 5.1 将慢查询记录到文件中时已经支持微秒级别，如果将慢查询记录到表中会导致时间粒度退化为只能到秒级【？？】
			* '''log_throttle_queries_not_using_indexes'''：用来限制没有使用索引的语句每分钟记录到慢查询日志中的次数。（MySQL5.6.5版本新引入）
			*: 在生产环境中，有可能有很多没有使用索引的语句，可能会导致慢查询日志快速增长。

			=== 分析工具 pt-query-digest【？？？】 ===
			pt-query-digest 是分析MySQL查询日志最有力的工具，该工具功能强大，它可以分析 binlog，Generallog，slowlog，也可以通过“show processlist”或者通过 tcpdump 抓取的 MySQL 协议数据来进行分析，比 mysqldumpslow 更具体，更完善。


			以下是使用 pt-query-digest 的示例：
			<syntaxhighlight lang="mysql" highlight="">
			//直接分析慢查询文件
			pt-query-digest slow.log > slow_report.log
			</syntaxhighlight>
			该工具可以将查询的剖析报告打印出来，可以分析结果输出到文件中，分析过程是先对查询语句的条件进行参数化，然后对参数化以后的查询进行分组统计，统计出各查询的执行时间，次数，占比等，可以借助分析结果找出问题进行优化。

	== 中继日志（relay log） ==		== 中继日志（relay log） ==

Eijux：/* 查询日志归档 */

2021-04-27T04:28:12Z

查询日志归档

←上一版本		2021年4月27日 (二) 12:28的版本
第306行：		第306行：
	Enter password:		Enter password:
	</syntaxhighlight>		</syntaxhighlight>

			== '''慢查询日志'''（slow query log） ==

	== 中继日志（relay log） ==		== 中继日志（relay log） ==

Eijux：/* 慢查询日志（slow query log） */

2021-04-27T04:27:51Z

慢查询日志（slow query log）

←上一版本		2021年4月27日 (二) 12:27的版本
第154行：		第154行：
	</syntaxhighlight>		</syntaxhighlight>

	~~== '''慢查询日志'''（slow query log） ==~~
	== 查询日志（general log） ==		== 查询日志（general log） ==
	查询日志在 MySQL中被称为 general log（通用日志）。		查询日志在 MySQL中被称为 general log（通用日志）。

MySQL日志分类及简介 - 版本历史

Eijux：​/* 事务日志 */

Eijux：​/* 事务日志 */

Eijux：​/* 关于“事务日志缓存”与“事务日志文件” */

Eijux：​/* 事务日志 */

Eijux：​/* 事务日志 */

Eijux：​/* 事务日志 */

Eijux：​/* 事务日志 */

Eijux：​/* 慢查询日志（slow query log） */

Eijux：​/* 查询日志归档 */

Eijux：​/* 慢查询日志（slow query log） */

Eijux：/* 事务日志 */

Eijux：/* 事务日志 */

Eijux：/* 关于“事务日志缓存”与“事务日志文件” */

Eijux：/* 事务日志 */

Eijux：/* 事务日志 */

Eijux：/* 事务日志 */

Eijux：/* 事务日志 */

Eijux：/* 慢查询日志（slow query log） */

Eijux：/* 查询日志归档 */

Eijux：/* 慢查询日志（slow query log） */