要选择有助于使查询执行更快的列，应遵循如下规则（这里，“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 有助于保持性能不下降。
使用合成索引。合成索引列有时很有用。一种技术是根据其他列建立一个散列值，并将其存储在一个独立的列中，然后可通过搜索散列值找到行。这只对精确匹配的查询有效。（散列值对具有诸如“ <”或“ > =”这样的操作符的范围搜索没有用处）。在MySQL3.23版及以上版本中，散列值可利用MD5( ) 函数产生。散列索引对BLOB 列特别有用。有一事要注意，在MySQL3.23.2 以前的版本中，不能索引BLOB 类型。甚至是在3.23.2 或更新的版本中，利用散列值作为标识值来查找BLOB 值也比搜索BLOB 列本身更快。
除非有必要，否则应避免检索较大的BLOB 或TEXT 值。例如，除非肯定WHERE 子句能够将结果恰好限制在所想要的行上，否则SELECT * 查询不是一个好办法。这样做可能会将非常大的BLOB 值无目的地从网络上拖过来。这是存储在另一列中的BLOB 标识信息很有用的另一种情形。可以搜索该列以确定想要的行，然后从限定的行中检索BLOB 值。
将BLOB 值隔离在一个独立的表中。在某些情况下，将BLOB 列从表中移出放入另一个副表可能具有一定的意义，条件是移出BLOB 列后可将表转换为定长行格式。这样会减少主表中的碎片，而且能利用定长行的性能优势。
