MySQL存儲和優化

我正在查看我正在繼承的項目的數據庫模式。有很多二進制答案被存儲爲INT（11）而不是TinyInt（1），這是我通常處理這種類型或存儲的方式。MySQL存儲和優化

我檢查了數據，一切都是「1」或「0」。是否有任何理由要或不要將數據類型更改爲TinyInt（1）對於所有這些實例，都是未簽名的？

同樣，如果像「姓氏」如果當前列允許爲varchar（255），將切換爲varchar（100）產生任何收益？我對性能/效率更感興趣，而不是僅僅限制數據存儲。

感謝， D.

來源

2011-06-09 Don

我會說肯定繼續對布爾列的更改。（注意：其實如果你使用的是MySQL 5+，我會使用bit數據類型而不是tinyint）。

就varchar列而言，它實際上並沒有改變255到100的長度。

從SQL文檔：

A柱使用一個長度字節如果值不需要超過255字節， 2長度個字節，如果值可能需要超過255個字節。

所以，只要它在255以下，你在內存存儲方面真的沒什麼收穫。這就是說，通過限制名稱的大小，需要在SQL服務器和應用程序之間傳輸更少的數據。

來源

2011-06-09 18:14:25 Swift

對varchar列**沒有影響，只要它們沒有索引**。 – Hammerite 2011-06-09 18:22:42

我會想象這與傳輸速度有關，而不是內存分配，對嗎？ – Swift 2011-06-09 18:27:21

我在問題中沒有看到任何內容，表明傳輸速度是優先考慮的因素。但除此之外，我的印象是，保持指數很小會產生很多好處（雖然是的，主要好處是在內存佔用）。 – Hammerite 2011-06-09 20:01:15

切換到TINYINT會爲您節省3個字節，我相信，這似乎不是一個對我很重要，但它肯定是一個小更高效。

我總是嘗試使VARCHAR列儘可能小，因爲我可以逃脫。我會親自關注你可以從中獲得的任何收益。

我能想到的，以避免這些變化的主要原因是，如果你有一個運行的ALTER TABLE會導致顯著的停機時間如此多的數據。

這些是否有助於您的應用更好地發揮作用，可以進行辯論。從理論上講，使用VARCHAR時，MySQL只會通過線路發送實際數據，所以如果所有姓氏的長度都是40個字節，則只能發送40個字節。如果該列未在查找中使用，則不應該對您的性能產生任何影響。在SO上有幾個相關的問題like this one已經涵蓋了這個問題。

來源

2011-06-09 18:13:09 muffinista

3個字節是很多，如果你一百萬/十億行... – 2011-06-09 18:24:43

可以肯定的相乘，它的很多，如果你需要通過電匯一百萬行，但沒有太多的每個記錄的基礎。 – muffinista 2011-06-09 18:28:24

即使在硬盤上。如果你有一百萬/十億行，那麼每行3個字節的總和就會增加到3MB/3GB ......我意識到存儲是便宜的，但它不是存儲除「比特」之外的任何布爾值的理由。 – 2011-06-09 18:30:13

MySQL存儲和優化

回答

相關問題