mysql之innodb日志管理

本文从两个方面进行阐述,常规的日志文件(不区分存储引擎),第二就是讲innodb存储引擎的事务日志。第三就是看下binlog日志和事务日志的对比。

一、基本日志文件

1.1、基本日志文件分类:
错误日志(error log)
慢查询日志日志(slow query log)
二进制日志(binlog)
查询日志(general log)

1.2、错误日志

主要包括mysql的启动,运行,关闭过程进行记录。

默认情况下以服务器的主机名命名`hostname`.err,可以通过参数--log-error=[file_name]指定
正在运行状态下删除错误日志后,不会自动创建错误日志,只有在刷新日志的时候才会创建一个新的错误日志文件。

查看错误日志:show variables like 'log_error';

日志刷新方法:
mysql> FLUSH LOGS;
shell> mysqladmin flush-logs
shell> mysqladmin refresh

1.3、一般查询日志

        查询日志分为一般查询日志和慢查询日志,通过参数long_query_time指定时间的值对其进行判定,如果在参数设定时间内完成查询,则为一般查询日志(建议关闭,因为太多),否则为慢查询日志。

#参数设定
--general_log={0|1} :是否开启一般查询日志
--general_log_file=file_name :指定一般查询日志的路径,默认名为`hostname.log`
log_output={TABLE|FILE|NONE} :设置一般查询日志和慢查询日志的输出格式,分别为(表|文件|不记录)

1.4、慢查询日志

      查询超出变量 long_query_time 指定时间值的为慢查询。mysql记录慢查询日志是在查询执行完毕且已经完全释放锁之后才记录的,因此慢查询日志记录的顺序和执行的SQL查询语句顺序可能会不一致

查看慢查询日志:show variables like '%slow_query_log%';

 

 

 执行语句

mysql>select sleep(10);

然后通过cat查看lgh3-slow.log日志:

 

 

 如果慢查询日志中有大量的数据,我们可以使用mysqldumpslow命令来查看分析慢日志文件:

[root@lgh3 mysql]# mysqldumpslow --help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]
Parse and summarize the MySQL slow query log. Options are
  --verbose    verbose
  --debug      debug
  --help       write this text to standard output
  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al,at,ar,c,l,r,t),'at' is default  #默认排序规则
                al: average lock time #平均锁定时间
                ar: average rows sent #平均返回记录时间
                at: average query time #平均查询时间
                 c: count  #记录数
                 l: lock time #锁定时间
                 r: rows sent #返回记录数
                 t: query time  #查询时间
  -r           reverse the sort order (largest last instead of first) #逆序排序
  -t NUM       just show the top n queries #top n
  -a           don't abstract all numbers to N and strings to 'S' #归类时不要使用N替换数字,S替换字符串
  -n NUM       abstract numbers with at least n digits within names
  -g PATTERN   grep: only consider stmts that include  string #匹配查询,同grep功能一样
  -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),default is '*',i.e. match all
  -i NAME      name of server instance (if using mysql.server startup script)
  -l           don't subtract lock time from total time

使用mysqldumpslow简单查看:明显省略掉了很多注释的东西

 

 

 

 

  相关参数:

#和慢查询的相关参数设定
log_throttle_queries_not_use_indexes=10 # 指定慢查询超时时长(默认10秒),超出此时长的属于慢查询
log_output={TABLE|FILE|NONE} # 定义一般查询日志和慢查询日志的输出格式,默认为file
log_slow_queries={yes|no} # 是否启用慢查询日志,默认不启用
slow_query_log={1|ON|0|OFF} # 也是是否启用慢查询日志,此变量和log_slow_queries修改一个另一个同时变化
slow_query_log_file=/mydata/data/hostname-slow.log #默认路径为库文件目录下主机名加上-slow.log
log_queries_not_using_indexes=OFF # 查询没有使用索引的时候是否也记入慢查询日志

1.5、二进制日志文件

        记录对mysql数据库执行了更改的所有操作,不包括select和show这样的操作,如果执行了update和delete这样的操作,但是没有引起数据库数据的任何变化,也可能被写入二进制日志文件中。
       二进制日志是以事件形式记录的,不是事务日志(但是也有可能是基于事务记录二进制日志的),对于事务表的操作,二进制日志只在事务提交的时候一次性写入(基于事务的innodb二进制日志),提交前的每个二进制日志记录都先cache,提交时写入。对于非事务表的操作,每次执行完语句就直接写入。

       mysql还创建一个二进制日志索引文件,当二进制日志文件滚动的时候会向该文件中写入对应的信息。所以该文件包含所有使用的二进制日志文件的文件名。默认情况下该文件与二进制日志文件的文件名相同,扩展名为'.index'。可以通过参数--log-bin-index[=file_name]指定文件名

 

 

 

1.5.1、二进制日志文件的作用
1、恢复:用户可以通过二进制文件的point-in-time进行恢复
2、复制:通过执行二进制的文件在远程的机器上恢复数据
3、审计:可以对二进制日志文件进行审计,判断是否有对数据库进行注入攻击

1.5.2、查看二进制文

1.使用mysqlbinlog工具。
2.使用show显示对应的信息。
SHOW {BINARY | MASTER} LOGS # 查看使用了哪些日志文件
SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] # 查看日志中进行了哪些操作
SHOW MASTER STATUS # 显式主服务器中的二进制日志信息

mysqlbinlog使用格式:

mysqlbinlog [option] log-file1 log-file2...

常用选项:

-d,--database=name:只查看指定数据库的日志操作
-o,--offset=#:忽略掉日志中的前n个操作命令
-r,--result-file=name:将输出的日志信息输出到指定的文件中,使用重定向也一样可以。
-s,--short-form:显示简单格式的日志,只记录一些普通的语句,会省略掉一些额外的信息如位置信息和时间信息以及基于行的日志。可以用来调试,生产环境千万不可使用
--set-charset=char_name:在输出日志信息到文件中时,在文件第一行加上set names char_name
--start-datetime,--stop-datetime:指定输出开始时间和结束时间内的所有日志信息
--start-position=#,--stop-position=#:指定输出开始位置和结束位置内的所有日志信息
-v,-vv:显示更详细信息,基于row的日志默认不会显示出来,此时使用-v或-vv可以查看

使用mysqlbinlog命令对mysql-bin.000001日志进行查看,如下:

[root@lgh3 mysql]# mysqlbinlog /data/binlog/mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0;
DELIMITER !;
# at 4
#190908 21:18:32 server id 1000  end_log_pos 123 CRC32 0x052f8ffd       Start: binlog v 4,server v 5.7.24-log created 190908 21:18:32 at startup
ROLLBACK;
BINLOG '
aKh1XQ/oAwAAdwAAAHsAAAAAAAQANS43LjI0LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABoqHVdEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
Af2PLwU=
'/*!*/;
# at 123
#190908 21:18:32 server id 1000  end_log_pos 154 CRC32 0x927edf95       Previous-GTIDs
# [empty]
# at 154
#190908 21:19:15 server id 1000  end_log_pos 219 CRC32 0xb05f419c       Anonymous_GTID  last_committed=0        sequence_number=1       rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS';
# at 219
#190908 21:19:15 server id 1000  end_log_pos 313 CRC32 0xaafce462       Query   thread_id=2     exec_time=0     error_code=0
SET TIMESTAMP=1567991955;
SET @@session.pseudo_thread_id=2;
SET @@session.foreign_key_checks=1,@@session.sql_auto_is_null=0,@@session.unique_checks=1,@@session.autocommit=1;
SET @@session.sql_mode=1075838976;
SET @@session.auto_increment_increment=1,@@session.auto_increment_offset=1!\C utf8mb4 *//*;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=45;
SET @@session.lc_time_names=0;
SET @@session.collation_database=DEFAULT;
create database test
313
#190908 21:19:53 server id 1000  end_log_pos 378 CRC32 0xdccfd8ec       Anonymous_GTID  last_committed=1        sequence_number=2       rbr_only=378
#190908 21:19:53 server id 1000  end_log_pos 497 CRC32 0x57a45727       Query   thread_id=2     exec_time=0     error_code=0
use `test`;
SET TIMESTAMP=1567991993;
create table gxt1(id int,name varchar(128))
497
#190908 21:20:17 server id 1000  end_log_pos 562 CRC32 0x316b41e9       Anonymous_GTID  last_committed=2        sequence_number=3       rbr_only=yes
!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'562end_log_pos 634 CRC32 0x693ee549       Query   thread_id=2     exec_time=0     error_code=0
SET TIMESTAMP=1567992017;
BEGIN
634
#190908 21:20:17 server id 1000  end_log_pos 684 CRC32 0xde906285       Table_map: `test`.`gxt1` mapped to number 108
# at 684 end_log_pos 734 CRC32 0xa0fc1d34       Write_rows: table id 108 flags: STMT_END_F

BINLOG '
0ah1XRPoAwAAMgAAAKwCAAAAAGwAAAAAAAEABHRlc3QABGd4dDEAAgMPAgACA4VikN4=
0ah1XR7oAwAAMgAAAN4CAAAAAGwAAAAAAAEAAgAC//wBAAAACAB6aGFuZ3NhbjQd/KA=
'/*!*/;
# at 734
#190908 21:20:17 server id 1000  end_log_pos 765 CRC32 0xc9208948       Xid = 10
COMMIT765
#190908 21:30:18 server id 1000  end_log_pos 812 CRC32 0xda645def       Rotate to mysql-bin.000002  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC'  added by mysqlbinlog */ ;
DELIMITER ;
# End of log file
!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

上面蓝色字体表示位置,红色表示时间。

SHOW BINARY LOGS ;

 

 

 SHOW MASTER LOGS ;

 

 

 show binlog events in 'mysql-bin.000001';

 

 

  SHOW MASTER STATUS;

 

 

 表示二进制文件已经记录到了第四个,位置为418.

1.5.3、二进制文件的删除

1.reset master将会删除所有日志,并让日志文件重新从000001开始。
mysql> reset master;

2.PURGE { BINARY | MASTER } LOGS { TO 'log_name' | BEFORE datetime_expr }
purge master logs to "binlog_name.00000X" 将会清空00000X之前的所有日志文件。例如删除000006之前的日志文件。
mysql> purge master logs to "mysql-bin.000006";
mysql> purge binary logs to "mysql-bin.000006";
master和binary是同义词

purge master logs before 'yyyy-mm-dd hh:mi:ss' 将会删除指定日期之前的所有日志。但是若指定的时间处在正在使用中的日志文件中,将无法进行purge。

3.使用--expire_logs_days=N选项指定过了多少天日志自动过期清空

1.5.4、相关参数

log-bin=on|off|file_name   #或者指定路径log-bin=/data/binlog/mysql-bin表示开启并设定路径,msyql5.7开启该参数必须分配server_id,否则mysql不能启动
server_id=1000     #指定server_id
max_binlog_size:  #(默认1G)指定一个二进制文件的最大值,如果超过该值,则产生一个新的二进制日志文件(考虑到事务不可能跨两个binlog文件,所以有时binlog文件的实际大小不会等于设定值)
binlog_cache_size: #(默认32k)存储所有未提交的二进制日志记录,用于缓存,当该事务提交了,则会写入到二进制日志文件中,如果该参数太小,可能)存储所有未提交的二进制日志记录,用于缓存,当该事务提交了,则会写入到二进制日志文件中,如果该参数太小,可能
                    #会写入到磁盘,影响性能,可以通过查看参数binlog_cache_disk_use,表示写磁盘的次数
sync_binlog:   #默认情况下,二进制日志不是每次写都会写入二进制日志文件中,(可以理解为缓冲)如果数据库异常宕机,就会存在二进制日志文件缺少记录的情况,可以通过参数sync_binlog=[N]来进行配置,当N=1时表示同步写磁盘的方式写二进制文件,这是不使用操作系统的缓冲来写日志。
               #N=0(默认),虽然设置sync_binlog=1理论上保证了同步,但是当使用innodb存储引擎时,会存在二进制记录了操作,但是事务由回滚了的情况,
               #可以通过参数innodb_support_xa=1来解决该问题,innodb_support_xa=1保证了二进制文件和存储引擎文件同步
binlog_do-db:   #记录该数据库
binlog_ingnore-db: #忽略该数据库
log_slave-update: #如果当前数据库时复制中的slave角色,不会把从master获取到的二进制日志写入到自己的二进制文件中,如果需要,则需要开启
                   #这个参数,如果搭建master=>slave=>slave的架构复制,则必须开启此参数
binlog_format:   #可以设置为如下的值
                 #statement:二进制日志文件都是记录的逻辑sql语句
                 #row:记录表行更改的情况,如果设置为该参数,可以将innodb存储引擎的事务隔离级别基本设置为READ COMMITTED,获得更好的并发,一般设置为row,虽然对磁盘和网络开销大一些,格式为二进制格式。使用mysqlbinlog工具查看
                 #mixed:mixed模式,默认使用statement配置

expire_logs_days : #指定自动删除二进制日志的时间,即日志过期时间
log_bin_index : #指定mysql-bin.index文件的路径
max_binlog_cache_size : #指定二进制日志缓存最大大小,硬限制。默认4G,够大了,建议不要改
binlog_cache_use:使用缓存写二进制日志的次数(这是一个实时变化的统计值)
binlog_cache_disk_use:使用临时文件写二进制日志的次数,当日志超过了binlog_cache_size的时候会使用临时文件写日志,如果该变量值不为0,则考虑增大binlog_cache_size的值

1.5.5、日志还原

方式一:直接还原
mysqlbinlog --stop-datetime="2014-7-2 15:27:48" /tmp/mysql-bin.000008 | mysql -u user -p password

方式二:先导入到一个文件然后恢复
mysqlbinlog mysql-bin.000001 > /tmp/a.sql
mysql -u root -p password -e "source /tm

 

二、事务日志

innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。

undo log不是redo log的逆向过程,其实它们都算是用来恢复的日志:
     1.redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。
    2.undo用来回滚行记录到某个版本。undo log一般是逻辑日志,根据每行记录进行记录

2.1、redo log

       redo log主要由重做日志缓冲(redo log buffer)和重做日志文件(redo log file)构成。缓冲数据存于内存,当机器异常或者服务异常会导致缓冲中的数据丢失,日志文件的数据存于磁盘,是持久化文件。

      重做日志就是通过先写入缓冲,然后刷新到磁盘的操作,那怎么能够保证数据不会丢失呢?

     我们可以通过参数innodb_flush_log_at_trx_commit进行控制,该参数有三个值,分别为0,1,2,在详细谅解这个参数之前,我们先了解下重做日志缓冲和重做日志文件的是如何同步的:确保每次日志都能写入到事务日志文件中,在每次将log buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MySQL是工作在用户空间的,MySQL的log buffer处于用户空间的内存中。要写入到磁盘上的log file中(redo:ib_logfile0和ib_logfile1文件,undo:share tablespace或.ibd文件),中间还要经过操作系统内核空间的os buffer,调用fsync()的作用就是将OS buffer中的日志刷到磁盘上的log file中。如下图所示:

 

 

接下来继续看  innodb_flush_log_at_trx_commit的值的意义:

    当设置为1的时候,事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO的性能较差。(推荐)
      当设置为0的时候,事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。
       当设置为2的时候,每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

 

 redo log是用来数据的crash recovery的,这是数据库保障数据安全的重要功能之一,保存着innodb表中的修改记录,所以也叫日志文件,在innodb存储引擎中,默认有两个日志文件,新建数据库后,会有名为ib_logfile0和ib_logfile1两个文件,如果在启动数据库时,两个文件不存在,则innodb会根据参数创建。

 

 日志文件是以类似循环的方式使用的,当第一个日志文件写满,会往第二个继续写,当所有日志文件写满,则会在第一个日志文件中清空一些空间出来,提供写空间,如下图所示:

 

       innodb中通过日志组来管理日志文件,是一个逻辑定义,它包含若干个日志文件,一组中的日志文件大小相等,大小通过参数设定。
参数innodb_log_files_group 决定,默认值为2,决定每个组有多少个日志文件。
参数innodb_log_group_home_dir,默认文mysql的database目录,决定日志文件存放的目录。

 

    日志组中的每个文件都有自己的格式,内部也是按照大小相同的页面切分,这里的页面大小是512字节,则是机械硬盘块的大小。这样的设计是为了提高数据写入的吞吐量和效率。并且日志将逻辑事务对数据库的分散随机写入转换为512字节整数倍的顺序写入,大大提高数据库写的性能,这也是数据库管理系统区别于文件管理系统的重要因素。

    既然说每个日志有很多个512字节的块组成,那么我们了解下每个日志文件的构成,如下图所示:

 

      如上图所示,一个日志文件包含很多个512字节的块,而每个块又分为三部分组成,分别为日志头,日志尾,和具体日志内容。其中日志头占用12字节,日志尾占用8字节,所以剩余的492字节为日志内容占用。

日志头包含4部分:
log_block_hdr_no:(4字节)该日志块在redo log buffer中的位置ID。
log_block_hdr_data_len:(2字节)该log block中已记录的log大小。写满该log block时为0x200,表示512字节。
log_block_first_rec_group:(2字节)该log block中第一个log的开始偏移位置。
lock_block_checkpoint_no:(4字节)写入检查点信息的位置

日志尾只有一个部分: log_block_trl_no ,该值和块头的 log_block_hdr_no 相等

接下来我们看看文件组:在每个组的第一个redo log file中,前2KB记录4个特定的部分,从2KB之后才开始记录log block。除了第一个redo log file中会记录,log group中的其他log file不会记录这2KB,但是却会腾出这2KB的空间。如下:

 

 我们知道重做日志的构成以及其作用之后,那重做日志是什么时间点从缓冲中刷新到日志文件的呢?接下来看看日志刷盘的时机。

日志刷盘时机主要有:

1、log buffer空间用完,
2、master主线程后台每秒刷新一次
3、在DML操作时,会检查日志空间是否足够,如果已经达到预设值,则刷新日志到磁盘
4、checkpoint时,保证所有要刷的数据页中的LSV最小值已经刷入到磁盘,
5、提交逻辑事务时,由参数innodb_flush_log_at_trx_commit 控制

上面提到的LSN称为日志的逻辑序列号(log sequence number),在innodb存储引擎中,lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。
根据LSN,可以获取到几个有用的信息:
1.数据页的版本信息。
2.写入的日志总量,通过LSN开始号码和结束号码可以计算出写入的日志量。
3.可知道检查点的位置。
实际上还可以获得很多隐式的信息。
LSN不仅存在于redo log中,还存在于数据页中,在每个数据页的头部,有一个fil_page_lsn记录了当前页最终的LSN值是多少。通过数据页中的LSN值和redo log中的LSN值比较,如果页中的LSN值小于redo log中LSN值,则表示数据丢失了一部分,这时候可以通过redo log的记录来恢复到redo log中记录的LSN值时的状态

可以通过:mysql> show engine innodb status\G;查看

 

 其中:

log sequence number就是当前的redo log(in buffer)中的lsn;
log flushed up to是刷到redo log file on disk中的lsn;
pages flushed up to是已经刷到磁盘数据页上的LSN;
last checkpoint at是上一次检查点所在位置的LSN

2.2、undo log

undo log有两个作用:提供回滚和多个行版本控制(MVCC)

    在数据修改的时候,不仅记录了redo,还记录了相对应的undo,如果因为某些原因导致事务失败或回滚了,可以借助该undo进行回滚。
    undo log和redo log记录物理日志不一样,它是逻辑日志。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。

    当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候,也是通过undo log来实现的:当读取的某一行被其他事务锁定时,它可以从undo log中分析出该行记录以前的数据是什么,从而提供该行版本信息,让用户实现非锁定一致性读取。undo log是采用段(segment)的方式来记录的,每个undo操作在记录的时候占用一个undo log segment。另外,undo log也会产生redo log,因为undo log也要实现持久性保护

    在事务提交的时候,会将该事务对应的undo log放入到删除列表中,未来通过purge来删除。并且提交事务时,还会判断undo log分配的页是否可以重用,如果可以重用,则会分配给后面来的事务,避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。

通过undo log记录delete和update操作的结果发现:(insert操作无需分析,就是插入行而已)
delete操作实际上不会直接删除,而是将delete对象打上delete flag,标记为删除,最终的删除操作是purge线程完成的。
update分为两种情况:update的列是否是主键列。
    如果不是主键列,在undo log中直接反向记录是如何update的。即update是直接进行的。
     如果是主键列,update分两部执行:先删除该行,再插入一行目标行

三、事务日志和binlog日志对比 

事务日志和binlog区别:

1、记录对象不一样:redo log是在记录存储引擎(innodb)的数据,而二进制文件时记录mysql的数据库更新数据相关的操作,可以是innodb,mymyisam等存储引擎。

2、记录内容不一样:binlog记录的一个事务的具体操作内容,是逻辑日志,redo log记录的是每个页的修改情况,是物理日志。

3、记录时间不一样:binlog仅仅在事务提交前jin进行提交,即只写磁盘一次,而redo log在事务的过程中不断的记录操作,写入redo log中。

4、记录格式不一样:binlog的记录方式和事务的提交顺序有关,而redo log中是记录的物理页的修改,redo log文件中同一个事务可能多次记录,最后一个提交的事务记录会覆盖所有未提交的事务记录。

5、事务日志记录的是物理页的情况,它具有幂等性,因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的。

binlog和事务日志的先后顺序及group commit:

    在提交事务的时候,如果存在修改数据,在提交事务的时候,则需要通过fsync()函数保证重做日志缓冲和重做日志文件的一致性,保证事务的持久性。但是当并发提交很多个事务的时候,就会存在每次提交一个事务,都会调用fsync函数刷新一次磁盘操作,这样的效率比较低,所以innodb存储引擎提供了group commit的功能,可以将多个事务的事务日志通过一次fsync()刷到磁盘中。

   提交事务时,在存储引擎层的上一层结构中会将事务按序放入一个队列,队列中的第一个事务称为leader,其他事务称为follower,leader控制着follower的行为。虽然顺序还是一样先刷二进制,再刷事务日志,但是机制完全改变了:保证即使开启了二进制日志,group commit也是有效的。

提交事务主要有如下三个步骤:

flush阶段:向内存中写入每个事务的二进制日志。
sync阶段:将内存中的二进制日志刷盘。若队列中有多个事务,那么仅一次fsync操作就完成了二进制日志的刷盘操作。称为BLGC(binary log group commit)。
commit阶段:leader根据顺序调用存储引擎层事务的提交。

参考:感谢如下作者的优质文章

https://www.cnblogs.com/f-ck-need-u/p/9010872.html#auto_id_12

https://www.cnblogs.com/f-ck-need-u/p/9001061.html

《mysql运维内参》

《mysql技术内幕:innodb存储引擎》

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


navicat查看某个表的所有字段的详细信息 navicat设计表只能一次查看一个字段的备注信息,那怎么才能做到一次性查询表的信息呢?SELECT COLUMN_NAME,COLUMN_COMMENT,COLUMN_TYPE,COLUMN_KEY FROM information_schema.CO
文章浏览阅读4.3k次。转载请把头部出处链接和尾部二维码一起转载,本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/52768613前言:数据库每天的数据不断增多,自动删除机制总体风险太大,想保留更多历史性的数据供查询,于是从小的hbase换到大的hbase上,势在必行。今天记录下这次数据仓库迁移。看下Agenda:彻底卸载MySQL安装MySQL_linux服务器进行数据迁移
文章浏览阅读488次。恢复步骤概要备份frm、ibd文件如果mysql版本发生变化,安装回原本的mysql版本创建和原本库名一致新库,字符集都要保持一样通过frm获取到原先的表结构,通过的得到的表结构创建一个和原先结构一样的空表。使用“ALTER TABLE DISCARD TABLESPACE;”命令卸载掉表空间将原先的ibd拷贝到mysql的仓库下添加用户权限 “chown . .ibd”,如果是操作和mysql的使用权限一致可以跳过通过“ALTER TABLE IMPORT TABLESPACE;”命令恢_alter table discard tablespace
文章浏览阅读225次。当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化:单表优化除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量:字段尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNEDVARCHAR的长度只分配_开发项目 浏览记录表 过大怎么办
文章浏览阅读1.5k次。Mysql创建、删除用户MySql中添加用户,新建数据库,用户授权,删除用户,修改密码(注意每行后边都跟个;表示一个命令语句结束):1.新建用户登录MYSQL:@>mysql -u root -p@>密码创建用户:mysql> insert into mysql.user(Host,User,Password) values("localhost_删除mysql用户组
MySQL是一种开源的关系型数据库管理系统,被广泛应用于各类应用程序的开发中。对于MySQL中的字段,我们需要进行数据类型以及默认值的设置,这对于数据的存储和使用至关重要。其中,有一个非常重要的概念就是MySQL字段默认字符串。 CREATE TABLE `my_...
MySQL是一个流行的开源关系型数据库管理系统,广泛应用于Web应用程序开发、数据存储和管理。在使用MySQL时,正确设置字符集非常重要,以确保数据的正确性和可靠性。 在MySQL中,字符集表示为一系列字符和字母的集合。MySQL支持多种字符集,包括ASCII、UTF...
MySQL存储函数 n以内偶数 MySQL存储函数能够帮助用户简化操作,提高效率,常常被用于计算和处理数据。下面我们就来了解一下如何使用MySQL存储函数计算n以内的偶数。 定义存储函数 首先,我们需要定义一个MySQL存储函数,以计算n以内的偶数。下...
MySQL是一个流行的关系型数据库管理系统,基于客户机-服务器模式,可在各种操作系统上运行。 MySQL支持多种字符集,不同的字符集包括不同的字符,如字母、数字、符号等,并提供不同的排序规则,以满足不同语言环境的需求。 //查看MySQL支持的字符集与校对规...
在MySQL数据库中,我们有时需要对特定的字符串进行截取并进行分组统计。这种操作对于数据分析和报表制作有着重要的应用。下面我们将讲解一些基本的字符串截取和分组统计的方法。 首先,我们可以使用substring函数对字段中的字符串进行截取。假设我们有一张表stude...
MySQL提供了多种字符串的查找函数。下面我们就一一介绍。 1. LIKE函数 SELECT * FROM mytable WHERE mycolumn LIKE 'apple%'; 其中"apple%"表示以apple开头的字符串,%表示任意多个字符...
MySQL 是一种关系型数据库管理系统,广泛应用于各种不同规模和类型的应用程序中。在 MySQL 中,处理字符串数据是很常见的任务。有时候,我们需要在字符串的开头添加一定数量的 0 ,以达到一定的位数。比如,我们可能需要将一个数字转换为 4 位或 5 位的字符串,不足的...
MySQL是一种流行的关系型数据库管理系统,支持多种数据类型。以下是MySQL所支持的数据类型: 1. 数值型数据类型: - TINYINT 保存-128到127范围内的整数 - SMALLINT 保存-32768到32767范围内的整数 - MEDIU...
MySQL中存储Emoji表情字段类型 在现代互联网生态中,表情符号已经成为人们展示情感和思想的重要方式之一,因此将表情符号存储到数据库中是一个经常出现的问题。MySQL作为最流行的开源关系型数据库管理系统之一,也需要能够存储和管理这些表情符号的字段类型。 UT...
MySQL是一种关系型数据库管理系统。在MySQL数据库中,有多种不同的数据类型。而其中,最常见的数据类型之一就是字符串类型。在MySQL中,字符串类型的数据通常会被存储为TEXT或VARCHAR类型。 首先,让我们来看一下VARCHAR类型。VARCHAR是My...
MySQL字符串取整知识详解 MySQL是一种开源的关系型数据库管理系统,广泛应用于各个领域。在使用MySQL过程当中,我们经常需要对数据进行取整操作。本文将介绍如何使用MySQL字符串取整来处理数据取整问题。 什么是MySQL字符串取整? MySQL...
使用MySQL进行数据存储是现代应用程序开发中一个非常重要的组成部分。在MySQL中,数据存储的一个重要特点就是字符长度无限制。在下文中,我们将会详细探讨MySQL字符长度无限制的特征和优势。 什么是MySQL字符长度无限制? MySQL字符长度无限制是指在...
在MySQL中,常常会涉及到字符串和数字之间的比较。然而它们有着不同的排序规则,因此需要注意对它们进行正确的比较。 首先我们来看一下数字比较。 SELECT 1 < 2; -- 返回 1 SELECT 2 > 1; -- 返回 1 SELEC...
MySQL是一种流行的关系型数据库管理系统,可以处理各种不同类型的数据。其中字符串是MySQL中最重要的数据类型之一,因为它可以存储各种不同的数据,例如邮件地址、文本信息、数字等等。在MySQL中,有时候我们需要将字符串按照某个符合进行分隔,例如将一条包含多个数字的字符...
在MySQL中,我们经常需要将字符串与变量拼接起来,以便满足数据操作的需求。可以使用CONCAT函数来进行字符串与变量的拼接,下面是一个使用CONCAT函数的例子: SELECT CONCAT('Hello', ' ', 'world'); 这个例子...