由于Varchar字段的存儲要求基于輸入的字符串的實際長度，因此將每個Varchar字段指定為最大可能值的缺點是什么：Varchar(65535)？ 好吧，除了1個額外的字節以外，最大字段數> 255個字符？

[長度為L的字符串的存儲要求：如果列值需要0 – 255字節，則L + 1字節；如果值可能需要255個以上字節，則L + 2字節]

謝謝！

如果不是相同的問題，請聯系：stackoverflow.com/questions/262238/

感謝大家的意見！ 我是stackoverflow的新手，并真誠地感謝每個人的響應能力。 :-)

從文檔-表的列數和行大小限制：

Every table (regardless of storage engine) has a maximum row size of 65,535 bytes. Storage engines may place additional constraints on this limit, reducing the effective maximum row size.

The maximum row size constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size. For example, utf8 characters require up to three bytes per character, so for a CHAR(255) CHARACTER SET utf8 column, the server must allocate 255 × 3 = 765 bytes per value. Consequently, a table cannot contain more than 65,535 / 765 = 85 such columns.

Storage for variable-length columns includes length bytes, which are assessed against the row size. For example, a VARCHAR(255) CHARACTER SET utf8 column takes two bytes to store the length of the value, so each value can take up to 767 bytes.

因此，定義單個VARCHAR(65535)列可以有效地將您限制為該行中的單個列(假設您已將其填滿)。

所有這些，除了對于某些類型的數據來說都是如此大的事實是完全錯誤的-如果您的電話號碼列可能包含本地和國際號碼，則可以選擇使用VARCHAR字段來執行此操作，但是將其設置為20以上可能毫無意義(我很慷慨)。

請參見Bill Karwin的答案，該答案還指出如果使用不必要的長VARCHAR字段生成臨時表可能會導致性能下降(與將此類字段轉換為CHAR并再次轉換-有關詳細信息，請參見該帖子)。

但是，除了VARCHAR(65535)列(稱為data1)之外，我的表確實還有其他列。 所有這些列都使用輸入的數據進行填充，因為沒有data1列實際上包含接近最大大小的字符串。

@tgoneil-嘗試在該列中插入65535個字符，并在其他列中插入數據。

我同意您的警告(假設您已填寫)，并理解這一點。 就我而言，可能永遠不會在該字段中插入大小為65535的實際字符串，因此從一開始就絕不是問題。 似乎限制VARCHAR大小的唯一真實原因是，如果嘗試超過預期的最大大小，則強制執行錯誤。

@tgoneil-這本身就是一個很好的理由。

請注意，TEXT和BLOB類型的列不計入此MySQL行大小限制(我以前曾以為VARCHAR也是如此，但我錯了)

我認為VARCHAR列長度不僅與存儲有關。它們也與數據語義有關。

即將name列指定為varchar(100)表示存儲在系統中的名稱不得超過100個字符。

在存儲方面，它們應該是相同的。雖然，行大小估計在VARCHAR列上具有特定長度的情況下會更準確，而在沒有行長度估計的情況下(不需要統計收集系統將數據分布保持在VARCHAR大小上)。

一種可能的原因是改善與其他應用程序的兼容性。例如，如果您有一個使用" product_no"字段長度為100個字符的應用程序，而您想與一個使用類似" model_no"字段類似長度為40個字符的應用程序進行交互，那將很痛苦。應用程序中任何超過40個字符的product_nos都將被截斷，您必須找出某種方法在應用程序之間進行轉換。

例如，MySQL中的MEMORY引擎不能很好地支持VARCHAR-Fields。引擎將為每一行保留最大字節數，而不是實際使用的長度。因此，如果您定義一個具有單個VARCHAR(1000)列的表，則添加的每一行的內存使用量將為1000 * 3字節，即使它們是空字符串也是如此。

原因之一是該字段的大小是對輸入數據的檢查。您是否真的要有人輸入1000個字符的電話號碼？字段太大是確保垃圾將輸入到數據庫中的一種方法。您的電話號碼上會顯示類似的內容(例如，不是隨機產生的)：

"只和前臺的大金發女郎說話"

而不是真實的電話號碼或電子郵件字段，其中包含有關客戶的注釋，因為他們沒有注釋字段？當您嘗試向其發送電子郵件時，效果并不理想。

寬表可能會在數據庫中產生所有問題，因為您可能會遇到意外的記錄限制(您可以將表設計為比實際存儲在一個記錄中更寬的表，有時這會導致插入意外失敗)和作為數據的性能問題跨數據頁分隔。我知道您可以從SQL Server的寬表中獲得該信息，如果mysql遇到類似問題，我也不會感到驚訝。 mysql專家將不得不真正解決這個問題。索引也可能是廣泛領域的問題。數據庫引擎可能不太傾向于認為索引是有用的。同樣，我不確定mysql是否會出現此問題，但這值得研究。我知道這些是在SQL Server中使用所有字段的最大字段大小的問題，mysql可能有這些問題或其他SQL Server沒有的問題。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的mysql为什么没有nvarchar,关于mysql：为什么不将每个VARCHAR指定为VARCHAR(65535)？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。