列的數據類型會影響查詢性能嗎？

假設我有這張桌子：

Table "public.orders"
        Column      |     Type      | Collation | Nullable | Default 
   -----------------+---------------+-----------+----------+---------
    o_orderkey      | integer       |           | not null | 
    o_custkey       | integer       |           |          | 
    o_orderstatus   | character(1)  |           |          | 
    o_totalprice    | numeric(12,2) |           |          | 
    o_orderdate     | date          |           |          | 
    o_orderpriority | character(15) |           |          | 
    o_clerk         | character(15) |           |          | 
    o_shippriority  | integer       |           |          | 
    o_comment       | character(79) |           |          |

如果我有涉及o_orderstatus、或列的查詢，我可以將數據類型更改o_orderpriority為以改進它們嗎？o_clerk``o_comment``char(n)``text

是的。而且可能很多。

使用(alias )永遠不會獲得性能。您根本沒有任何收穫，因為該類型已過時，大多無用且不受歡迎。有關的：character(n)``char(n)

• 當所有值都是 36 個字元時，使用 char 與 varchar 進行索引查找會明顯更快嗎

但是您在手冊的引文中看到了這一點：

除了使用空白填充類型時增加儲存空間

char(n)是空白填充類型。像這樣的列名comment主要表示空白填充的廢物。text或varchar消除臃腫，你桌子周圍的一切都會變得更快，就像你的平均水平一樣。行大小可能縮小到不到一半。每個數據頁更多的元組意味著每個查詢要讀取和處理的頁面更少，這是影響性能的最重要因素。

在此期間，對列進行有利的排序以使其更高效，但是：

  Column      |     Type      | Collation | Nullable | Default 
---------------+---------------+-----------+----------+---------
orderkey      | integer       |           | not null | 
custkey       | integer       |           |          | 
orderdate     | date          |           |          | 
shippriority  | integer       |           |          | 
totalprice    | numeric(12,2) |           |          | 
orderstatus   | varchar(1)    |           |          | 
orderpriority | varchar(15)   |           |          | 
clerk         | varchar(15)   |           |          | 
comment       | varchar(79)   |           |          |

為什麼？

• 在 PostgreSQL 中計算和節省空間

我保留了長度限制varchar(n)，但如果這些只是任意的，請text改用。稍微快一點，但是。（並且減少了極端情況的麻煩。）請參閱：

• 我應該向 VARCHAR 列添加任意長度限制嗎？

引用自：https://dba.stackexchange.com/questions/312006