MySQL字段空間分配

首先，我在我的應用程序上創建一個模型，然後Entity Framework生成用於創建表的SQL。第一個生成類型爲varchar(20)的列，第二個生成longtext。MySQL字段空間分配

例

[StringLength(20)] 
public string Code { get; set; } 

public string CodeTwo { get; set; }

問題

有以下兩個聲明（空間分配）之間有什麼區別？（即使它們存儲了與「test」相同的值，其中包含5個字符）。

如果我知道字段之間有長度差異，例如10-15個字符，那麼限制最大長度還是讓它「無限」（空間分配）？

在此先感謝。對不起，我可憐的英語。

來源

2016-08-01 LP. Gonçalves

用戶翻譯的答案@Marconcílio Souza，用另一種語言問同樣的問題。

當實體框架生成數據庫檢查它的類型每個字段的，在字符串類型的情況下，當你指定它同樣規格銀行規模與其相應類型的表。

在其

[StringLength (20)] 
public string Code {get; set; }

的情況下相應的MySQL是VARCHAR（20），但是當相同的字符串類型和不具有固定尺寸的聲明實體框架分配儘可能對於這種類型的數據庫中的在MySQL和longtext的情況下。

類型BLOB作爲LONGTEXT的列是本質上是可變的長度和不使用時佔用幾乎沒有存儲。他們需要的空間不會受到影響，即使在使用的情況下一個NULL值，如「文字」測試「設置」分配和傳遞的字符串的大小。

*的BLOB的優勢/劣勢與VARCHAR處理*

在這一段提及VARCHAR類型所有評論有效期爲CHAR類型了。每個註釋以BLOB +或VARCHAR +標記結束，以指示哪種數據更好。

- 你知道你的數據的最大長度？

使用VARCHAR您需要聲明鏈的最大長度。斑點你不必擔心它。 BLOB +

您需要存儲很長的字符串？

單個VARCHAR被限制爲32K字節（即大約10,000個Unicode字符）。最大尺寸爲blob（根據服務指南）;

- 頁面大小1KB => 64 MB - 頁面大小2KB => 512 MB - 4 KB的頁面大小=>的4Gb - 8KB的頁面大小=>的32Gb

BLOB +

您需要將多個長文本列存儲在單個表中嗎？

總行長度（未壓縮）限制爲64K。 VARCHAR直接在線存儲，因此不能在一行中存儲很多長字符串。 Blob由它們的blob-id表示，並且僅使用最大64K的8個字節。 BLOB +

你希望儘量減少客戶端和服務器之間的呼叫？

在搜索操作中VARCHAR數據與其他行數據一起被提取，並且通常在網絡上同時發送多行。每個blob都需要額外的搜索操作open/fetch。 VARCHAR +

你希望儘量減少客戶端和服務器之間傳輸的數據量？

blob的優點是獲得的行只有blob-id，因此您可以決定是否搜索BLOB數據。在早期版本的InterBase中，存在VARCHAR通過網絡以聲明全長髮送的問題。 Firebird 1.5和InterBase 6.5中已修復此問題。平局

你希望儘量減少佔用的空間（舊版本服務器的BLOB +）？

VARCHAR是壓縮的RLE（實際上整行是壓縮的，除了blob）。最多128個字節可以壓縮到2個字節。這意味着即使是空的varchar（32000）也會佔用500 + 2個字節。

Blob未壓縮，但空（即null）blob將僅佔用8個字節的blob-id（並且將在以後進行RLE壓縮）。非空blob可能與行中的其他數據（如果適用）或單獨頁面中存儲在同一頁面上。適合數據頁面的小塊有40字節（或更多）的開銷。大數據塊在數據頁面中具有相同的40字節開銷，並且在每個塊頁面（第一個30字節）上加上28字節開銷。 blob頁面不能包含多個blob（即，blob頁面不能作爲數據頁面共享）。例如。對於4K頁面大小，如果您存儲5K blob，則將分配兩頁blob類型，這意味着您將失去3K的空間！換句話說 - 較大的頁面大小，小數據塊適合數據頁面的可能性較高，但如果大數據塊需要單獨的blob頁面，則會浪費更多空間。 VARCHAR +（除VARCHAR處理有非常大的聲明的長度，或表有很多空的斑點）

你需要表非常大量的行？

每行由DB_KEY標識，它是一個64位值，32位，32位，並且它是用於定位行的平衡ID。表格中理論行數的最大值爲2^32（但由於各種原因，最大真實值甚至更低）。 Blob -IDS是從與DB_KEYs相同的地址空間分配的，這意味着表中的blob越多，DB_KEYs就越少，以面對隊列。另一方面，當存儲的行很寬時（例如它們包含較長的VARCHAR），那麼適合數據頁的行較少，並且許多DB_KEY值仍然未分配。 varchar +？

你想要一個好的表現呢？

由於大數據塊存儲在數據頁面之外，它們增加了數據頁行效率的「密度」，從而緩存（減少搜索期間的I/O操作次數）。 BLOB +

您需要執行文本列的內容搜索？

在VARCHAR中，您可以使用運算符（如'='，'>'），其中包括（），區分大小寫和區分大小寫不敏感的CONTAINING。在大多數情況下，索引可以用來加速搜索。 Blob無法編入索引，並且您僅限於TASTE，啓動幷包含運算符。您不能直接比較blob與運算符'='，'>'等（除非您使用UDF），因此您不能在Blob字段中連接表。 VARCHAR +

您要搜索這些文本的內容與含？

Containig可用於執行不區分大小寫的搜索內容VARCHAR字段。（無索引使用）由於無法爲BLOB列設置排序順序，因此無法在BLOB列中使用具有全國字符的完全不敏感的搜索大小寫（只有字符集的下半部分不區分大小寫）。（或者，您可以使用UDF）。 Firebird 2已經允許你設置文字環繞（和二進制）列。 VARCHAR +

您需要的文本列的資本內容是什麼？

您可以在varchar上使用內置的UPPER（）函數，但不能使用blob。（參見CAST，MIN，MAX不能與斑點使用） VARCHAR +

您不能排序BLOB列。（E GROUP BY，DISTINCT，UNION，JOIN ON）無法連接blob列。 VARCHAR +

有用於將團塊到VARCHAR或VARCHAR成團塊沒有內置的轉換功能（CAST）。（但您可以爲此編寫UDF。）由於Firebird 1.5可以使用內置SUBSTRING函數將blob轉換爲VARCHAR（但FROM子句不能超過32K）。繪製

您不能分配值直接在SQL命令，例如成團塊。輸入值指南（MyBlob）（'abc'）; （但您可以使用UDF將字符串轉換爲Blob）。 VARCHAR +

火鳥 - 0.9.4已經有這個功能繪製

您需要對這些文本列了良好的安全性？

要恢復表數據，您必須被授予SELECT權限。要檢索blob，您只需要知道blob -id（存儲在表中），但Firebird/InterBase不會檢查您是否擁有任何Blob表權限。這意味着每個知道或猜出正確blob-id的人都可以讀取blob，而無需任何表格權限。（你可以用ISQL和BLOBDUMP命令試試吧。） VARCHAR +

更多細節

2016-08-08 17:12:47

MySQL字段空間分配

回答

相關問題