在SQL中增加列大小的潜在风险是什么？

Question

假设我在名为Ticket的表中有一个名为ShortDescription的列。

ShortDescription varchar (16) NOT NULL 

现在，假设我增加大小这样的 -

alter table Ticket modify ShortDescription varchar (32) NOT NULL; 

什么是这样做的潜在风险？一个潜在的风险是，如果其他应用程序根据之前的ShortDescription大小将其字段中的任何一个字段静态设置为16，那么这些应用程序可能无法正确处理更大尺寸的数据。

Answer 1

SQL是一种查询语言，而不是一个具体的实施DB，所以你的里程可能会有所不同，但是......

假设“SQL”是指在DB网站MySQL数据库你已经没有什么可担心的存储和性能超出事实，如果你存储了一堆32字节的叮咬，你会用更多的内存和磁盘来处理它们，但是如果你实际存储的内容是16字节字符，那么转换为VARCHAR（32）就是洗。

在MySQL中，VARCHAR没有影响（假设你保持NOT NULL）。如果在复合主键中使用该列，则可能会达到大小限制，但是否则所有varchar条目都只会占用数据大小+1个字节进行存储。

如果列被引用为某个其他表中的foriegn键，则需要将该列扩展到VARCHAR（32），或者如果尝试在32个字符字符串转换为16个字符的列。

如果不是MySQL，实施可能会因数据库技术而有所不同。但是，VARCHAR的实现往往是相似的，只使用存储数据的大小，然后用一个常量表示数据的结束。因此，为什么在许多数据库系统中，通常有多个选项具有静态CHAR和动态VARCHAR类型。

正如您在文章中指出的那样，必须考虑依赖静态数据大小的外部系统。

注：请原谅条款byte 和character，我假设UTF8或ASCII以上快速和*交换。如果您正在使用多字节编码 ，请适当替换。