要挑选有助于使查询执行更快的列，应遵照如下原则(这里，“BLOB 类型”应该明白为即包括B L O B也包括TEXT 类型)：
运用定长列，不运用可变长列。这条原则对被经常修正，从而容易发生碎片的表来说特别首要。比如，应该挑选CHAR 列而不挑选VARCHAR 列。所要权衡的是运用定长列时，表所占用的空间更多，但假设能够承当这种空间的消耗，运用定长行将比运用可变长的行处理快得多。
在较短的列能够满足要求时不要运用较长的列。假设正运用的是定长的CHAR 列，应该使它们尽量短。假设列中所存储的最长值为40 个字符，那么就不要将其定义为CHAR ( 2 5 5 );只需定义为CHAR(40) 即可。假设能够运用MEDIUMINT 而不是BIGINT，表将会更小(硬盘I/O 也较少)，其值在计算中也能够处理得更快。
将列定义为NOT NULL。这样处理更快，所需空间更少。并且有时还能简化查询，由于不须要检验能不能存在特例NULL。
思索运用ENUM 列。假设有一个只含有限数目标特定值的列，那么应该思索将其转换为ENUM 列。ENUM 列的值能够更快地处理，由于它们在内部是以数值表示的。
运用PROCEDURE ANALYSE( )。假设运用的是MySQL3.23 或更新的版本，应该执行PROCEDURE ANALYSE( )，检查它所提供的关于表中列的信息：
相应输出中有一列是关于表中每列的最好列类型的建议。第二个例子要求PROCEDURE ANALYSE( ) 不要建议含有多于16 个值或取多于256 字节的ENUM 类型(可依据须要修改这些值)。假设没有这样的限定，输出能够会很长;ENUM 的定义也会很难阅读。依据PROCEDURE ANALYSE( ) 的输出，会发觉能够对表执行修改以运用更有效的类型。假设期盼修改值类型，运用ALTER TABLE 语句即可。
将数据装入B L O B。用BLOB 存储运用顺序中包装或未包装的数据，有能够使原来须要多个检索操作才干完成的数据检索得以在单个检索操作中完成。并且还对存储规范表结构不易表示的数据或随时间改变的数据有协助。在第3 章ALTER TABLE 语句的简介中，有一个例子处理存储来自Web 问卷的结果的表。该例子中探讨了在问卷中添加疑问时，怎样运用ALTER TABLE 向该表追加列。
处理该疑问的另一个方法是让处理Web 的运用顺序将数据包装成某种数据结构，然后将其插入单个BLOB 列。这样会添加运用顺序对数据执行解码的开支(并且从表中检索出记载后要对其执行编码)，但是简化了表的结构，并且不必在修改问卷时对表执行修改。另一方面， BLOB 值也有自己的固有疑问，特别是在执行大量的DELETE 或UPDATE 操作时更是如此。删除BLOB 会在表中留下一个大空白，在现在将需用一个记载或能够是不一样大小的多个记载来填充。
对容易发生碎片的表运用OPTIMIZE TABLE。大量执行修正的表，特别是那些含有可变长列的表，容易发生碎片。碎片不好，由于它在存储表的硬盘块中发生不运用的空间。随着时间的增长，必需读取更多的块才干取到有效的行，从而降低了功用。恣意具有可变长行的表都存在这个疑问，但这个疑问对BLOB 列更为突出，由于它们尺寸的改变十分大。经常运用OPTIMIZE TABLE 有助于坚持功用不降低。
