使用更小的 varchar 大小，我的數據庫索引是否會更高效？

我們正在使用 Mysql 5.7

我們在大約 500M 行的表中的 varchar(255) 列上有一個索引。

select distinct varchar_column from table產生七個結果，最大長度為 21。

一位 DBA 顧問建議我們將 varchar 列的長度減少到 21。在測試中減少 varchar 列的大小相當於在不更改架構的情況下對錶進行碎片整理（例如alter table）。

當我們將長度減少到 17 時，我們看到了稍微好一點的結果。

除了索引大小之外，我們還缺少什麼優勢嗎？

如果某些值是 21 個字元，則降至 17 會失去數據。你可能不想這樣做。

保守一點——未來的數據會是什麼樣子？也許22個字元？將長度降低到 30。

更改最大長度不會節省空間——在“數據”或“索引”中。好吧，不是因為改變。但是，大多數都ALTERs包括某種程度的重建表。這可能會擠出一些而不是全部釋放或浪費的空間。要明白我的意思，

SHOW TABLE STATUS LIKE 't';   -- current size
OPTIMIZE TABLE t;
SHOW TABLE STATUS LIKE 't';   -- defragmented size
ALTER TABLE t MODIFY COLUMN c VARCHAR(30)...;`
SHOW TABLE STATUS LIKE 't';   -- probably no change to Data_length or Index_length

表現？在一個複雜SELECT的地方，需要建立一個臨時表，臨時VARCHARs變成CHARs。對於 utf8mb4，即 4255 字節與 430。這導致體積龐大。如果臨時表對於 RAM 來說太大，它將溢出到磁碟。磁碟速度較慢，甚至 SSD 也是如此。

使用列時會有一些 CPU 流失，VARCHAR因為必須進行長度計算。VARCHAR(21)無論或，這都是真的VARCHAR(255)。如果您正在尋找更快的速度，則必須將其更改VARCHAR(21)為CHAR(21).

這將使行長度和索引更大，但您會看到更好的結果。大小與速度的權衡是非常值得的。

我之前討論過這個

• May 10, 2011; 在固定大小的欄位上使用 CHAR 與 VARCHAR 對性能有何影響？
• Mar 25, 2011: MySQL VARCHAR 大小的性能影響

對於使用 MySQL 5.x 的使用者，您應該使用以下方法確定正確的大小和類型

select distinct varchar_column from table PROCEDURE ANALYSE();

請參閱有關 PROCEDURE ANALYSE() 的 MySQL 5.7 文件。（在 8.0 中已棄用）。

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