参考Character Types上的Postgres文档，我不清楚指定字符变化（varchar）类型的长度。
假设：
确实提到：
短字符串（最多126个字节）的存储要求是1个字节 加上实际的字符串，包括案例中的空格填充 性格。较长的字符串有4个字节的开销而不是1个字节。 系统会自动压缩长字符串，所以 磁盘上的物理要求可能更低。很长的价值也是 存储在后台表中，以便它们不会快速干扰 访问较短的列值。无论如何，最长的可能 可以存储的字符串大约是1 GB。 （最大值 在数据类型声明中将允许n小于 那。使用多字节进行更改是没有用的 字符编码的字符数和字节数可以相当 不同。
这讨论了字符串的大小，而不是字段的大小（即声音总是会压缩大型varchar字段中的大字符串，而不是大型varchar字段中的小字符串？）
我问这个问题，因为指定一个更大的尺寸会更容易（和懒惰），所以你永远不必担心字符串太大。例如，如果我为地名指定varchar（50），我将获得具有更多字符的位置（例如Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch），但如果我指定varchar（100）或varchar（500），我就不太可能得到这个问题
如果您的最大字符串长度为400个字符，那么您会在varchar（500）和（任意）varchar（5000000）或text（）之间获得性能影响吗？
如果有人对此有答案并且知道其他数据库的答案，也不感兴趣，请添加。
我用Google搜索，但没有找到足够技术性的解释。
答案 0 :(得分：12)
我的理解是，拥有约束对于数据完整性非常有用，因此我使用列大小来验证较低层的数据项，并更好地描述数据模型。
关于此事的一些链接：
答案 1 :(得分：5)
我的理解是，这是旧数据库的遗留物，其存储空间不如Postgres灵活。有些人会使用固定长度的结构来轻松找到特定的记录，而且由于SQL是一种有些标准化的语言，即使它没有提供任何实际的好处，它仍然可以看到遗产。
因此，你的“大做强”的方法对于Postgres应该是一个完全合理的方法，但它可能无法很好地转移到其他不太灵活的RDBMS系统。
答案 2 :(得分：3)
文档解释了这一点：
如果在没有长度说明符的情况下使用字符变化，则该类型接受任何大小的字符串。后者是PostgreSQL扩展。
SQL标准要求所有类型的长度规范。这可能主要是出于遗留原因。在PostgreSQL用户中，偏好倾向于省略长度规范，但如果要编写可移植代码，则必须包含它（并在许多情况下选择任意大小）。
答案 3 :(得分：1)
还有两个想法：
Postgres文档说，非常长的值也存储在背景表格中。因此，将所有字符串定义为无界可能会将它们推送到背景表中 - 确保性能受到影响。
长时间宣布所有内容会干扰数据库预测查询执行计划的工作，因为它对数据知之甚少。
构建包含索引的b树也会被抛弃，因为它无法猜出合理的打包策略。例如，如果性别是TEXT，你怎么知道它只是M或F？