Mysql：字段大小/顯示寬度是否影響索引性能？

Question

CREATE TABLE student(
`id` int(11) auto_increment PRIMARY KEY
`grade` int(11)
)

假設我想在grade列上添加索引。 如果它具有較小的顯示寬度，例如int(4) ，它會有所不同嗎？

編輯：

• 這里的performance是指查詢時間。

• 另外，不清楚列顯示寬度是否影響索引大小。 我們正在考慮一個至少有數百萬行的非常大的表。 如果答案可以闡明這一點，那就太好了。

Answer 1

首先，顯示在任何情況下都沒有區別——它只是關於字段在查詢響應中的表示方式。 一個int仍然和int使用 4 個字節，一個bigint是一個使用 8bytes 的bigint等等......

您從什么方面考慮“性能”？ 保持數據和索引加載或緩存所需的總請求時間、內存使用情況？ 磁盤空間？

我猜你的意思是，它會影響查詢響應的速度。

然而，這個問題非常廣泛，真正的答案是，這取決於。 你的系統是64位還是32位？ 我們在談論多少記錄？ 該字段是一個更大的復合索引的一部分，但仍然是它的一小部分嗎？

（注意：需要對此聲明進行檢查，例如 CHAR 是否只是針對索引進行散列）從 a 或 CHAR(4) 轉到 CHAR(32) 並確保您可能會發現一些不可忽略的性能影響，但這不是由於復雜性，但您的操作系統和架構處理這些的額外開銷。

但是，我將大膽提出建議，除非更改類型（int 到 varchar），否則可能會更改索引方法或索引存儲大小的大量更改，否則您可能不會“看到”任何區別。 我懷疑在不同的整數類型之間您是否能夠輕松地顯示一致的減速。

Answer 2

簡短回答： (4)對INT沒有任何意義。

龍哥 回復:

列大小影響行大小，從而影響表大小，進而影響查詢速度。 但...

如果表“小”，則性能差異很小。

如果該表大於 RAM 中可以緩存的大小，則差異可能很大——因為您可能會受到 I/O 限制。 在某些情況下，這是十倍的減速。

要縮小始終為 4 個字節的INT ，請切換到TINYINT UNSIGNED （1 個字節，范圍：0..255）、 SMALLINT UNSIGNED （2 個字節，0..65K）或MEDIUMINT UNSIGNED （3 個字節，0..16M） ）。

假設grade是 0..100，那么TINYINT （有符號或無符號）是最佳的。

同時，您可以更改您的更改id 。

INT(4)的唯一目的是與ZEROFILL結合使用，您希望將 12 顯示為0012 。 這是極其罕見的。

除非字符串是真正固定長度的字符串，否則不要使用CHAR 。 然后它可能應該明確聲明為CHARACTER SET ascii因為它是十六進制、所有數字或 2 個字母的 country_code（等）。 無論如何，utf8 是矯枉過正。

假設您使用的是 InnoDB，“次要” INDEX(grade)將隱式包含PRIMARY KEY(id) 。 所以每個索引條目的大小是grade的大小加上id的大小加上一堆開銷。 假設成績正常且學生不超過 65K，您可以使用 3 個字節而不是原來的 8 個字節。但表很小，因此您不太可能受到 I/O 限制。 因此 8 而不是 3 的開銷很小。