information_schema系列十一
1: INNODB_CMP 和INNODB_CMP_RESET
这两个表存储的是关于压缩INNODB信息表的时候的相关信息,
Column name | Description |
PAGE_SIZE | Compressed page size in bytes. |
COMPRESS_OPS | Number of times a B-tree page of the size PAGE_SIZE has been compressed. Pages are compressed whenever an empty page is created or the space for the uncompressed modification log runs out. |
COMPRESS_OPS_OK | Number of times a B-tree page of the size PAGE_SIZE has been successfully compressed. This count should never exceed COMPRESS_OPS. |
COMPRESS_TIME | Total time in seconds spent in attempts to compress B-tree pages of the size PAGE_SIZE. |
UNCOMPRESS_OPS | Number of times a B-tree page of the size PAGE_SIZE has been uncompressed. B-tree pages are uncompressed whenever compression fails or at first access when the uncompressed page does not exist in the buffer pool. |
UNCOMPRESS_TIME | Total time in seconds spent in uncompressing B-tree pages of the size PAGE_SIZE. |
这几个表主要就是看我们的压缩是不是有效,必须有PEOCESS的权限才可以查看这两张表.
在这刚好补充一下表压缩的知识:
在创建innodb表时带上ROW_FORMAT=COMPRESSED参数能够使用比默认的16K更小的页。这样在读写时需要更少的I/O,对于SSD磁盘更有价值,页的大小通过KEY_BLOCK_SIZE参数指定。不同大小的页意味着需要使用独立表空间,不能使用系统共享表空间,可以通过innodb_file_per_table指定。KEY_BLOCK_SIZE的值越小,你获得I/O好处就越多,但是如果因为你指定的值太小,当数据被压缩到不足够满足每页多行数据记录时,会产生额外的开销来重组页。对于一个表,KEY_BLOCK_SIZE的值有多小是有严格的限制的,一般是基于每个索引键的长度。有时指定值过小,当create table或者alter table会失败。
在缓冲池中,被压缩的数据是存储在小页中的,这个小页的实际大小就是KEY_BLOCK_SIZE的值。为了提取和更新列值,mysql也会在缓冲池中创建一个未压缩的16k页。任何更新到未压缩的页也需要重新写入到压缩的页,这时你需要估计缓冲池的大小以满足压缩和未压缩的页,尽管当缓冲空间不足时,未压缩的页会被挤出缓冲池。在下次访问时,不压缩的页还会被创建。
看个例子:
SET GLOBAL innodb_file_per_table=1; SET GLOBAL innodb_file_format=Barracuda; CREATE TABLE t1 (c1 INT PRIMARY KEY) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
- 如果你指定ROW_FORMAT=COMPRESSED,那么可以忽略KEY_BLOCK_SIZE的值,这时使用默认innodb页的一半,即8kb;
- 如果你指定了KEY_BLOCK_SIZE的值,那么你可以忽略ROW_FORMAT=COMPRESSED,因为这时会自动启用压缩;
- 为了指定最合适KEY_BLOCK_SIZE的值,你可以创建表的多个副本,使用不同的值进行测试,比较他们的.ibd文件的大小;
- KEY_BLOCK_SIZE的值作为一种提示,如必要,Innodb也可以使用一个不同的值。0代表默认压缩页的值,Innodb页的一半。KEY_BLOCK_SIZE的值只能小于等于innodb page size。如果你指定了一个大于innodb page size的值,mysql会忽略这个值然后产生一个警告,这时KEY_BLOCK_SIZE的值是Innodb页的一半。如果设置了innodb_strict_mode=ON,那么指定一个不合法的KEY_BLOCK_SIZE的值是返回报错。
InnoDB未压缩的数据页是16K,根据选项组合值,mysql为每个表的.ibd文件使用1kb,2kb,4kb,8kb,16kb页大小,实际的压缩算法并不会受KEY_BLOCK_SIZE值影响,这个值只是决定每个压缩块有多大,从而影响多少行被压缩到每个页。设置KEY_BLOCK_SIZE值等于16k并不能有效的进行压缩,因为默认的innodb页就是16k,但是对于拥有很多BLOB,TEXT,VARCHAR类型字段的表可能会有效果的。
一般而言,对于读远远大于写的应用以及拥有合理数量的字符串列的表,使用压缩效果会更好。
四、INNODB表是如何压缩的?
1、压缩算法
mysql进行压缩是借助于zlib库,采用L777压缩算法,这种算法在减少数据大小、CPU利用方面是成熟的、健壮的、高效的。同时这种算法是无失真的,因此原生的未压缩的数据总是能够从压缩文件中重构,LZ777实现原理是查找重复数据的序列号然后进行压缩,所以数据模式决定了压缩效率,一般而言,用户的数据能够被压缩50%以上。
不同于应用程序压缩或者其他数据库系统的压缩,InnoDB压缩是同时对数据和索引进行压缩,很多情况下,索引能够占数据库总大小的40%-50%。如果压缩效果很好,一般innodb文件会减少25%-50%或者更多,而且减少I/O增加系统吞吐量,但是会增加CPU的占用,你可通过设置innodb_compression_level参数来平衡压缩级别和CPU占用。
2、InnoDB数据存储及压缩
所有数据和b-tree索引都是按页进行存储的,每行包含主键和表的其他列。辅助索引也是b-tree结构的,包含对值:索引值及指向每行记录的指针,这个指针实际上就是表的主键值。
在innodb压缩表中,每个压缩页(1,2,4,8)都对应一个未压缩的页16K,为了访问压缩页中的数据,如果该页在buffer pool中不存在,那么就从硬盘上读到这个压缩页,然后进行解压到原来的数据结构。为了最小化I/O和减少解压页的次数,有时,buffer pool中包括压缩和未压缩的页,为给其他页腾出地方,buffer pool会驱逐未压缩页,仅仅留下压缩页在内存中。或者如果一个页一段时间没有被访问,那么会被写到硬盘上。这样一来,任何时候,buffer pool中都可以包含压缩页和未压缩页,或者只有压缩页或者两者都没有。
Mysql采用LRU算法来保证哪些页应该在内存中还是被驱逐。因此热数据一般都会在内存中。
五、OLTP系统压缩负载优化
一般而言,innodb压缩对于只读或者读比重比较多的应用效果更好,SSD的出现,使得压缩更加吸引我们,尤其对于OLTP系统。对于经常update、delete、insert的应用,通过压缩表能够减少他们的存储需求和每秒I/O操作。
下面是针对写密集的应用,设置压缩表的一些有用参数:
- innodb_compression_level:决定压缩程度的参数,如果你设置比较大,那么压缩比较多,耗费的CPU资源也较多;相反,如果设置较小的值,那么CPU占用少。默认值6,可以设置0-9
- innodb_compression_failure_threshold_pct:默认值5,范围0到100.设置中断点避免高昂的压缩失败率。
- innodb_compression_pad_pct_max:指定在每个压缩页面可以作为空闲空间的最大比例,该参数仅仅应用在设置了innodb_compression_failure_threshold_pct不为零情况下,并且压缩失败率通过了中断点。默认值50,可以设置范围是0到75.
可以使用以下语句进行压缩.
alter table test KEY_BLOCK_SIZE=1|2|4|8|16;
设置的越小,压缩比例就会越大,但是会带来额外的开销,一般建议8K.
2:INNODB_CMP_PER_INDEX和INNODB_CMP_PER_INDEX_RESET
这两个表存储的是关于压缩INNODB信息表的时候的相关信息,有关整个表和索引信息都有.我们知道对于一个INNODB压缩表来说,不管是数据还是二级索引都是会被压缩的,因为数据本身也可以看作是一个聚集索引.
Column name | Description |
DATABASE_NAME | 相关数据库 |
TABLE_NAME | 监控的压缩表 |
INDEX_NAME | 索引的名字 |
COMPRESS_OPS | Number of compression operations attempted. Pages are compressed whenever an empty page is created or the space for the uncompressed modification log runs out. |
COMPRESS_OPS_OK | Number of successful compression operations. Subtract from the COMPRESS_OPS value to get the number of compression failures. Divide by the COMPRESS_OPS value to get the percentage of compression failures. |
COMPRESS_TIME | Total amount of CPU time, in seconds, used for compressing data in this index. |
UNCOMPRESS_OPS | Number of uncompression operations performed. Compressed InnoDB pages are uncompressed whenever compression fails, or the first time a compressed page is accessed in the buffer pool and the uncompressed page does not exist. |
UNCOMPRESS_TIME | Total amount of CPU time, in seconds, used for uncompressing data in this index. |
但是要注意一点的就是,用这两个表来收集所有信息的表的时候,是会对性能造成严重的影响的,所以说默认是关闭状态的。如果要打开这个功能的话我们要设置以下参数为ON状态。
innodb_cmp_per_index_enabled
3: INNODB_CMPMEM_RESET和 INNODB_CMPMEM
这两个表是存放关于MySQL INNODB的压缩页的buffer pool信息。
Column name | Description |
PAGE_SIZE | Block size in bytes. Each record of this table describes blocks of this size. |
BUFFER_POOL_INSTANCE | A unique identifier for the buffer pool instance. |
PAGES_USED | Number of blocks of the size PAGE_SIZE that are currently in use. |
PAGES_FREE | Number of blocks of the size PAGE_SIZE that are currently available for allocation. This column shows the external fragmentation in the memory pool. Ideally, these numbers should be at most 1. |
RELOCATION_OPS | Number of times a block of the size PAGE_SIZE has been relocated. The buddy system can relocate the allocated “buddy neighbor”of a freed block when it tries to form a bigger freed block. Reading from the table INNODB_CMPMEM_RESET resets this count. |
RELOCATION_TIME | Total time in microseconds spent in relocating blocks of the size PAGE_SIZE. Reading from the table INNODB_CMPMEM_RESETresets this count. |
热衷于学习讨论MySQL和SQL Server,NoSQL等数据库技术,欢迎加入SQL优化群:659336691