My SQL数据库实用技术（22）

4.3 列类型选择与查询效率
要选择有助于使查询执行更快的列，应遵循如下规则（这里，“BLOB 类型”应该理解为即包含B L O B也包含TEXT 类型）：
■ 使用定长列，不使用可变长列。这条准则对被经常修改，从而轻易产生碎片的表来说非凡重要。例如，应该选择CHAR 列而不选择VARCHAR 列。所要权衡的是使用定长列时，表所占用的空间更多，但假如能够承担这种空间的耗费，使用定长行将比使用可变长的行处理快得多。
■ 在较短的列能够满足要求时不要使用较长的列。假如正使用的是定长的CHAR 列，应该使它们尽量短。假如列中所存储的最长值为40 个字符，那么就不要将其定义为CHAR ( 2 5 5 )；只要定义为CHAR(40) 即可。假如能够使用MEDIUMINT 而不是BIGINT，表将会更小（磁盘I/O 也较少），其值在计算中也可以处理得更快。
■ 将列定义为NOT NULL。这样处理更快，所需空间更少。而且有时还能简化查询，因为不需要检查是否存在特例N U L L。
■ 考虑使用ENUM 列。假如有一个只含有限数目的特定值的列，那么应该考虑将其转换为ENUM 列。ENUM 列的值可以更快地处理，因为它们在内部是以数值表示的。
■ 使用PROCEDURE ANALYSE( )。假如使用的是MySQL 3.23 或更新的版本，应该执行PROCEDURE ANALYSE( )，查看它所提供的关于表中列的信息： dedecms.com

相应输出中有一列是关于表中每列的最佳列类型的建议。第二个例子要求PROCEDURE ANALYSE( ) 不要建议含有多于16 个值或取多于256 字节的ENUM 类型（可根据需要更改这些值）。假如没有这样的限制，输出可能会很长；ENUM 的定义也会很难阅读。根据PROCEDURE ANALYSE( ) 的输出，会发现可以对表进行更改以利用更有效的类型。假如希望更改值类型，使用A LTER TABLE 语句即可。
■ 将数据装入B L O B。用BLOB 存储应用程序中包装或未包装的数据，有可能使原来需要几个检索操作才能完成的数据检索得以在单个检索操作中完成。而且还对存储标准表结构不易表示的数据或随时间变化的数据有帮助。在第3 章A LTER TABLE 语句的介绍中，有一个例子处理存储来自Web 问卷的结果的表。该例子中讨论了在问卷中增加问题时，怎样利用A LTER TABLE 向该表追加列。
解决该问题的另一个方法是让处理Web 的应用程序将数据包装成某种数据结构，然后将其插入单个BLOB 列。这样会增加应用程序对数据进行解码的开销（而且从表中检索出记录后要对其进行编码），但是简化了表的结构，并且不用在更改问卷时对表进行更改。另一方面， BLOB 值也有自己的固有问题，非凡是在进行大量的DELETE 或UPDATE 操作时更是如此。删除BLOB 会在表中留下一个大空白，在以后将需用一个记录或可能是不同大小的多个记录来填充。 本文来自织梦
■ 对轻易产生碎片的表使用OPTIMIZE TA B L E。大量进行修改的表，非凡是那些含有可变长列的表，轻易产生碎片。碎片不好，因为它在存储表的磁盘块中产生不使用的空间。随着时间的增长，必须读取更多的块才能取到有效的行，从而降低了性能。任意具有可变长行的表都存在这个问题，但这个问题对BLOB 列更为突出，因为它们尺寸的变化非常大。经常使用OPTIMIZE TABLE 有助于保持性能不下降。
■ 使用合成索引。合成索引列有时很有用。一种技术是根据其他列建立一个散列值，并将其存储在一个独立的列中，然后可通过搜索散列值找到行。这只对精确匹配的查询有效。（散列值对具有诸如“ <”或“ > =”这样的操作符的范围搜索没有用处）。在MySQL 3.23版及以上版本中，散列值可利用MD5( ) 函数产生。散列索引对BLOB 列非凡有用。有一事要注重，在MySQL 3.23.2 以前的版本中，不能索引BLOB 类型。甚至是在3.23.2 或更新的版本中，利用散列值作为标识值来查找BLOB 值也比搜索BLOB 列本身更快。

看完这篇，您有何感觉呢？