mysql innodb-mysql 5.6innodb compac的vachar长度标记位1还是2byte的问题:

问题描述

mysql 5.6innodb compac的vachar长度标记位1还是2byte的问题:

For each non-NULL variable-length field, the record header contains the length of the column in one or two bytes. Two bytes will only be needed if part of the column is stored externally in overflow pages or the maximum length exceeds 255 bytes and the actual length exceeds 127 bytes. For an externally stored column, the 2-byte length indicates the length of the internally stored part plus the 20-byte pointer to the externally stored part. The internal part is 768 bytes, so the length is 768+20. The 20-byte pointer stores the true length of the column.

5.6文档上有如上的一句话,文档上说当最大长度超过255字节和实际存储超过127字节的时候,使用2Byte标识,是什么意思呢?那如果最大长度超过255,实际存储小于127byte呢?

时间: 2024-08-23 16:10:50

mysql innodb-mysql 5.6innodb compac的vachar长度标记位1还是2byte的问题:的相关文章

关于MYSQL INNODB index page header学习和实验总结

关于INNODB  index header 所用到的工具是自己写的mysqlblock和bcview, 我放到了百度云盘 http://pan.baidu.com/s/1num76RJ 供大家下载和使用 普通表空间(及设置了innodb_file_per_table每个表都对应一个idb文件)从第4个块开始通常是innodb的数据页. 前38字节为FILE HEADER 从38字节到74字节为INDEX HEADER,如下: number of directory slot          

反驳"MySQL InnoDB (不行)的性能问题",千万级别记录来测试说明

在 JavaEye 上看到一篇对 MySQL FUD(Fear, uncertainty and doubt) 的文章 用MySQL InnoDB Benchmark 性能测试来说明 http://www.javaeye.com/topic/34676 文中提到:"InnoDB 的磁盘性能很令人担心,MySQL 缺乏良好的 tablespace 真是天大的缺陷! --网上有用户反映存在同样的插入性能问题,百万行记录插入之后,插入速度下降到了 1/30,从开始的 1600行/秒衰退到 50行/秒-

巧用MySQL InnoDB引擎锁机制解决死锁问题

最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read mysql tables in use 1, loc

MySQL Innodb数据库性能实践——热点数据性能

对于大部分的应用来说,都存在热点数据的访问,即:某些数据在一定时间内的访问频率要远远高于其它数据. 常见的热点数据有"最新的新闻"."最热门的新闻"."下载量最大"的电影等. 为了了解MySQL Innodb对热点数据的支持情况,我进行了基准测试,测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR

MySQL/InnoDB和Group Commit(2)

今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作,而且是用最优雅的方式(移植了MariaDB的实现,而不是workaround),心里难掩激动. 这篇文章接前篇继续介绍一下问题的背景:什么是Group Commit,现在的官方版本Group Commit做到了什么程度? 1. 什么是Group Commit MySQL/InnoDB在做事务的时候使用的日志先行(Write-ahead logging)的方式保证事务

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理   1. InnoDB 引擎表行锁等待和等待超时发生的场景 2.InnoDB 引擎行锁等待情况的处理 2.1 InnoDB 行锁等待超时参数 innodb_lock_wait_timeout 2.2 大量行锁等待和行锁等待超时的处理 1. InnoDB 引擎表行锁等待和等待超时发生的场景 当一个 RDS for MySQL 连接会话等待另外一个会话持有的互斥行锁时,会发生 InnoDB 引擎表行锁等待情况. 通常情况下,持有该

MySQL Innodb日志机制深入分析

                            MySQL Innodb日志机制深入分析   1.1. Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面.Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件).   由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析. 名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位

MySQL Innodb数据库性能实践——合适的表记录数

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MySQL Innodb数据库性能实践

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000