字符串類型（）
與CHAR 和VARCHAR 類似的類型還有BINARY 和VARBINARY它們存儲的是二進制字符串二進制字符串跟常規字符串非常相似但是二進制字符串存儲的是字節碼而不是字符填充也不一樣MySQL 填充BINARY 采用的是\（零字節）而不是空格在檢索時也不會去掉填充值
當需要存儲二進制數據並且希望MySQL 使用字節碼而不是字符進行比較時這些類型是非常有用的二進制比較的優勢並不僅僅體現在大小寫敏感上MySQL 比較BINARY 字符串時每次按一個字節並且根據該字節的數值進行比較因此二進制比較比字符比較簡單很多所以也就更快
慷慨是不明智的
使用VARCHAR（） 和VARCHAR（） 存儲hello的空間開銷是一樣的那麼使用更短的列有什麼優勢嗎？
事實證明有很大的優勢更大的列會消耗更多的內存因為MySQL 通常會分配固定大小的內存塊來保存內部值尤其是使用內存臨時表進行排序或操作時會特別糟糕在利用磁盤臨時表進行排序時也同樣糟糕
所以最好的策略是只分配真正需要的空間
BLOB 和TEXT 類型
BLOB 和TEXT 都是為存儲很大的數據而設計的字符串數據類型分別采用二進制和字符方式存儲
實際上它們分別屬於兩組不同的數據類型家族字符類型是TINYTEXTSMALLTEXTTEXTMEDIUMTEXTLONGTEXT ;對應的二進制類型是TINYBLOBSMALLBLOBBLOBMEDIUMBLOBLONGBLOBBLOB 是SMALLBLOB 的同義詞TEXT 是SMALLTEXT 的同義詞
與其他類型不同MySQL 把每個BLOB 和TEXT 值當作一個獨立的對象處理存儲引擎在存儲時通常會做特殊處理當BLOB 和TEXT 值太大時InnoDB 會使用專門的外部
存儲區域來進行存儲此時每個值在行內需要 ~ 個字節存儲一個指針然後在外部存儲區域存儲實際的值
BLOB 和TEXT 家族之間僅有的不同是BLOB 類型存儲的是二進制數據沒有排序規則或字符集而TEXT 類型有字符集和排序規則
MySQL 對BLOB 和TEXT 列進行排序與其他類型是不同的它只對每個列的最前max_sort_length 字節而不是整個字符串做排序如果只需要排序前面一小部分字符則可以減小max_sort_length 的配置或者使用ORDER BY SUSTRING（column length）
MySQL 不能將BLOB 和TEXT 列全部長度的字符串進行索引也不能使用這些索引消除排序（關於這個主題下一章會有更多的信息）
磁盤臨時表和文件排序
因為Memory 引擎不支持BLOB 和TEXT 類型所以如果查詢使用了BLOB 或TEXT列並且需要使用隱式臨時表將不得不使用MyISAM 磁盤臨時表即使只有幾行數據也是如此（Percona Server 的Memory 引擎支持BLOB 和TEXT 類型但直到本書寫作之際同樣的場景下還是需要使用磁盤臨時表）
這會導致嚴重的性能開銷即使配置MySQL 將臨時表存儲在內存塊設備上（RAMDisk）依然需要許多昂貴的系統調用
最好的解決方案是盡量避免使用BLOB 和TEXT 類型如果實在無法避免有一個技巧是在所有用到BLOB 字段的地方都使用SUBSTRING（column length） 將列值轉換為字符串（在ORDER BY 子句中也適用）這樣就可以使用內存臨時表了但是要確保截取的子字符串足夠短不會使臨時表的大小超過max_heap_table_size 或tmp_table_size超過以後MySQL 會將內存臨時表轉換為MyISAM 磁盤臨時表
最壞情況下的長度分配對於排序的時候也是一樣的所以這一招對於內存中創建大臨時表和文件排序以及在磁盤上創建大臨時表和文件排序這兩種情況都很有幫助例如假設有一個 萬行的表占用幾個GB 的磁盤空間其中有一個utf字符集的VARCHAR（） 列每個字符最多使用 個字節最壞情況下需要 字節的空間如果在ORDER BY 中用到這個列並且查詢掃描整個表為了排序就需要超過GB 的臨時表
這三行數據實際存儲為整數而不是字符串可以通過在數字上下文環境檢索看到這個雙重屬性
返回目錄高性能MySQL
編輯推薦
ASPNET MVC 框架揭秘
Oracle索引技術
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
From:http://tw.wingwit.com/Article/program/MySQL/201311/29686.html
