如何選擇列[innodb特定]的優化數據類型？

我正在學習數據庫數據類型的用法。如何選擇列[innodb特定]的優化數據類型？

例如：

哪一個電子郵件更好？ VARCHAR [100]，的char [100]或tinyint（開玩笑）
哪個用戶名更好？我應該使用int，bigint還是varchar？解釋。我的一些朋友說，如果我們使用int，bigint或其他數字數據類型，它會更好（Facebook做它）。就像u = 123400023引用用戶123400023，而不是用戶=用戶名稱。由於數字花費的時間更短。
哪個更適合電話號碼？帖子（如在博客或通告）？或者也許日期（我使用datetime）？也許有些人已經做了想要分享的研究。
產品價格（我使用十進制（11,2），不知道你們）？
或其他任何你的想法一樣，「我用的串行數據類型blablabla。」

爲什麼我提的InnoDB具體？

除非你使用的是InnoDB表類型（參見第11章，「高級的MySQL，」瞭解更多信息），CHAR 列更快地比 VARCHAR訪問。

的Inno DB有一些diffrence，我不知道。我從here讀到。

來源

2010-07-20 Adam Ramadhan

感謝colithium。我不知道如何處理鏈接哈哈。 – 2010-07-20 03:21:11

添加了mysql標籤。 – 2010-07-20 04:33:42

小結：

（只是我的意見）

對於電子郵件地址 - VARCHAR(255)
用戶名 - VARCHAR(100)或VARCHAR(255)
爲id_username - 使用INT（除非你計劃在系統中有超過20億用戶）
電話號碼 - TEXT
日期 - - INT或VARCHAR也許CHAR
職位（如果你想存儲格式取決於）DATE或DATETIME（肯定包括時代喜歡的事情的帖子或電子郵件）
錢 - DECIMAL(11,2)
雜項 - 見下文

至於使用的是InnoDB，因爲VARCHAR應該是更快，我不會擔心，或一般的速度。使用InnoDB是因爲您需要執行事務並且/或者您想使用外鍵約束（FK）來保證數據的完整性。另外，InnoDB使用行級鎖定，而MyISAM只使用表級鎖定。因此，InnoDB可以比MyISAM更好地處理更高級別的併發性。使用MyISAM可以使用全文索引並減少開銷。

對於速度而言，比引擎類型更重要：將索引放在需要快速搜索的列上。總是在您的ID/PK列上放置索引，例如我提到的id_username。

更多細節：

這裏有一堆關於MySQL的數據類型和數據庫設計問題（警告，超過你問）：

就當使用InnoDB引擎幾個問題：

我只是用tinyint幾乎一切（嚴重）。

編輯 - 如何存儲「的帖子：」

下面是更多的一些細節上的鏈接，但這裏的短版。爲了存儲「帖子」，你需要一個長文本字符串的空間。 CHAR最大長度爲255，所以這不是一個選項，當然CHAR會浪費未使用的字符與VARCHAR，這是可變長度CHAR。

在MySQL 5.0.3之前，VARCHAR最大長度爲255，所以你應該留下TEXT。但是，在更新版本的MySQL中，您可以使用VARCHAR或TEXT。選擇歸結爲偏好，但有一些差異。 VARCHAR和TEXT現在最大長度均爲65,535，但您可以在VARCHAR上設置自己的最大值。假設你認爲你的帖子只需要最大2000，你可以設置VARCHAR(2000)。如果你每遇到極限，你可以在ALTER後面查表，並將它碰到VARCHAR(3000)。另一方面，TEXT實際上將其數據存儲在BLOB（1）中。我聽說VARCHAR和TEXT之間可能存在性能差異，但我還沒有看到任何證據，因此您可能需要進一步研究，但您可以隨時更改這些小細節。

更重要的是，使用全文索引而不是LIKE來搜索此「發佈」列會快得多（2）。但是，您必須使用MyISAM引擎才能使用全文索引，因爲InnoDB不支持它。在MySQL數據庫中，每個表可以有不同的引擎組合，因此您只需使「My Posts」表使用MyISAM即可。但是，如果您絕對需要使用InnoDB（針對交易）的「帖子」，請設置一個觸發器來更新「posts」表的MyISAM副本，並使用MyISAM副本來處理所有全文搜索。

查看底部的一些有用的引號。

（3）「在VARCHAR列中的值是可變長度字符串。可以將指定長度爲的值設置爲MySQL 5.0.3之前的0至 255,0.0.3及更高版本中的0至 65,535。

的MySQL 5.0.3之前，如果你需要數據類型，其尾部的空格不刪除，請考慮使用BLOB或TEXT 類型。

當存儲CHAR值時，它們是右側填充空格到指定的長度。當檢索到CHAR值爲時，尾隨空格是已刪除。

在MySQL 5.0.3之前，將尾部空格從存儲到VARCHAR列的值中刪除;這意味着空間也從檢索到的值缺席「

最後，這裏是關於VARCHAR的與TEXT利弊一個偉大的職位也說，以性能問題：。

VARCHAR(n) Considered Harmful

來源

2010-07-20 03:31:07 JohnB

這個帖子怎麼樣？ 1 for =「thelongpost」？，2 =「the2ndlongpost」:)。 – 2010-07-20 04:18:06

對不起Adam，我想我已經包含了另一個鏈接來回答你的問題。好吧，請看我的編輯存儲「帖子」。 – JohnB 2010-07-20 14:45:15

拍攝，我忘了提及比InnoDB不支持全文索引。你必須使用MyISAM。請重新閱讀我的部分。 – JohnB 2010-07-20 16:32:33

有多個角度接近你的問題。

從設計POV中，最好選擇表示要最佳建模的數量的數據類型。也就是說，正確地獲取數據域和數據大小，以便首先無法將非法數據存儲在數據庫中。但是這並不是MySQL首先強大的地方，尤其是沒有默認的sql_mode（http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html）。如果它適用於您，請嘗試使用TRADITIONAL sql_mode，這是許多期望標誌的簡寫。

從性能POV來看，問題是完全不同的。例如，關於電子郵件正文的存儲，您可能需要閱讀http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/然後考慮一下。

消除冗餘和縮短密鑰可能是一大勝利。例如，在我看到的項目中，日誌表一直存儲http User-Agent信息。通過簡單地將日誌表中的每個用戶代理字符串替換爲查找表中的用戶代理字符串的數字標識，數據集大小顯着降低（超過60％）。通過進一步解析用戶代理，然後存儲一堆ID（操作系統，瀏覽器類型，版本索引），數據集大小減少到原始大小的1％。

最後，有許多規則可以幫助您發現模式設計中的錯誤。

例如，名稱中有id並且不是無符號整數類型的任何東西都可能是一個錯誤（特別是在innodb環境中）。例如，任何名稱中含有價格或成本且未簽名的東西都是潛在的欺詐來源（欺詐者用負價創建文章併購買該文章）。

例如，任何對貨幣數據有效並且沒有使用適當大小的DECIMAL數據類型的人可能會犯數學錯誤（DECIMAL正在做BCD，具有正確精度和舍入的小數紙張數學運算，DOUBLE和FLOAT不會）。

來源

2010-07-20 13:39:29 Isotopp

SQLyog的具有計算最優化的數據類型功能，這有助於基於插入表中的記錄找出最佳的數據類型。它使用

SELECT * FROM table_name` PROCEDURE ANALYSE（1，10）;

查詢，找出最佳的數據類型爲固定

來源

2013-11-29 12:29:25

如何選擇列[innodb特定]的優化數據類型？

回答

相關問題