MySQL列类型选择和查询效率有怎样的联系呢?要选择有助于使查询执行更快的MySQL列类型，应遵循规则。下面学步园小编来讲解下MySQL列类型选择和查询效率有怎样的联系?
MySQL列类型选择和查询效率有怎样的联系
■使用定长列，不使用可变长列。这条准则对被经常修改，从而容易产生碎片的表来说特别重要。例如，应该选择CHAR列而不选择VARCHAR列。所要权衡的是使用定长列时，表所占用的空间更多，但如果能够承担这种空间的耗费，使用定长行将比使用可变长的行处理快得多。
■在较短的列能够满足要求时不要使用较长的列。如果正使用的是定长的CHAR列，应该使它们尽量短。如果列中所存储的最长值为40个字符，那么就不要将其定义为CHAR(255);只要定义为CHAR(40)即可。如果能够使用MEDIUMINT而不是BIGINT，表将会更小(磁盘I/O也较少)，其值在计算中也可以处理得更快。
■将列定义为NOTNULL。这样处理更快，所需空间更少。而且有时还能简化查询，因为不需要检查是否存在特例NULL。
■考虑使用ENUM列。如果有一个只含有限数目的特定值的列，那么应该考虑将其转换为ENUM列。ENUM列的值可以更快地处理，因为它们在内部是以数值表示的。
■使用PROCEDUREANALYSE()。如果使用的是MySQL3.23或更新的版本，应该执行PROCEDUREANALYSE()，查看它所提供的关于表中列的信息：
相应输出中有一列是关于表中每列的最佳列类型的建议。第二个例子要求PROCEDUREANALYSE()不要建议含有多于16个值或取多于256字节的ENUM类型(可根据需要更改这些值)。如果没有这样的限制，输出可能会很长;ENUM的定义也会很难阅读。根据PROCEDUREANALYSE()的输出，会发现可以对表进行更改以利用更有效的类型。如果希望更改值类型，使用ALTERTABLE语句即可。
MySQL列类型选择和查询效率有怎样的联系
■将数据装入BLOB。用BLOB存储应用程序中包装或未包装的数据，有可能使原来需要几个检索操作才能完成的数据检索得以在单个检索操作中完成。而且还对存储标准表结构不易表示的数据或随时间变化的数据有帮助。在第3章ALTERTABLE语句的介绍中，有一个例子处理存储来自Web问卷的结果的表。该例子中讨论了在问卷中增加问题时，怎样利用ALTERTABLE向该表追加列。
解决该问题的另一个方法是让处理Web的应用程序将数据包装成某种数据结构，然后将其插入单个BLOB列。这样会增加应用程序对数据进行解码的开销(而且从表中检索出记录后要对其进行编码)，但是简化了表的结构，并且不用在更改问卷时对表进行更改。另一方面，BLOB值也有自己的固有问题，特别是在进行大量的DELETE或UPDATE操作时更是如此。删除BLOB会在表中留下一个大空白，在以后将需用一个记录或可能是不同大小的多个记录来填充。
■对容易产生碎片的表使用OPTIMIZETABLE。大量进行修改的表，特别是那些含有可变长列的表，容易产生碎片。碎片不好，因为它在存储表的磁盘块中产生不使用的空间。随着时间的增长，必须读取更多的块才能取到有效的行，从而降低了性能。任意具有可变长行的表都存在这个问题，但这个问题对BLOB列更为突出，因为它们尺寸的变化非常大。经常使用OPTIMIZETABLE有助于保持性能不下降。
■使用合成索引。合成索引列有时很有用。一种技术是根据其他列建立一个散列值，并将其存储在一个独立的列中，然后可通过搜索散列值找到行。这只对精确匹配的查询有效。(散列值对具有诸如“<”或“>=”这样的操作符的范围搜索没有用处)。在MySQL3.23版及以上版本中，散列值可利用MD5()函数产生。散列索引对BLOB列特别有用。有一事要注意，在MySQL3.23.2以前的版本中，不能索引BLOB类型。甚至是在3.23.2或更新的版本中，利用散列值作为标识值来查找BLOB值也比搜索BLOB列本身更快。
■除非有必要，否则应避免检索较大的BLOB或TEXT值。例如，除非肯定WHERE子句能够将结果恰好限制在所想要的行上，否则SELECT*查询不是一个好办法。这样做可能会将非常大的BLOB值无目的地从网络上拖过来。这是存储在另一列中的BLOB标识信息很有用的另一种情形。可以搜索该列以确定想要的行，然后从限定的行中检索BLOB值。
■将BLOB值隔离在一个独立的表中。在某些情况下，将BLOB列从表中移出放入另一个副表可能具有一定的意义，条件是移出BLOB列后可将表转换为定长行格式。这样会减少主表中的碎片，而且能利用定长行的性能优势。
以上就是关于“MySQL列类型选择和查询效率有怎样的联系”的内容，希望对大家有用。更多资讯请关注学步园。学步园，您学习IT技术的优质平台!