主页 / dba / 问题 / 89429
Accepted
Bohemian
Asked: 2015-01-16 16:49:59 +0800 CST

当所有值都是 36 个字符时，使用 char 与 varchar 进行索引查找会明显更快吗

  • 772

我有一个遗留模式（免责声明！），它使用基于哈希生成的 id 作为所有表的主键（有很多）。这种 id 的一个例子是：

922475bb-ad93-43ee-9487-d2671b886479

改变这种方法是不可能的，但是索引访问的性能很差。撇开这可能的种种原因不谈，我注意到有一件事似乎不太理想——尽管所有许多表中的所有 id 值的长度都正好是 36 个字符，但列类型是varchar(36)，而不是 char(36)。

将列类型更改为固定长度char(36)是否会提供任何显着的索引性能优势，除了每个索引页的条目数量的非常小的增加等？

即 postgres 在处理固定长度类型时是否比处理可变长度类型时执行得更快？

请不要提及微小的存储节省 - 与更改列所需的手术相比，这无关紧要。

postgresql performance

1 个回答

  1. Best Answer

    不，没有任何收获。该手册明确指出：

    提示：这三种类型之间没有性能差异，除了在使用空白填充类型时增加了存储空间，以及在存储到长度受限的列时需要一些额外的 CPU 周期来检查长度。虽然character(n)在其他一些数据库系统中具有性能优势，但在 PostgreSQL 中没有这样的优势；事实上character(n)，由于其额外的存储成本，它通常是三者中最慢的。在大多数情况下应该使用text orcharacter varying来代替。

    大胆强调我的。

    char(n)是一种很大程度上过时、无用的类型。坚持varchar(n)。无需强制执行最大长度，varchar或者text更快一点，并发症更少。

    如果所有字符串的长度正好是 36 个字符，那么无论哪种方式都不会节省存储空间，即使是很小的存储空间也是如此。两者在磁盘和 RAM 中的大小完全相同。您可以使用pg_column_size()（在表达式和表格列上）进行测试。

    如果所有字符串都必须有 36 个字符，那么最好text使用CHECK (length(col) = 36)强制执行精确长度的约束，而varchar(36)不仅仅是强制执行最大长度。长度。看：

    您没有要求其他选项，但我会提到两个：

    1.COLLATION

    除非您使用“C”排序规则运行您的数据库。整理经常被忽视并且可能很昂贵。由于您的字符串在自然语言中似乎没有意义，因此遵循COLLATION规则可能没有意义。有关的：

    广泛的基准比较（除其他外）COLLATE "C"对性能的影响：

    2.UUID _

    您的字符串可疑地看起来像一个 UUID（32 个十六进制数字，以规范方式由 4 个分隔符分隔）。将 UUID 存储为实际数据类型效率更高：以多种方式更快，并且每个 UUIDuuid仅占用16个字节 - 与RAM 中的37char(36)个字节或varchar(36)（不带分隔符存储，仅 32 个定义字符）或33个字节相反在磁盘上。但是在许多情况下，对齐填充会导致40个字节。）也与数据类型COLLATION无关。uuid

    SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

    这可能会有所帮助（最后几章）：

    也可以看看：

    • 53

相关问题