MySQL的几个重要配置参数

学习东西需要了解其体系，最近我刚好在学习这块的东西，也简单的做了一些笔记，总结出来分享给大家。

1、配置通用查询日志，需要在配置文件my.cnf中增加如下：

(1) 在mysql的安装目录下，修改my.cnf配置文件，增加general_log = 1

备注：当general_log 参数功能打开时，可以用来追踪相关语句。

2、配置慢查询日志，需要在配置文件my.cnf增加如下参数：

slow_query_log = 1

备注：增加配置参数后，需要重新启动mysql。

3、配置mysql的错误日志，需要在my.cnf中追加路径，增加参数后需要重启mysql。

log_error = /home/mysql.err

4、my.cnf配置文件中增加no-auto-rehash参数，可以确保mysql的服务在启动的时候速度能够更快。

5、影响MySQL中redo的配置参数：

innodb_log_file_size：指定每个redo日志大小，默认值48MB

innodb_log_files_in_group：指定日志文件组中redo日志文件数量，默认为2

innodb_log_group_home_dir：指定日志文件组所在路劲，默认值./，指mysql的数据目录datadir

6、查看innodb配置：show variables like 'innodb%log%';

7、binlog：binlog记录了对MySQL数据库执行更改的所有操作mysql配置，但是不包括SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改。然后，若操作本身并没有导致数据库发生变化，那么该操作也会写入二进制日志。比如在数据库中执行了一条update语句，但是并没有给数据库带来变化，也会记录在binlog中。

8、影响binlog的参数：

max_binlog_size:指定单个binlog文件最大值。默认值为1g，最大值1g，如果超过该值，则产生新的binlog文件，后缀名+1，并记录到.index文件。

binlog_cache_size：使用事务表存储引擎（如innodb存储引擎）时，所有未提交的binlog日志会被记录到一个缓存中去，等事务提交时再将缓存中的binlog写入到binlog文件中。缓存的大小由binlog_cache_size决定，默认大小为32K。binlog_cache_size是基于session的，也就是说，当一个线程开始一个事务时，MySQL会自动分配一个大小为binlog_cache_size的缓存，因此该值的设置需要非常小心，不能设置过大。当一个事务的记录大于设定的binlog_cache_size时，MySQL会把缓存中的日志写入一个临时文件中，因此该值又不能设的太小。

max_binlog_cache_size:如果事务需要的内存超过很多字节，则服务器会生成多于“max_binlog_cache_size”字节的存储错误所需的并发事务。 最小值为4096字节，最大可能值为16EB（exabytes）。建议的最大值为4GB; 这是因为MySQL目前无法使用大于4GB的二进制日志位置。

expire_logs_days：表示binlog文件自动删除N天前的文件。默认值为0，表示不自动删除，最大值99.要手动删除binlog文件，可以使用purge binary logs语句。

binlog_rows_query_log_events：默认为不启用，启用binlog_rows_query_log_events时，会在binlog日志中记录原始SQL语句。

sync_binlog：sync_binlog=[N]表示没写缓冲N次就同步到磁盘，如果将N设为1，即sync_binlog表示采用同步写磁盘的方式来写二进制日志，在MySQL5.7.7后，默认为1。会对数据库的IO系统带来一定影响，但可以得到最大的高可用行。

binlog_checksum：该参数目的就是写入binlog进行校验，有两个值[crc32|none],默认为crc32

binlog-do-db：表示需要写入日志的数据库，默认为空，表示同步所有库

binlog-ignore-db：表示忽略写入日志的数据库，默认为空，表示同步所有库

log-slave-update:表示从master端取得并执行的binlog，写入自己的binlog文件中，一般应用在master=>slave=>slave架构

binlog_format：记录binlog的格式。[statement,row,mixed],在MySQL5.7.7之后，默认为row。

解析binlog（row格式）

mysqlbinlog -v --base64-output=decode-rows解析

9. redo log与binlog的区别

第一:redo log是在InnoDB存储引擎层产生，而binlog是MySQL数据库的上层产生的，并且二进制日志不仅仅针对INNODB存储引擎，MySQL数据库中的任何存储引擎对于数据库的更改都会产生二进制日志。

第二：两种日志记录的内容形式不同。MySQL的binlog是逻辑日志，其记录是对应的SQL语句。而innodb存储引擎层面的重做日志是物理日志。

第三：两种日志与记录写入磁盘的时间点不同，二进制日志只在事务提交完成后进行一次写入。而innodb存储引擎的重做日志在事务进行中不断地被写入，并日志不是随事务提交的顺序进行写入的。二进制日志仅在事务提交时记录，并且对于每一个事务，仅在事务提交时记录，并且对于每一个事务，仅包含对应事务的一个日志。而对于innodb存储引擎的重做日志，由于其记录是物理操作日志，因此每个事务对应多个日志条目，并且事务的重做日志写入是并发的，并非在事务提交时写入，其在文件中记录的顺序并非是事务开始的顺序。

第四：binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。

第五：binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。

今天还和同事聊起了极客时间，从初创型创业公司一路做到了 it 行业付费垂直领域的翘楚，一路成长起来，确实很给力。有它的执着，刚好我也有一股执着的劲，不禁唏嘘许多。

今天刚好他们出版了一款不错的课程《透视 HTTP 协议》，360 骨灰级大佬带你玩转 http 协议，作者对 Nginx 开源项目做出了较大的贡献。老规矩，从我这里购买的读者，可以加入我的付费社群《高哥织梦圈》。建议读者理性购买、感性学习。买来不看的那还是不用买了，毕竟买课程不是一锤子买卖（偷笑）。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!