高性能MySQL-筆記2-數據類型和奇怪的東西
數據類型優化
- 數據範圍內最小類型
- 數據不進行二次操作（使用簡單的類型）
- 避免索引NULL值（innodb中稀疏數據無所謂）
各種的數據類型
整數
類型：TINYINT ，SMALLINT ，MEDIUMINT ，INT，BIGINT 【數據範圍增大】
對於BIGINT UNSIGNED 無符號整型，常用來作爲id值；BUG在於：
- 一些處理，對長度超出bigint的數字直接截取了，又不報錯
- 語言（Java）沒有無符號整數的類型，使用Long，超出最大值會報錯，回顯出現截取情況。
【在“MySQL-UUID_SHORT使用問題”的筆記中有這個原因引起的問題處理詳情】
實數
類型：FLOAT，DOUBLE，DECIMAL【常用於貨幣金額】
對於精度問題：使用BIGINT存儲百萬倍的數據，達到需要的進度計算。（大數據情況下DECIMAL開銷顯得大）
存在的問題：
當使用超大字符串數值作爲條件查詢時，mysql會將他們認爲一樣大，這個時候需要加索引纔可以避免錯誤，該bug在5.5、5.6，5.7.2都存在目前沒有修復.
-- 栗子： select case when '100000000000000000000002' = convert(100000000000000000000003,DECIMAL(25,0)) then 1 else 0 end -- true select case when '100000002' = convert(100000003,DECIMAL(25,0)) then 1 else 0 end -- false正常情況下decimal是不能直接作爲分區key的[5.6版本]
字符串
類型：char 和 varchar ，BLOB 和 TEXT ，枚舉(不用就好) ，
存在的問題：
- char 和 varchar ：對於
' tset '的存儲是不一樣的，char默認會刪除末尾空格。╮(╯_╰)╭- BLOB和TEXT只能部分數據排序，且不能全長度進行索引。
時間日期
類型：DATETIME 和 TIMESTAMP 。【精度秒】
區別：
DATETIME 保存與時區無關的時間整數值，ANSI標準定義的時間格式。範圍-9999年；
TIMESTAMP 1970-2038年，保存的是秒數以及。在多時區的情況下，日期值會與時區有關。
雖然推薦使用的是TIMESTAMP，顆粒小較小。不過爲了避免時區的問題，我還是不想用。╮(╯_╰)╭
標示符
數據中的標示符的選用，比較影響性能，因爲常作爲關聯對比索引來使用。
可以是用TINYINT(整形) 作爲標示符，避免使用字符串。同時，系統內儘量統一標示符類型，避免處理中的隱式轉換。
ipv4 可以使用無符號整數進行存儲，提供INE_ATON() 與INET_NTOA() 方法進行數據轉換。
一些奇怪的建議
- 列設計不要太多，書是說上千的列不好，這誰都知道的啊。【我覺的按頁16KB計算，定義的時候一行1~2KB最多了】
- 關聯太多，影響mysql解析優化查詢的代價。最好在12個表以內。(⊙_⊙)?
- 不使用枚舉類型。【這個壓根就不知道是啥。】
- 對於NULL的字段，作爲索引列或者關聯列儘量避免爲NULL。【NULL值對比操作起來很奇怪】
一個奇怪的騷操作
高效加載大量數據
加載大量數據到有非唯一索引的表中，由於索引的使用，導致在插入大量數據的時候變得緩慢，尤其是索引還有好幾個的時候。
這裏的處理方法是，先禁用索引，然後加載數據，再重啓索引。【由於大量數據完成插入之後進行索引，可以通過排序來構建索引，減少了索引的碎片】
ALTER TABLE test.tableName DISABLE KEYS;
-- load all data
ALTER TABLE test.tableName ENABLE KEYS;
還有一個做法是，直接刪除所有非唯一索引，然後在完成數據導出之後重建索引。
感覺用得到的新的語法
-
INSERT INTO … ON DUPLICATE KEY UPDATE : 當insert已經存在的記錄時，執行Update【主鍵重複的時候】
-
with rollup 的用法：用來在分組統計數據的基礎上再進行統計彙總，即用來得到group by的彙總信息；
select merchant_name,count(id) from merchant_trade group by merchant_name with rollup
-- 最後一個爲（null） 值 的就是彙總信息