共计 3397 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章给大家介绍 MySQL 中有哪些日志维护策略，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
日志类型：
MySQL 有几个不同的日志文件，可以帮助你找出 mysqld 内部发生的事情：
日志文件记入文件中的信息类型 错误日志记录启动、运行或停止时出现的问题 查询日志记录建立的客户端连接和执行的语句二进制日志记录所有更改数据的语句。主要用于复制和即时点恢复慢日志记录所有执行时间超过 long_query_time 秒的所有查询或不使用索引的查询事务日志记录 InnoDB 等支持事务的存储引擎执行事务时产生的日志
1. 启动慢查询日志：
MySQL 如果启用了 slow_query_log=ON 选项，就会记录执行时间超过 long_query_time(默认 10s)的查询(初使表锁定的时间不算作 执行 时间)。日志记录文件为 slow_query_log_file[=file_name]，如果没有给出 file_name 值， 默认为主机名，后缀为 -slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。
【这个可以在调试 mysql 性能的时候启用, 可以找出是哪个 sql 指令最浪费时间。生产环境中建议关闭】
2. 生产环境中关闭通用查询日志：
由 于打开通用查询日志是记录用户的所有操作，在生产环境中这个日志的量是非常大的，所以一般情况下都是不打开的，myslq 默认的该日志功能也是关闭的，在 特殊情况下才进行打开【一般只有在开发测试环境中，为了定位某些功能具体使用了哪些 SQL 语句的时候，才会在短时间段内打开该日志来做相应的分析。】
mysql set global general_log = 1; #1：启动通用查询日志，0：关闭通用查询日志
mysql show global variables like %general_log%
+------------------+----------------------------+ | Variable_name | Value | +------------------+----------------------------+ | general_log | ON | #是否启用了通用查询日志 | general_log_file | /var/run/mysqld/mysqld.log | # 日志路径 +------------------+----------------------------+2 rows in set (0.00 sec)
3. 定期备份二进制日志和 sql 数据：【本地一份，远程日志主机一份，存储主机一份】
在 my.cnf 中 log-bin = [filename]是启用二进制日志，默认以 [filename].000001 往上记录的，从启用 log-bin 之后【此时 *** 用 mysqldump 保存当前的 mysql 某个库的数据，因为二进制日志只是记录了从现在起到最近一次 mysql 当机重启中的所有 sql 语句】，mysql 就会开始记录每一个 sql 语句，一旦 mysql 因各种原因需要重启，则会产生新的二进制日志，000001 的后缀名会不断往上自加。若是在 mysql 当机期间 mysql 的数 据遭到了破坏(如磁盘损坏)，之前的数据全部都被破坏了，这时候这个备份策略就可以帮你挽回损失。你可以从二进制日志中恢复从开始到最近一次 mysql 重 启这段时间的数据。【二进制日志中记录的是每一个 sql 语句，可以用 mysqlbinlog [filename] 查看日志内容】
4.sync_binlog 全局变量的取值一定要合适：
默 认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器 (不仅仅是 MySQL 服务器) 崩溃，有可能二进制日志中 *** 的语句丢失了。要想防止这种情况，你可以使用 sync_binlog 全局变量(1 是最安全的值，但也是最慢的)，使二进制日志在每 N 次二进制日志写入后与硬盘同步。对非 事务表的更新执行完毕后立即保存到二进制日志中。
下面解释下 sync_binlog:
“sync_binlog”：这个参数是对于 MySQL 系统来说是至关重要的，他不仅影响到 Binlog 对 MySQL 所带来的性能损耗，而且还影响到 MySQL 中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache 中的信息到磁盘，而让 Filesystem 自行决定什么时候来做同步，或者 cache 满了之后才同步到磁盘。
sync_binlog=n，当每进行 n 次事务提交之后，MySQL 将进行一次 fsync 之类的磁盘同步指令来将 binlog_cache 中的数据强制写入磁盘。
在 MySQL 中系统默认的设置是 sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是 *** 的，但是风险也是 *** 的。因为一旦系 统 Crash，在 binlog_cache 中的所有 binlog 信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗 *** 的设置。因为当设置为 1 的时候，即使系统 Crash，也最多丢失 binlog_cache 中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看, 对于 高并发事务的系统来说,“sync_binlog”设置为 0 和设置为 1 的系统写入性能差距可能高达 5 倍甚至更多。
5. 如果数据库有很多的事务型操作，则建议把二进制日志的回滚上限设置大一些：
对于事务表，例如 BDB 或 InnoDB 表，所有更改表的更新 (UPDATE、DELETE 或 INSERT) 被缓存起来，直到服务器接收到 COMMIT 语句。在该点，执行完 COMMIT 之前，mysqld 将整个事务写入二进制日志。当处理事务的线程启动时，它为 缓冲查询分配 binlog_cache_size 大小的内存。如果语句大于该值，线程则打开临时文件来保存事务【所以如果 bunlog_cache_size 足够大，就避免了过多的磁盘的 I / O 操作, 可以把数据全部缓存在内存中】。线程结束后临时文件被删除。【“max_binlog_cache_size”：和 binlog_cache_size 相对应，但是所代表的是 binlog 能够使用的 *** cache 内存大小。当我们执行多语句事务的时候，max_binlog_cache_size 如果不够大的话，系统可能会报出“Multi- statementtransactionrequiredmorethan max_binlog_cache_size bytesofstorage”的错误。所以 *** 也把 max_binlog_cache_size 也调大些(具体多大看你的服务器了)】
6. 尽量把 max_binlog_size 设置大些
Binlog 日志 *** 值，一般来说设置为 512M 或者 1G，但不能超过 1G。该大小并不能非常严格控制 Binlog 大小，尤其是当到达 Binlog 比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有 SQL 都记录进入当前日志，直到该事务 结束。
7. 下面是 mysql 环境的情况：
mysql show variables like %binlog%
+--------------------------------+------------+ | Variable_name | Value | +--------------------------------+------------+
| binlog_cache_size | 1048576 |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size| 4294967295 |
| max_binlog_size| 1073741824 |
| sync_binlog| 0|
+--------------------------------+------------+
关于 MySQL 中有哪些日志维护策略就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
