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

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

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

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

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

char：定長(zhǎng)字符型，最大可存儲(chǔ) 255 （2 的 8 次方）個(gè)字節(jié)長(zhǎng)度，可以理解成最大可以存儲(chǔ) 255 個(gè)字符。在計(jì)算機(jī)中以 8 位二進(jìn)制的方式存儲(chǔ)。

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

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

varchar：不定長(zhǎng)字符型，最大可存儲(chǔ) 65535（2 的 16 次方） 個(gè)字節(jié)長(zhǎng)度，在計(jì)算機(jī)中以 16位 二進(jìn)制的方式存儲(chǔ)。

它與char不同的地方在于，當(dāng)字符長(zhǎng)度在 0-255 以內(nèi)時(shí)，會(huì)在后面添加一個(gè)字節(jié)，超過 255 時(shí)，添加兩個(gè)字節(jié)。同樣的，當(dāng)超過最大存儲(chǔ)長(zhǎng)度后，也會(huì)丟失一部分?jǐn)?shù)據(jù)。

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

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

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

100 只是在呈現(xiàn)角度上定義的，比如該數(shù)據(jù)有 120 個(gè)字符，那么你在查詢?cè)摂?shù)據(jù)時(shí)，看到的只有 100 個(gè)。但是如果在定義時(shí)，添加了UNSIGNED ZEROFILL屬性，那么這將改變?cè)擃愋偷淖畲蟠鎯?chǔ)長(zhǎng)度。

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

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

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

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

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

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

第二范式：表必須含有一個(gè)唯一主鍵來標(biāo)識(shí)這張表。

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

Scale Out（垂直切分）

Scale Up（橫向拆分）

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

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

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

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

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

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

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

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

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

盡量不要使用text這種類型，這會(huì)使得數(shù)據(jù)查詢?cè)撟侄螘r(shí)，創(chuàng)建臨時(shí)表。

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

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

盡量使用 EXISTS和BETWEEN代替IN。

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

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

盡量使用INNER JOIN而不是LEFT JOIN，因?yàn)榍罢吣J(rèn)使用小表驅(qū)動(dòng)大表。

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

避免使用模糊查詢LIKE。

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

InnoDB 支持外鍵，MyISAM 不支持。

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

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

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

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

MyISAM 計(jì)算 COUNT(*)時(shí)，速度遠(yuǎn)高于 InnoDB。

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

原子性

可靠性

穩(wěn)定性

隔離性

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

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

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

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

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

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

未更完，下次更新補(bǔ)上。