摘要：也就是說當使用字符型存儲數(shù)據(jù)后，該數(shù)據(jù)轉(zhuǎn)換為二進制時的長度超過了位，那么該數(shù)據(jù)將不會完整存儲，會丟失一部分數(shù)據(jù)。

閱讀本文大約需要 8 分鐘。

數(shù)據(jù)庫打算只寫 MySQL，Redis 兩部分，不會很細，主要以面試題為主。這次寫的是 MySQL 篇。

這里先介紹一下數(shù)據(jù)庫的概念，數(shù)據(jù)庫是一種數(shù)據(jù)結(jié)構(gòu)，內(nèi)含多種算法，幫助我們將數(shù)據(jù)以最優(yōu)化的方式存儲在計算機中，也可以幫助我們快速找到存儲的數(shù)據(jù)。

數(shù)據(jù)最終存儲在計算機中都是以「二進制」的方式存儲。比如 4，存儲在計算機中其實是以 0100 的方式存儲。比如 A，存儲在計算中是以 0100 0001 的方式存儲。

char：定長字符型，最大可存儲 255 （2 的 8 次方）個字節(jié)長度，可以理解成最大可以存儲 255 個字符。在計算機中以 8 位二進制的方式存儲。

使用char類型存儲數(shù)據(jù)時，假設(shè)存儲的數(shù)據(jù)是 4，4 在計算機中存儲的結(jié)果是 0000 0100，意味著使用定長字符型char，不管你存儲的值是多少位，最終在計算機里都是以 8 位二進制的方式存儲，不滿 8 位，前面補 0。超過 8 位，超出的部分會被去除。

也就是說當使用char字符型存儲數(shù)據(jù)后，該數(shù)據(jù)轉(zhuǎn)換為二進制時的長度超過了 8 位，那么該數(shù)據(jù)將不會完整存儲，會「丟失」一部分數(shù)據(jù)。

varchar：不定長字符型，最大可存儲 65535（2 的 16 次方） 個字節(jié)長度，在計算機中以 16位 二進制的方式存儲。

它與char不同的地方在于，當字符長度在 0-255 以內(nèi)時，會在后面添加一個字節(jié)，超過 255 時，添加兩個字節(jié)。同樣的，當超過最大存儲長度后，也會丟失一部分數(shù)據(jù)。

text：長文本數(shù)據(jù)類型，最大可存儲 65555 個字節(jié)長度，不能指定長度，也就是說不支持text(num)。

但是該類型盡量不要使用，因為text類型數(shù)據(jù)在檢索中，不會使用索引，而是使用全局搜索，這會產(chǎn)生臨時表，使得檢索時間變長，不推薦使用。

由于char和varchar的特性，在實際使用當中，如果該數(shù)據(jù)是經(jīng)常會發(fā)生變化、經(jīng)常使用的，那么推薦使用char類型，因為 MySQL 在對數(shù)據(jù)進行排序時，會根據(jù)該數(shù)據(jù)的長度來排，固定長度的char類型會提供更高的性能。但是由于固定長度的特性，在存儲短數(shù)據(jù)時，一定程度上也會造成資源浪費，算是一個雙刃劍。

100 只是在呈現(xiàn)角度上定義的，比如該數(shù)據(jù)有 120 個字符，那么你在查詢該數(shù)據(jù)時，看到的只有 100 個。但是如果在定義時，添加了UNSIGNED ZEROFILL屬性，那么這將改變該類型的最大存儲長度。

同樣的，在實際使用當中，varchar(num)里的值不需要定義的特別長，只要夠用就行，具體原因上面有提，這里不再贅述。

DORP：非事務(wù)操作，徹底刪除一張表，無法反悔恢復(fù)。

DELETE：事務(wù)操作，刪除表里的一行或多行數(shù)據(jù)，如果反悔或是誤刪，可以通過「事務(wù)回滾」恢復(fù)該表。不會影響該表下的view或索引。

TRUNCATE：非事務(wù)操作，刪除表里的某行數(shù)據(jù)，或是刪除整張表的數(shù)據(jù)（表依然存在，只是成了一張空表）。無法反悔恢復(fù)，并且會將該表下的view或索引重置。

執(zhí)行速度：DROP > TRUNCATE > DELETE。

第一范式：表中的字段只能表達一種意思，不能模棱兩可。

第二范式：表必須含有一個唯一主鍵來標識這張表。

第三范式：表中的字段不能互相依賴。

Scale Out（垂直切分）

Scale Up（橫向拆分）

這里有篇文章值得看一看。MySQL 分區(qū)、分表

如果把數(shù)據(jù)庫當做一本書的話， 那么索引就是書的「目錄頁」，通過目錄，我們可以快速定位查找內(nèi)容，同樣的，目錄頁在書中也占了一頁紙，所以索引是一個數(shù)據(jù)結(jié)構(gòu)，也要占據(jù)數(shù)據(jù)庫物理內(nèi)存。

索引分為 4 種類型：普通索引、唯一索引、主鍵索引和全文索引（MyISAM 專有）。

索引的創(chuàng)建規(guī)則：經(jīng)常使用的字段名，和出現(xiàn)在 where 后面的字段名，建議為它們創(chuàng)建索引，索引要遵循最左前綴原則（最能體現(xiàn)該索引特征，也就是常用的字段放最左邊）。

索引的原理：可以看看這篇文章。索引

索引的使用場景：中等、大量數(shù)據(jù)時，使用索引效率會非常高，小型數(shù)據(jù)不建議使用索引，沒有全局搜索來的快。

索引的作用：索引可以提高查詢速度。但是索引會增加數(shù)據(jù)庫存儲額外開銷。索引會將數(shù)據(jù)庫查詢時的隨機 I/O 變成順序 I/O，減少服務(wù)器排序操作，和臨時表的開銷。

使用EXPLAIN查看 SQL 執(zhí)行計劃，幫助自己查看哪些地方可以優(yōu)化。

杜絕使用 SELECT * FROM xxx 這種查詢語句，需要什么就查什么。

盡量不要使用text這種類型，這會使得數(shù)據(jù)查詢該字段時，創(chuàng)建臨時表。

明確知道查詢數(shù)據(jù)結(jié)果大概有幾行時，使用LIMIT，為查詢結(jié)果限制顯示頁數(shù)。

避免使用 MySQL 的內(nèi)置函數(shù)。

盡量使用 EXISTS和BETWEEN代替IN。

避免在 WHERE中使用表達式操作，這會使得 MySQL 放棄使用索引查詢。

盡量使用小表驅(qū)動大表（從小的表中，查找跟大表中有關(guān)系的數(shù)據(jù)），可以減少 CPU 運算次數(shù)，以及 I/O 總量。

盡量使用INNER JOIN而不是LEFT JOIN，因為前者默認使用小表驅(qū)動大表。

索引要遵循最左前綴法則。

避免使用模糊查詢LIKE。

避免設(shè)置字段NULL屬性，在對NULL進行判斷時，會使得 MySQL 放棄使用索引。

InnoDB 支持外鍵，MyISAM 不支持。

MyISAM 擁有全文索引，InnoDB 沒有。

數(shù)據(jù)庫崩潰后，InnoDB 可以安全恢復(fù)，而 MyISAM 不可以。

InnoDB 擁有事務(wù)，而 MyISAM 沒有。

InnoDB 擁有行鎖，而 MyISAM 擁有表鎖。

MyISAM 計算 COUNT(*)時，速度遠高于 InnoDB。

InnoDB 引擎下，MySQL 支持事務(wù)操作，事務(wù)擁有以下幾個特點：

原子性

可靠性

穩(wěn)定性

隔離性

使用事務(wù)的操作，要么執(zhí)行，要么不執(zhí)行，只有一個結(jié)果，但是事務(wù)可以回滾，也就是撤回操作。

InnoDB 引擎下的 MySQL 在處理高并發(fā)時，會對 MySQL 數(shù)據(jù)庫添加鎖機制，以此完成并發(fā)的要求，并保證數(shù)據(jù)的完整性，可靠性。

悲觀鎖是 MySQL 為數(shù)據(jù)庫添加行鎖，強行為多個事務(wù)排序，阻塞事務(wù)運行，解決事務(wù)之間的沖突問題，但是事務(wù)之間有可能出現(xiàn)長時間等待，且開鎖、解鎖需要額外的數(shù)據(jù)庫資源消耗。所以要謹慎使用。

樂觀鎖沒有鎖機制，但是引入了版本號控制，在高并發(fā)時，數(shù)據(jù)庫在事務(wù)提交之前會進行版本號校驗，如果版本后前后不一致，說明此刻有其他事務(wù)正在操作，那么本次事務(wù)重新操作。

版本號的好處在于沒有鎖的開銷，并且只在事務(wù)最后提交更改時進行判斷，但是也要考慮重新執(zhí)行的代價是否過大。

總的來說，高并發(fā)下，讀操作多的時候，使用樂觀鎖，寫的操作時，使用悲觀鎖。

未更完，下次更新補上。