Posted by&
作者：吴炳锡　来源：http://wubx.net/ 联系方式：
转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
最近有几个同学问我varchar和text有啥别吗，这个问题，以前说真的也没太多的整理，以前遇到text在设计中就是尽可能的拆到另一个表中，保持主表尽量的瘦小，可以让innodb bp缓存更多的数据。
今天借次机会系统整理一下，主要从存储上，最大值，默认值几个方面进行比较。
BTW： 从ISO SQL:2003上讲VARCHAR是一个标准型，但TEXT不是（包括tinytext）.varchar在MySQL 5.0.3之前只支持0-255byte, 在5.0.3之后才支持到0-65535byte.
从存储上讲：
- text 是要要进overflow存储。 也是对于text字段，不会和行数据存在一起。但原则上不会全部overflow ,
会有768字节和原始的行存储在一块，多于768的行会存在和行相同的Page或是其它Page上。
- varchar 在MySQL内部属于从blob发展出来的一个结构，在早期版本中innobase中，也是768字节以后进行overfolw存储。
- 对于Innodb-plugin后： 对于变长字段处理都是20Byte后进行overflow存储
（在新的row_format下：dynimic compress）
- text 是要要进overflow存储。 也是对于text字段，不会和行数据存在一起。但原则上不会全部overflow ,会有768字节和原始的行存储在一块，多于768的行会存在和行相同的Page或是其它Page上。&- varchar 在MySQL内部属于从blob发展出来的一个结构，在早期版本中innobase中，也是768字节以后进行overfolw存储。&- 对于Innodb-plugin后： 对于变长字段处理都是20Byte后进行overflow存储（在新的row_format下：dynimic compress）&
说完存储后，说一下使用这些大的变长字段的缺点：
- 在Innobase中,变长字段，是尽可能的存储到一个Page里，这样，如果使用到这些大的变长字段，会造成一个Page里能容纳的行
数很少，在查询时，虽然没查询这些大的字段，但也会加载到innodb buffer pool中，等于浪费的内存。
（buffer pool 的缓存是按page为单位）（不在一个page了会增加随机的IO）
- 在innodb-plugin中为了减少这种大的变长字段对内存的浪费，引入了大于20个字节的，都进行overflow存储，
而且希望不要存到相同的page中，为了增加一个page里能存储更多的行，提高buffer pool的利用率。 这也要求我们，
如果不是特别需要就不要读取那些变长的字段。
- 在Innobase中,变长字段，是尽可能的存储到一个Page里，这样，如果使用到这些大的变长字段，会造成一个Page里能容纳的行数很少，在查询时，虽然没查询这些大的字段，但也会加载到innodb buffer pool中，等于浪费的内存。（buffer pool 的缓存是按page为单位）（不在一个page了会增加随机的IO）&- 在innodb-plugin中为了减少这种大的变长字段对内存的浪费，引入了大于20个字节的，都进行overflow存储，而且希望不要存到相同的page中，为了增加一个page里能存储更多的行，提高buffer pool的利用率。 这也要求我们，如果不是特别需要就不要读取那些变长的字段。&
那问题来了？ 为什么varchar(255+)存储上和text很相似了，但为什么还要有varchar, mediumtext, text这些类型？
（从存储上来讲大于255的varchar可以说是转换成了text.这也是为什么varchar大于65535了会转成mediumtext)
我理解：这块是一方面的兼容，另一方面在非空的默认值上varchar和text有区别。从整体上看功能上还是差别的。
这里还涉及到字段额外开销的：
- varchar 小于255byte
1byte overhead
- varchar 大于255byte
2byte overhead
- tinytext 0-255 1 byte overhead
- text 0-65535 byte 2 byte overhead
- mediumtext 0-16M
3 byte overhead
- longtext 0-4Gb 4byte overhead
- varchar 小于255byte&&1byte overhead- varchar 大于255byte&&2byte overhead&- tinytext 0-255 1 byte overhead- text 0-65535 byte 2 byte overhead- mediumtext 0-16M&&3 byte overhead&- longtext 0-4Gb 4byte overhead&
备注 overhead是指需要几个字节用于记录该字段的实际长度。
从处理形态上来讲varchar 大于768字节后，实质上存储和text差别不是太大了。 基本认为是一样的。
另外从8000byte这个点说明一下： 对于varcahr, text如果行不超过8000byte（大约的数，innodb data page的一半） ,overflow不会存到别的page中。基于上面的特性可以总结为text只是一个MySQL扩展出来的特殊语法有兼容的感觉。
默认值问题：
- 对于text字段，MySQL不允许有默认值。
- varchar允许有默认值
- 对于text字段，MySQL不允许有默认值。- varchar允许有默认值&
根据存储的实现： 可以考虑用varchar替代tinytext
如果需要非空的默认值，就必须使用varchar
如果存储的数据大于64K，就必须使用到mediumtext , longtext
varchar(255+)和text在存储机制是一样的
需要特别注意varchar(255)不只是255byte ,实质上有可能占用的更多。
特别注意，varchar大字段一样的会降低性能，所以在设计中还是一个原则大字段要拆出去，主表还是要尽量的瘦小
根据存储的实现： 可以考虑用varchar替代tinytext如果需要非空的默认值，就必须使用varchar如果存储的数据大于64K，就必须使用到mediumtext , longtextvarchar(255+)和text在存储机制是一样的&需要特别注意varchar(255)不只是255byte ,实质上有可能占用的更多。&特别注意，varchar大字段一样的会降低性能，所以在设计中还是一个原则大字段要拆出去，主表还是要尽量的瘦小&
源码中类型：
+--Field_str (abstract)
+--Field_longstr
+--Field_string
+--Field_varstring
+--Field_blob
+--Field_geom
+--Field_null
+--Field_enum
+--Field_set
12345678910
+--Field_str (abstract) |&&+--Field_longstr |&&|&&+--Field_string |&&|&&+--Field_varstring |&&|&&+--Field_blob |&&|&&&& +--Field_geom |&&| |&&+--Field_null |&&+--Field_enum |&&&& +--Field_set
（末完待续，也希望大家一块讨论一下）
/2010/11/handling-long-textsblobs-in-innodb-1-to.html
http://nicj.net/mysql-text-vs-varchar-performance/
/blog/text-vs-varchar/
测试SQL及方法
create table tb_01(
c1 varchar(255),
c2 varchar(255),
c3 varchar(255),
c4 varchar(255),
c5 varchar(255),
c6 varchar(255),
c7 varchar(255),
c8 varchar(255),
c9 varchar(255),
c10 varchar(255),
c11 varchar(255)
insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
ERROR ): Row size too large (& 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
(testing)root@localhost [wubx]& set global innodb_file_format=BARRACUDA;
Query OK, 0 rows affected (0.00 sec)
(testing)root@localhost [wubx]& alter table tb_01 row_format=
Query OK, 0 rows affected (0.19 sec)
Records: 0
Duplicates: 0
Warnings: 0
(testing)root@localhost [wubx]& insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
Query OK, 1 row affected (0.00 sec)
set global innodb_file_format=A
create table tb_02(
c1 varchar(2000),
c2 varchar(2000),
c3 varchar(2000),
c4 varchar(2000),
c5 varchar(2000),
c6 varchar(2000),
c7 varchar(2000),
c8 varchar(2000)
insert into tb_02(c1, c2, c3,c4,c5,c6,c7,c8) values(repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000) );
create table tb_03(
insert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
(testing)root@localhost [wubx]& insert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
ERROR ): Row size too large (& 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
set global innodb_file_format=BARRACUDA;
alter table tb_03 row_format=
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263
create table tb_01(c1 varchar(255),c2 varchar(255),c3 varchar(255),c4 varchar(255),c5 varchar(255),c6 varchar(255),c7 varchar(255),c8 varchar(255),c9 varchar(255),c10 varchar(255),c11 varchar(255))engine=I&insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));ERROR 1118 (42000): Row size too large (& 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.&(testing)root@localhost [wubx]& set global innodb_file_format=BARRACUDA;Query OK, 0 rows affected (0.00 sec)&(testing)root@localhost [wubx]& alter table tb_01 row_format=Query OK, 0 rows affected (0.19 sec)Records: 0&&Duplicates: 0&&Warnings: 0&(testing)root@localhost [wubx]& insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));Query OK, 1 row affected (0.00 sec)&&set global innodb_file_format=Acreate table tb_02(c1 varchar(2000),c2 varchar(2000),c3 varchar(2000),c4 varchar(2000),c5 varchar(2000),c6 varchar(2000),c7 varchar(2000),c8 varchar(2000))engine=I&insert into tb_02(c1, c2, c3,c4,c5,c6,c7,c8) values(repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000) );&&create table tb_03(c1 text,c2 text,c3 text,c4 text,c5 text,c6 text,c7 text,c8 text,c9 text,c10 text,c11 text)engine=Iinsert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));&(testing)root@localhost [wubx]& insert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));ERROR 1118 (42000): Row size too large (& 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.&set global innodb_file_format=BARRACUDA;alter table tb_03 row_format=
Posted by&
作者：吴炳锡　来源：http://wubx.net/ 联系方式：
转载请注明作/译者和出处，并且不能用于商业用途，违者必究.
MySQL二制进日志用于记录数据库的变更记录，这里从结构上讨论一下日志的格式。
每个日志都包含4个字节的magic number 和event的描述包
日志有前四个字节是magic number： oxfe ox62 0x69 0x6e = 0xfe ‘b”i”n’ 转成整数：
用处就是读4个字节对比不是这个数，说明就不是二进制日志，就不用处理了。
log_event.sh中可以查到
/* 4 bytes which all binlogs should begin with */
#define BINLOG_MAGIC
"\xfe\x62\x69\x6e"
&&log_event.sh中可以查到&&/* 4 bytes which all binlogs should begin with */&&&& #define BINLOG_MAGIC&&&&&&&&"\xfe\x62\x69\x6e"&
每个event的header大概如下：
- 每个event中包含： event的类型，什么时间，由哪版本的MySQL产生的
- 从header头能找到该event的大小及一些变更信息
- 每个event中包含： event的类型，什么时间，由哪版本的MySQL产生的 - 从header头能找到该event的大小及一些变更信息&
第一个event称为：format descriptor event(Event描述结构:FDE) 用于说明日志的格式
其它event就是依赖于描述结构不同，用不同的结构记录数据
最后一个event是： 日志切换事件（log-rotation event）用于指点定下个日志的文件名
每个event的结构大概如下：
+===================+
| event header
+===================+
| event data
+===================+
+===================+| event header&&&&&&|+===================+| event data&&&&&&&&|+===================+&
现在大多使用的V4结构，从MySQL 5.0起，具体如下：
+=====================================+
| timestamp
| header +----------------------------+
| type_code
+----------------------------+
| server_id
+----------------------------+
| event_length
+----------------------------+
| next_position
+----------------------------+
+----------------------------+
| extra_headers
19 : x-19 |
+=====================================+
| fixed part
+----------------------------+
| variable part
+=====================================+
1234567891011121314151617181920
+=====================================+| event&&| timestamp&&&&&&&& 0 : 4&&&&|| header +----------------------------+|&&&&&&&&| type_code&&&&&&&& 4 : 1&&&&||&&&&&&&&+----------------------------+|&&&&&&&&| server_id&&&&&&&& 5 : 4&&&&||&&&&&&&&+----------------------------+|&&&&&&&&| event_length&&&&&&9 : 4&&&&||&&&&&&&&+----------------------------+|&&&&&&&&| next_position&&&&13 : 4&&&&||&&&&&&&&+----------------------------+|&&&&&&&&| flags&&&&&&&&&&&&17 : 2&&&&||&&&&&&&&+----------------------------+|&&&&&&&&| extra_headers&&&&19 : x-19 |+=====================================+| event&&| fixed part&&&&&&&&x : y&&&&|| data&& +----------------------------+|&&&&&&&&| variable part&&&&&&&&&&&&&&|+=====================================+&
第一个event是FDE结构没有extra_headers部分，所以固定为19个字节。
FDE的event_data中定长部分为：
2字节的的日志格式版本，从MySQL 5.0后都是4
50字节 用于记录MySQL的版本号 如：5.6.16-64.2-rel64.2-log 不够50字节用0x00填充
4字节 日志产生的时间
1字节 header长度。一般是19，如果大于19，则下面的event都有extra_header字段
对于FDE变长部分一般为空
其它Event计算
header length = x byte
data length = (event_lenth -x )byte
数据区里定长部分长度
fixed_part = y byte
variable_part = (event_length - (x+y)) byte
&&fixed_part = y byte&&variable_part = (event_length - (x+y)) byte&
如果给定的X不是19，则存extra_header里面有内存
Y依赖于event_type有不同的大小，需要参考不同的event进行特别处理
参考：/doc/internals/en/event-data-for-specific-event-types.html
Posted by&
作者：吴炳锡　来源： 联系方式：select unhex(&#96EDF6D’); 载请注明作/译者和出处，并且不能用于商业用途，违者必究。
为什么需要在Windows下编译MySQL？
在Linux下编译MySQL是非常方便的操作，而且是轻车熟路，很容易搞定的。随着对MySQL的使用时间的增长，也慢慢的对MySQL代码的分析有点感兴趣了。所以想着找一个工具去学习一下MySQL的代码，对于Linux用户可以使用vim+ctags去分析，
但做为大多数用户来说工作的平台还都是windows平台。所以就需要在windows上去调试MySQL了。
对于下载的MySQL在Windows平台上无法直接编译的，工程文件没了，这里关建问题就是怎么创建一个工程文件。下面我装分几步去讲解，怎么去创建工程文件，怎么调试，怎么编译。
准备工作：
　　安装一个编译器，推荐Microsoft visual studio 2008吧
　　另外需要装:
GNU Bison for Windows :http://gnuwin32.sourceforge.net/packages/bison.htm
CMake 2.6.0 or later
http://www.cmake.org
开始编译：
这里以mysql-5.1.38的源码编译为例：
mysql-5.1.38的代码下载可以到mysql官方网站下载，具体怎么下载不在说明。
打开一个cmd窗口：
cscript //H:CScript
cd /path/mysql-5.1.38
win\configure WITH_INNOBASE_STORAGE_ENGINE __NT__
win\build-vs9.bat
到此我们将会创建一个mysql.sln　的工程文件，如果对想学习代码的朋友，到此即可以，然后可以用Microsoft visual studio 2008打开这个文件就可以查看相应的代码了。
如果需要调试或单步执行调试：
这里以mysqld项目为例：
　　打开项目　mysqld 的属性　点击　debugging
在mysqld的属性页设置命令参数（Command Arguments)为：–console。这样就可以用debug方式调试代码了。
同样对于其它项目的调试，也是这样处理，属性，添加命令行参数：–console。
对于想跟踪的项目可以执行build，然后可以在mysql-5.1.38/client/Debug下生成相应的执行文件。
如果真的想编译一个Windows的MySQL，上面那个打开步骤可以不做。接着上面完成的bat后，直接进行：
vcbuild mysql.sln “Release”
进行编译。然后拷mysqld.exe及相应的文件到相应的目录就ＯＫ了。具体怎么安装，这里也不在说明了。本文档的核心目的就是教会大家怎么创建工程文件，然后怎么去调试。MySQL Antelope和Barracuda的区别分析_百度知道
MySQL Antelope和Barracuda的区别分析
提问者采纳
希捷Barra.：酷鱼，主要面向多媒体开发人员和骨灰级玩家。 Barracuda XT（或STAS）.Barracuda是希捷科技股份有限公司(Seagate Technology)出品的一款硬盘产品系列的总称。中文名，是希捷推出的业界首款符合6Gbps规范容量为2TB的高端硬盘
其他类似问题
为您推荐：
barracuda的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁MySQL Antelope和Barracuda的区别分析_百度知道
MySQL Antelope和Barracuda的区别分析
不会进行overflow page存储. 　　Barracuda 　　(innodb-plugin) 　　ROW_FORMAT=DYNAMIC 　　ROW_FORMAT=COMPRESSED 　　 　　这两者主要是功能上的区别功能上的，其它的overflow page存储。 　　compact的存储格式为首部为一个非NULL的变长字段长度列表 　　redundant的存储格式为首部是一个字段长度偏移列表（每个字段占用的字节长度及其相应的位移）　　文件格式 支持行格式 特性 　　Antelope 　　（Innodb-base） 　　ROW_FORMAT=COMPACT 　　ROW_FORMAT=REDUNDANT 　　Compact和redumdant的区别在就是在于首部的存存内容区别。 　　在Antelope中对于变长字段，某些情况下会减少结果集IO。　另外在行里的变长字段和Antelope的区别是只存20个字节，低于768字节的
为您提供更好的产品和服务
主营：七彩虹品牌主板，显卡等电脑及配件产品
其他类似问题
为您推荐：
barracuda的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁mysql&innodb（61）
/** There are currently two InnoDB fileformats which are used to group
features with similar restrictions anddependencies. Using an enum allows
switch statements to give a compilerwarning when a new one is introduced. */
enum innodb_file_formats_enum {
&&&&&&&& /**Antelope File Format: InnoDB/MySQL up to 5.1.
&&&&&&&& Thisformat includes REDUNDANT and COMPACT row formats */
&&&&&&&& UNIV_FORMAT_A&&&&&&&&&&&& =0,
&&&&&&&& /**Barracuda File Format: Introduced in InnoDB plugin for 5.1:
&&&&&&&& Thisformat includes COMPRESSED and DYNAMIC row formats.& It
&&&&&&&& includesthe ability to create secondary indexes from data that
&&&&&&&& isnot on the clustered index page and the ability to store more
&&&&&&&& dataoff the clustered index page. */
&&&&&&&& UNIV_FORMAT_B&&&&&&&&&&&& =1
Barracuda文件格式由innodb5.1引入，包括compressed和dynamic文件格式。Barracuda与Antelope的区别在于barracuda可以在不在聚集索引页的数据上创建二级索引，并且能存更多数据在溢出页。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：24616次
排名：千里之外
原创：62篇
转载：49篇
(3)(3)(4)(7)(4)(5)(4)(4)(4)(4)(5)(6)(4)(6)(7)(6)(1)(4)(8)(2)(6)(9)(8)