MySQL innodb_table_monitor 解析

背景:
       用innodb_table_monitor来查看表内部的存储信息和索引结构是一个好的办法。再之前的MySQL 字符串主键和整型主键分析中提到了一些内容,但没有细讲,现在来好好的分析下。

使用方法:
       
建立一张 innodb_table_monitor的表:

create table innodb_table_monitor(a int)engine=innodb;

表建立之后,会每隔1m20s间隔把监控到的信息写到error日志中。要是停止监控的话,只需要删除表就可以了。注意:要是一直开启的话,错误日志会变的非常大。

日志的具体信息:

===========================================
121103 10:25:57 INNODB TABLE MONITOR OUTPUT
===========================================
--------------------------------------
TABLE: name SYS_FOREIGN, id 0 11, flags 0, columns 7, indexes 3, appr.rows 8
  COLUMNS: ID: DATA_VARCHAR prtype 524292 len 0; FOR_NAME: DATA_VARCHAR prtype 524292 len 0; REF_NAME: DATA_VARCHAR prtype 524292 len 0; N_COLS: DATA_INT len 4; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
  INDEX: name ID_IND, id 0 11, fields 1/6, uniq 1, type 3
   root page 46, appr.key vals 8, leaf pages 1, size pages 1
   FIELDS:  ID DB_TRX_ID DB_ROLL_PTR FOR_NAME REF_NAME N_COLS
  INDEX: name FOR_IND, id 0 12, fields 1/2, uniq 2, type 0
   root page 47, appr.key vals 4, leaf pages 1, size pages 1
   FIELDS:  FOR_NAME ID
  INDEX: name REF_IND, id 0 13, fields 1/2, uniq 2, type 0
   root page 48, appr.key vals 3, leaf pages 1, size pages 1
   FIELDS:  REF_NAME ID
--------------------------------------
TABLE: name SYS_FOREIGN_COLS, id 0 12, flags 0, columns 7, indexes 1, appr.rows 8
  COLUMNS: ID: DATA_VARCHAR prtype 524292 len 0; POS: DATA_INT len 4; FOR_COL_NAME: DATA_VARCHAR prtype 524292 len 0; REF_COL_NAME: DATA_VARCHAR prtype 524292 len 0; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
  INDEX: name ID_IND, id 0 14, fields 2/6, uniq 2, type 3
   root page 49, appr.key vals 8, leaf pages 1, size pages 1
   FIELDS:  ID POS DB_TRX_ID DB_ROLL_PTR FOR_COL_NAME REF_COL_NAME
--------------------------------------

上面显示,其中输出结构的开始部分会包含2张内部数据字典表用于维护外键的信息,表名为SYS_FOREIGN、SYS_FOREIGN_COLS。看看用户创建表的信息:

1,有主键的表(有数据):

CREATE TABLE `test` (
  `uid` char(36) NOT NULL DEFAULT ‘‘,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`uid`),
  KEY `idx_id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

 1 TABLE: name test/test, id 0 718, flags 1, columns 7, indexes 2, appr.rows 635787
 2    COLUMNS: uid: DATA_MYSQL DATA_NOT_NULL len 108; id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARMYSQL len 765; status: DATA_INT DATA_BINARY_TYPE len 1; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
 3    INDEX: name PRIMARY, id 0 1387, fields 1/6, uniq 1, type 3
 4    root page 3, appr.key vals 635787, leaf pages 4056, size pages 4078
 5 FIELDS:  uid DB_TRX_ID DB_ROLL_PTR id name status  /*主键包含所有列*/
 6 INDEX: name idx_id, id 0 1388, fields 1/2, uniq 2, type 0   7 root page 4, appr.key vals 638241, leaf pages 1834, size pages 1896   8 FIELDS: id uid /*表中定义的二级索引包含主键uid列*/ 

第一部分(1):表信息:表名(test),表ID(718),列数(7),索引数(2),索性的基数<Cardinality>(625787,会变动);

第二部分(2):列信息:包括列名、列类型(DATA_XXXX)、是否NULL、以及列字段的长度。后面还有额外三列(主键ID,事务ID,回滚子指针) 总共7列;

• DATA_xxx(列类型): These symbols indicate the data type. There may be multiple DATA_xxx symbols for a given column.
• prtype(列的数据类型的字符集编码,空性,符号性,以及是否它是一个二进制字符串): The column‘s “precise” type. This field includes information such as the column data type, character set code, nullability,signedness, and whether it is a binary string. This field is described in the innobase/include/data0type.h source file.
• len(列字段的长度):The column length in bytes.
• prec(类型的精确值):The precision of the type.

第三部分(3~5):索引信息:索引名、索引ID,fields m/n (m代表用户定义索引中的列数/n代表总的索引列数,其中包含附加的internal columns),由于没有显示的定义主键或者非空的唯一索引,InnoDB会建表的时候自动的创建名字为GEN_CLUST_INDEX的Clustered Index。如果显示的定义一个主键的话,这个时候INDEX中name的值是:PRIMARY。以及 一些page信息和索引的基数信息。最后则是被索引的列,和 fields m/n 里的n对应。

• type(索引类型:聚集索引1,唯一索引2,普通索引0,既聚集又唯一3): The index type. This is a bit field. For example, 1 indicates a clustered index and 2 indicates a unique index, so a clustered index (which always contains unique values), will have a type value of 3. An index with a type value of 0 is neither clustered nor unique. The flag values are defined in the innobase/include/dict0mem.h source file.
• root page(索引节点:根节点): The index root page number.
• appr. key vals(索引的基数): The approximate index cardinality.
• leaf page(页节点大小): number of leaf pages in the index.
• size pages(总页大小): The approximages: The approate total number of pages in the index.
• FIELDS(被索引的列,主键包含所有列以及隐藏列,二级索引包含主键): The names of the fields in the index. For a clustered index that was generated automatically, the field list begins with the internal DB_ROW_ID (row ID) field. DB_TRX_ID and DB_ROLL_PTR are always added internally to the clustered index, following the fields that comprise the primary key. For a secondary index, the final fields are those from the primary key that are not part of the secondary index.

2,上面的表是有主键的,看看无主键的表(没有数据):

CREATE TABLE `test1` (
  `uid` char(36) NOT NULL DEFAULT ‘‘,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL,
  KEY `idx_id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

1 TABLE: name test/test1, id 0 820, flags 1, columns 7, indexes 2, appr.rows 0
2   COLUMNS: uid: DATA_MYSQL DATA_NOT_NULL len 108; id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARMYSQL len 765; status: DATA_INT DATA_BINARY_TYPE len 1; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
3   INDEX: name GEN_CLUST_INDEX, id 0 1524, fields 0/7, uniq 1, type 1 /*1 说明只是主键,不是唯一*/
4    root page 3, appr.key vals 0, leaf pages 1, size pages 1
5    FIELDS:  DB_ROW_ID DB_TRX_ID DB_ROLL_PTR uid id name status
6   INDEX: name idx_id, id 0 1525, fields 1/2, uniq 2, type 0
7    root page 4, appr.key vals 0, leaf pages 1, size pages 1
8    FIELDS:  id DB_ROW_ID

1和2对比异同:
      第一行和第二行他们的信息是一样的。
      第三行出现不一致,因为1的表是有主键的,而2的表没有主键,2会自动生成一个Row_ID来代替,而导致第五行也不一致,因为2比1多了一个Row_ID(6个字节)。所以2的表中被索引的列有7个,而1只有6个,2没有定义索引列,而1定义了一个(fields)。因为二级索引包含主键列(第8行),主键不一样了,导致二级索引的列也会不一样。

3,测试有没有主键表大小问题:

CREATE TABLE `test2` (
  `uid` char(36) NOT NULL DEFAULT ‘‘,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL,
  PRIMARY KEY `idx_id` (`id`)
) ENGINE=InnoDB;   /*有自增主键*/

CREATE TABLE `test3` (
  `uid` char(36) NOT NULL DEFAULT ‘‘,
  `id` int(11) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL
) ENGINE=InnoDB; /*无主键*/

CREATE TABLE `test4` (
  `uid` char(36) NOT NULL DEFAULT ‘‘,
  `id` int(11) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`uid`)
) ENGINE=InnoDB; /*有字符串主键*/

--------------------------------------
TABLE: name test/test2, id 0 824, flags 1, columns 7, indexes 1, appr.rows 625647
  COLUMNS: uid: DATA_MYSQL DATA_NOT_NULL len 108; id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARMYSQL len 765; status: DATA_INT DATA_BINARY_TYPE len 1; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
  INDEX: name PRIMARY, id 0 1532, fields 1/6, uniq 1, type 3
   root page 3, appr.key vals 625647, leaf pages 4056, size pages 4070
   FIELDS:  id DB_TRX_ID DB_ROLL_PTR uid name status
--------------------------------------
TABLE: name test/test3, id 0 825, flags 1, columns 7, indexes 1, appr.rows 617020
  COLUMNS: uid: DATA_MYSQL DATA_NOT_NULL len 108; id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARMYSQL len 765; status: DATA_INT DATA_BINARY_TYPE len 1; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
  INDEX: name GEN_CLUST_INDEX, id 0 1533, fields 0/7, uniq 1, type 1
   root page 3, appr.key vals 617020, leaf pages 4311, size pages 4326
   FIELDS:  DB_ROW_ID DB_TRX_ID DB_ROLL_PTR uid id name status
--------------------------------------
TABLE: name test/test4, id 0 826, flags 1, columns 7, indexes 1, appr.rows 655560
  COLUMNS: uid: DATA_MYSQL DATA_NOT_NULL len 108; id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARMYSQL len 765; status: DATA_INT DATA_BINARY_TYPE len 1; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
  INDEX: name PRIMARY, id 0 1534, fields 1/6, uniq 1, type 3
   root page 3, appr.key vals 655560, leaf pages 4056, size pages 4078
   FIELDS:  uid DB_TRX_ID DB_ROLL_PTR id name status
--------------------------------------

时间: 2024-10-02 17:13:55

MySQL innodb_table_monitor 解析的相关文章

Mysql流程解析

Mysql流程解析 流程图 流程图解析 客户端发送一条sql语句. 1.此时,mysql会检查sql语句,查看是否命中缓存,如果命中缓存,直接返回结果,不继续执行.没有命中则进入解析器. 2.解析器会检查sql语句的语法,并生成一个解析树. 3.预处理器会检查解析树的表名,列名等是否正确,表是否有权限等. 4.当解析树是一个合法的了,优化器将其转化成执行计划,一个解析树有多个执行计划,但是都返回同样的结果,唯一不同的是,每个执行计划的成本不一样,mysql会选择一个最低成本的执行计划来执行. 5

MySQL Binlog 解析工具 Maxwell 详解

maxwell 简介 Maxwell是一个能实时读取MySQL二进制日志binlog,并生成 JSON 格式的消息,作为生产者发送给 Kafka,Kinesis.RabbitMQ.Redis.Google Cloud Pub/Sub.文件或其它平台的应用程序.它的常见应用场景有ETL.维护缓存.收集表级别的dml指标.增量到搜索引擎.数据分区迁移.切库binlog回滚方案等.官网(http://maxwells-daemon.io).GitHub(https://github.com/zende

Mysql binlog 解析

首先,我们知道MySQL本身就带有replication的机制,我们需要伪造一个slave,向master注册,这样的话master才会发送binlog event.注册很简单,通过调用limysql.so中的cli_advanced_command(),指定binlog filename+position,向master发送COM_BINLOG_DUMP命令.在发送dump命令的时候,我们可以指定flag为BINLOG_DUMP_NON_BLOCK,这样master在没有可以发送的binlog

mysql binlog解析概要

1,dump协议: 根据数据库的ip+port创建socket,如果创建成功,说明链接建立成功,接下来是使用dump协议订阅binlog 链接建立成功之后,服务端会主动向客户端发送如下问候信息greeting(可以理解为经java转换后,是一个java对象), 在下面的代码中可以看到greeting中的信息: this.context.setServerStatus(greeting.getServerStatus());//this.context.setServerVersion(greet

Python操作小结(连接mysql、解析txt文件)

有段时间没有使用python了,对它的语法有点生疏,花了几个小时熟悉,期间发现很多小细节不清楚.为了下次能快速上手,避免重复犯错,我将python使用过程中的一些问题在这篇博文中记录小结一下,主要内容涉及到python操作mysql数据库,和解析txt文本.注:我用的是python2.7版本. 一.导入模块 python的脚本文件里面,可以导入其他脚本文件,并引用其中的方法和参数,使用关键字import.如下: import os,glob,sys 二.基础语法 1.普通变量定义 python

关于MySQL DNS解析探究之一:DNS解析确实在起作用

机器A --> 192.168.103.94  -- 服务器 机器B --> 192.168.4.2        -- 客户端 机器A => 装上mysql-server,启动: 使用root用户登录,查看DNS解析是否开启,执行如下命令: mysql> show variables like 'skip_name_resolve%'; +-------------------+-------+ | Variable_name     | Value | +-----------

MySQL Binlog解析(2)

一.TABLE_MAP_EVENT Used for row-based binary logging beginning with MySQL 5.1.5.The TABLE_MAP_EVENT defines the structure if the tables that are about to be changed. 用于从MySQL 5.1.5开始的基于行的二进制日志记录.每个ROW_EVENT之前都有一个TABLE_MAP_EVENT,用于描述表的内部ID和结构定义. 1)触发条件

最新用python来操作mysql完全解析

1.此处通过MySQLdb来操作mysql,首先 sudo apt-get install libmysqlclient-dev,如何出现 Encountered a section with no Package: header E: Problem with MergeList /var/lib/apt/lists/dl.google.com_linux_chrome_deb_dists_stable_main_i18n_Translation-en%5fUS E: The package

mysql日志解析

mysql有4种不同的日志,分别是二进制日志,查询日志,慢查询日志和错误日志,这些日记记录着数据库工作的方方面面,可以帮助我们了解数据库的不同方面的踪迹,下面先介绍二进制日志的作用和使用方法,并利用二进制日志对数据库进行各种维护和优化,其他日志也会在后面陆续会做详细的介绍. 二进制日志(bin-log日志)在上一篇介绍mysql主从配置的blog中,已经提过bin-log日志的作用和使用,bin-log日志记录了所有的DDL和DML的语句,但不包括查询的语句,语句以事件的方式保存,描述了数据的更