开发中常用的数据库日志都长啥样呢？
目录
常见日志级别
数据库日志
Undo log 逻辑日志
redolog binlog
慢查询日志
AOF 文本文件
RDB 二进制文件
常见日志级别
-
DEBUG：用于详细记录应用程序的运行过程，如变量值、执行流程等。DEBUG级别的日志通常用于开发和调试过程中，以便于了解程序的内部运行状态。
-
INFO：用于记录应用程序的一般信息，如状态变更、操作结果等。INFO级别的日志通常用于生产环境中，以便于了解应用程序的运行状况。
-
WARNING：用于记录可能导致问题的事件，如性能瓶颈、配置错误等。WARNING级别的日志通常用于提醒开发者关注潜在的问题和风险。
-
ERROR：用于记录应用程序运行过程中出现的错误和异常。ERROR级别的日志通常包含错误发生的时间、位置、详细描述和堆栈跟踪等信息，以便于问题排查。
-
CRITICAL：用于记录应用程序中的严重错误和问题，如数据丢失、系统崩溃等。CRITICAL级别的日志通常用于处理紧急情况和重大事件。
这些日志级别通常按照从低到高的顺序排列，即DEBUG < INFO < WARNING < ERROR < CRITICAL。在配置logging库时，可以设置日志记录的最低级别，以便于过滤不需要的日志信息。
数据库日志
先讲一下三种日志类型（主要区别在于记录的信息和恢复数据的方式）：
-
逻辑日志（Logical Log）：逻辑日志记录了数据库操作的高级描述，例如插入、更新和删除操作。逻辑日志关注数据的变更内容，而不关注底层数据结构的改变。
UndoLog就是一种逻辑日志，它记录了对数据库表的操作，以便在需要时撤销这些操作。 -
物理日志（Physical Log）：物理日志记录了数据库底层数据结构的改变，例如磁盘上的数据页的变化。物理日志关注数据存储的具体实现，而不关注数据的逻辑变更。物理日志通常用于数据库的故障恢复、备份等场景。
-
二进制日志（Binary Log，也称为Binlog）是MySQL数据库中用于记录数据库操作的一种日志文件。它记录了对数据库进行的所有更改操作（如插入、更新、删除等）以及这些操作发生的时间。二进制日志以二进制格式存储。在某种程度上类似逻辑日志，因为它记录了操作的高级描述。
Undo log 逻辑日志
实际上，UndoLog日志文件中的记录格式取决于你的应用程序需求和日志记录方式。通常，日志文件中的记录会以文本形式存储，每行一个记录，可以是JSON、CSV或其他自定义格式。以下是一个以JSON格式存储的UndoLog日志文件记录示例：
{"id": 1, "operation": "UPDATE", "timestamp": "2022-08-01T12:34:56Z", "table_name": "User", "primary_key": 1, "old_data": {"name": "Alice", "age": 25}, "new_data": {"name": "Alice", "age": 26}}
{"id": 2, "operation": "INSERT", "timestamp": "2022-08-01T12:35:30Z", "table_name": "User", "primary_key": 2, "old_data": null, "new_data": {"name": "Bob", "age": 30}}
{"id": 3, "operation": "DELETE", "timestamp": "2022-08-01T12:36:10Z", "table_name": "User", "primary_key": 3, "old_data": {"name": "Charlie", "age": 22}, "new_data": null} 示例中，日志文件包含3条UndoLog记录，分别是一条更新操作、一条插入操作和一条删除操作。每条记录都是一个JSON对象，占据一行。这种格式便于解析和处理。
redolog binlog
重做日志redo log和binlog 日志都是以二进制的形式保存的，不能直接“看”，
mysqlbinlog工具查看的binlog日志记录类似：
# at 4
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x12345678
Start: binlog v 4, server v 8.0.27-0ubuntu0.20.04.1-log created 211001 12:00:00 at startup
# at 123
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x23456789
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
BEGIN
/*!*/;
# at 456
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x34567890
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
UPDATE users SET age=26, last_login='2021-10-02 10:00:00' WHERE id=100
/*!*/;
# at 789
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x45678901
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
COMMIT
/*!*/; 而redo log主要用于数据库内部处理，通常不需要直接查看或分析。在需要恢复数据时，数据库管理系统会自动处理redo log。
慢查询日志
MySQL的慢查询日志记录了执行时间超过指定阈值的查询。慢查询日志可以帮助您发现性能瓶颈并优化数据库性能。慢查询日志的格式和内容可能因MySQL版本和配置而异，但通常包括查询的SQL语句、执行时间、锁定时间等信息。
简化的示例
# Time: 211001 12:00:00
# User@Host: example_user[example_user] @ localhost []
# Thread_id: 1 Schema: example_db Last_errno: 0 Killed: 0
# Query_time: 5.123456 Lock_time: 0.000123 Rows_sent: 1 Rows_examined: 1000 Rows_affected: 0
# Bytes_sent: 100 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: Yes Filesort_on_disk: No Merge_passes: 0
SET timestamp=1633080000;
SELECT * FROM example_table WHERE some_column = 'some_value'; 记录了一个SELECT操作，涉及到名为example_table的表。此操作的查询时间（Query_time）为5.123456秒，超过了慢查询阈值。慢查询日志还包含了其他元数据，如锁定时间（Lock_time）、发送的行数（Rows_sent）、查询类型（全表扫描、文件排序等）等。
启用慢查询日志并设置阈值，您需要在MySQL配置文件（如my.cnf或my.ini）中添加以下配置：
slow_query_log = 1
slow_query_log_file = /path/to/your/slow-query.log # 日志文件路径
long_query_time = 1 # 慢查询阈值设置为1sAOF 文本文件
AOF（Append Only File）属于Redis数据库的持久化日志。它记录了操作Redis的所有命令，以便在Redis服务器重启时恢复数据。AOF日志以文本格式存储，每一行都是一个Redis命令。通常具有 .aof 扩展名，例如 appendonly.aof。
*2
$6
SELECT
$1
0
*3
$3
SET
$3
key
$5
value
*3
$5
LPUSH
$6
mylist
$4
item 例中的AOF文件包含了三个Redis命令：SELECT 0（选择数据库0）、SET key value（设置键值对）和LPUSH mylist item（将元素推入列表）。当Redis服务器启动时，它会自动执行这些命令以恢复数据。
RDB 二进制文件
Redis的RDB（Redis Database）文件是一个二进制文件，用于存储Redis数据库在某个时间点的数据快照。RDB文件通常具有.rdb扩展名，例如dump.rdb。由于RDB是二进制格式，因此它的内容无法直接阅读。
RDB文件包含了Redis数据库中的键值对数据，以及一些元数据，如过期时间等。RDB文件的结构和格式由Redis内部实现，通常不需要关注。（虚晃一枪收尾）