MySQL内核月报 2014.09-MySQL· 引擎差异·create_time in status

背景

  在MySQL数据库中,我们利用show table status命令可以得到表的状态信息,其中一列信息为create_time,表示表的创建时间。对于不同的存储引擎(如InnoDB/MyISAM/MEMORY)我们都能得到create_time的数值。我们知道不同的存储引擎表的文件结构是不同的,因此实现表的创建时间create_time的机制也是不同的。下面着重探讨InnoDB和MyISAM在create_time上的区别。

实验

  我们先做一些实验来看看create_time的特点。在InnoDB引擎下创建一个表:


  在MyISAM引擎下也创建结构相同的一个表,如何可以更新create_time呢?我们在表上做以下3种操作,观察create_time的变化。

  1. 对表进行增删改查操作,InnoDB、MyISAM的create_time不变。

  2. 对表进行alter table add column e varchar(32),InnoDB、MyISAM的create_time都更新到当前时间。

  3. 对表进行truncate table tb,InnoDB的create_time不变、MyISAM的create_time更新到当前时间。

  通过这些操作我们发现虽然2种引擎的内部实现不同,但前2种操作的现象是一样的。对表进行增删改查并不重建表,因此create_time没有更新。而alter table会更新create_time的原因是新建了一个原表的副本,在副本上实现alter table的功能(增加新列等等),最后删除原表,用副本替代原表。因此alter table下create_time是原表副本的创建时间。

  第3种操作,两者的现象不同,这是为什么呢?我们从代码实现上分析原因。

show table status的create_time的实现

1.InnoDB

  在InnoDB下执行show table status获得create_time来自于代码:


  stats.create_time最终来自于以下代码的statinfo变量:


  stat为C语言的库函数,含义是将文件路径path定位的文件(TABLENAME.frm)的状态信息(包括了创建时间create_time)存入statinfo。

  通过对源码的分析,我们知道在InnoDB引擎,create_time来源于.frm文件的创建日期。在truncate table之后,InnoDB并没有重建.frm文件,因此show table status的create_time不变。

2. MyISAM下

  在MyISAM下执行show table status获得create_time来自于代码:


  对应的misam_info.create_time来源于:


  即MyISAM通过读.MYI文件来获得state信息(包含了create_time),也就是说MyISAM下show table status的create_time最终来源于MYI文件中的state信息。

  在MyISAM下,创建表(create table..)的create_time来源于以下代码:


  MyISAM下的create_time来源于share变量,每次执行这部分代码都会更新share.state.create_time。share是MyISAM引擎下的全局信息,share.state区间信息包含了键和数据文件长度、时间戳(即create_time)和打开表的次数等等参数。share.state会记入MYI文件,代码如下:


  执行truncate table也会经过以上2处的代码,更新.MYI文件的state区间的信息,然后show table status时读入.MYI文件最新的state信息(包含了create_time),因此create_time会被更新。

时间: 2024-10-03 08:14:25

MySQL内核月报 2014.09-MySQL· 引擎差异·create_time in status的相关文章

MySQL内核月报 2014.11-TokuDB· 引擎特性· FAST UPDATES

MySQL的update在执行时需要做read-modify-write: 操作路径还是比较长的,TokuDB提供了fast update语法,让"某些"场景下update更快,无需做read和modify直接write. 用法: NOAR语句: 语义是:插入一条记录,如果该记录存在(id为1),就对count的值做加法操作,不存在则做插入. 注意: fast updates的条件是比较苛刻的,必须满足: 看了这些苛刻的条件后,有种"臣妾做不到"的感觉了吧,可以看出TokuDB一直为细节而努力.

MySQL内核月报 2014.12-MySQL· 优化改进· GTID启动优化

背景 GTID 可以说是 MySQL 5.6 版本的一个杀手级特性,它给主备复制带来了极大的便利,RDS只读实例就是强依赖于这个特性.然而GTID在给我们带来便利的同时,也埋下了许多坑,最近几期内核月报中GTID的频繁出现也说明了这一点,对其我们可以说是既爱又恨. GTID 并不是免费午餐,要使用它是要有代价的,为了保证GTID这个体系能够运转起来,需要做许多相关的工作,比如binlog里每个事务要多记 gtid_event 这种事件.写binlog的时候要生成 gtid.要维护几个GTID集合

MySQL内核月报 2014.10-TokuDB· 引擎特性·压缩

TokuDB除了有着较好的写性能外,还有一个重要的特性:压缩,而且大部分情况下压缩效果很不错. 目前TokuDB有4种压缩算法: 使用上也比较简单: 可能大家会有一个疑问:如果一个表创建的时候压缩算法是tokudb_quicklz,我可以通过ALERT TABLE改成其他算法吗?答案是:可以的! TokuDB在底层实现上,用1byte来标记当前block的压缩算法,并持久化到磁盘,当压缩算法改变后,从磁盘读取数据然后解压缩的代码类似: 是不是很机智? 在使用TokuDB的过程中,一般不会改变压缩

MySQL内核月报 2014.08-MySQL· 参数故事·timed_mutexes

提要 MySQL 5.5.39 Release版本正式从源码里删除了全局参数timed_mutexes.timed_mutexes原本用来控制是否对Innodb引擎的mutex wait进行计时统计,以方便进行性能诊断.为什么要删除这个参数呢? 下面介绍下相关背景: Innodb的同步锁机制 Innodb封装了mutex和rw_lock结构来保护内存的变量和结构,进行多线程同步,考虑可移植性, mutex使用lock_word或者OS mutex来保证原子操作,并使用event条件变量进行阻塞和

MySQL内核月报 2014.11-MySQL· 5.7改进·Recovery改进

背景 InnoDB作为事务性引擎,使用write-ahead logging(WAL)机制保证ACID中的Atomicity和Durability,使用undo机制保证ACID中的Consistency和Isolation. 按照WAL和undo的机制,形成以下两个原则: 1. 数据块的更改需要先记录redo日志. 2. 数据块的更改需要先写入undo. 根据这两个原则,InnoDB更新数据的基本流程可以简单的总结为: 1. 记录需要更改undo record的redo log 2. 记录需要更

MySQL内核月报 2014.09-MySQL· 捉虫动态·GTID 和 DELAYED

描述 这是一个MySQL 5.6才有的bug,影响包含最新版本.涉及到的概念有GTID.DELAYED. 现象 在5.6主备都开启GTID-MODE的时候,备库同步线程停止,且Last_SQL_Error显示"When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT var

MySQL内核月报 2014.12-TokuDB· Binary Log Group Commit with TokuDB

MySQL在开启Binary Log的情况下,使用2PC(图1)来保证事务(XA)完整性的,每次提交事务需要做: 每个事务在提交的时候都要做3次fsync以确保日志真正的落盘,这样在log里,一个事务就会有3种状态: 这样,无论处于任何一个状态,事务的完整性都不会被破坏,但是每次提交会产生3次fsync,性能非常低. 为了提升性能,MySQL 5.6增加了group commit功能,当多个事务并发提交时,让多个都在等待fsync的事务合并做一次fsync,大大提升了吞吐量. 但是这个优化还需要

MySQL内核月报 2014.09-MySQL· 捉虫动态·auto_increment

背景: Innodb引擎使用B_tree结构保存表数据,这样就需要一个唯一键表示每一行记录(比如二级索引记录引用). Innodb表定义中处理主键的逻辑是: 1.如果表定义了主键,就使用主键唯一定位一条记录 2.如果没有定义主键,Innodb就生成一个全局唯一的rowid来定位一条记录 auto_increment的由来: 1.Innodb强烈推荐在设计表中自定义一个主键,因为rowid是全局唯一的,所以如果有很多表没有定义主键,就会在生成rowid上产生争用. row_id由mutex保护,并

MySQL内核月报 2014.11-MySQL· 5.7优化·Metadata Lock子系统的优化

背景 引入MDL锁的目的,最初是为了解决著名的bug#989,在MySQL 5.1及之前的版本,事务执行过程中并不维护涉及到的所有表的Metatdata 锁,极易出现复制中断,例如如下执行序列: Session 1: BEGIN; Session 1: INSERT INTO t1 VALUES (1); Session 2: Drop table t1; --------SQL写入BINLOG Session 1: COMMIT; -----事务写入BINLOG 在备库重放 binlog时,会