數據庫八股文背誦版v0.2
大家好，我是小富～，我和BAT的小伙伴收集了市面上的大廠面試題，并配上了相關答案，放到了我的公眾號上。大家可以關注下方公眾號，回復關鍵詞：interviewtop 獲取題庫pdf版。
同時，我們根據題庫，也開發(fā)了互聯(lián)網題庫在線網站：也有不少熱心的網友貢獻了面試經歷。題庫還處于更新中，歡迎大家訪問。http://interviewtop.top。同時，我的公眾號也會發(fā)一點廣告，負擔一下服務器成本，希望大家諒解。
目前題庫覆蓋公司有：各類銀行科技崗，百度，阿里，字節(jié)，騰訊，美團，快手，網易，華為，shopee，京東。
題庫包括：計算網絡，操作系統(tǒng)，數據庫，Redis，Java基礎，Java多線程，Java虛擬機，設計模式，數據結構與算法。
大家可以進入網站搜索大廠對應題庫的高頻面試題。
簡述數據庫三大范式
第一范式是最基本的范式。如果數據庫表中的所有字段值都是不可分解的原子值，就說明該數據庫表滿足了第一范式。
數據庫第二范式：關系模式必須滿足第一范式，并且所有非主屬性都完全依賴于主碼。注意，符合第二范式的關系模型可能還存在數據冗余、更新異常等問題。關系模型（學號，姓名，專業(yè)編號，專業(yè)名稱）中，學號->姓名，而專業(yè)編號->專業(yè)名稱，不滿足數據庫第二范式
數據庫第三范式：關系模型滿足第二范式，所有非主屬性對任何候選關鍵字都不存在傳遞依賴。即每個屬性都跟主鍵有直接關系而不是間接關系。接著以學生表舉例，對于關系模型（學號，姓名，年齡，性別，所在院校，院校地址，院校電話）院校地址，院校電話和學號不存在直接關系，因此不滿足第三范式。
簡述MySQL的架構
MySQL可以分為應用層,邏輯層,數據庫引擎層,物理層。
應用層：負責和客戶端，響應客戶端請求，建立連接，返回數據。
邏輯層：包括SQK接口，解析器，優(yōu)化器，Cache與buffer。
數據庫引擎層：有常見的MyISAM,InnoDB等等。
物理層：負責文件存儲，日志等等。
簡述執(zhí)行SQL語言的過程
客戶端首先通過連接器進行身份認證和權限相關 如果是執(zhí)行查詢語句的時候，會先查詢緩存，但MySQL 8.0 版本后該步驟移除。 沒有命中緩存的話，SQL 語句就會經過解析器，分析語句，包括語法檢查等等。 通過優(yōu)化器，將用戶的SQL語句按照 MySQL 認為最優(yōu)的方案去執(zhí)行。 執(zhí)行語句，并從存儲引擎返回數據。
簡述MySQL的共享鎖排它鎖
共享鎖也稱為讀鎖，相互不阻塞，多個客戶在同一時刻可以同時讀取同一個資源而不相互干擾。排他鎖也稱為寫鎖，會阻塞其他的寫鎖和讀鎖，確保在給定時間內只有一個用戶能執(zhí)行寫入并防止其他用戶讀取正在寫入的同一資源。
簡述MySQL中的按粒度的鎖分類
表級鎖: 對當前操作的整張表加鎖,實現(xiàn)簡單，加鎖快，但并發(fā)能力低。
行鎖: 鎖住某一行，如果表存在索引，那么記錄鎖是鎖在索引上的，如果表沒有索引，那么 InnoDB 會創(chuàng)建一個隱藏的聚簇索引加鎖。行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小，并發(fā)度高，但加鎖的開銷也最大，加鎖慢，會出現(xiàn)死鎖。
Gap 鎖：也稱為間隙鎖: 鎖定一個范圍但不包括記錄本身。其目的是為了防止同一事物的兩次當前讀出現(xiàn)幻讀的情況。
Next-key Lock：行鎖+gap鎖。
如何解決數據庫死鎖
預先檢測到死鎖的循環(huán)依賴，并立即返回一個錯誤。 當查詢的時間達到鎖等待超時的設定后放棄鎖請求。
簡述樂觀鎖和悲觀鎖
樂觀鎖：對于數據沖突保持一種樂觀態(tài)度，操作數據時不會對操作的數據進行加鎖，只有到數據提交的時候才通過一種機制來驗證數據是否存在沖突。
悲觀鎖：對于數據沖突保持一種悲觀態(tài)度，在修改數據之前把數據鎖住，然后再對數據進行讀寫，在它釋放鎖之前任何人都不能對其數據進行操作，直到前面一個人把鎖釋放后下一個人數據加鎖才可對數據進行加鎖，然后才可以對數據進行操作，一般數據庫本身鎖的機制都是基于悲觀鎖的機制實現(xiàn)的。
簡述InnoDB存儲引擎
InnoDB 是 MySQL 的默認事務型引擎，支持事務，表是基于聚簇索引建立的。支持表級鎖和行級鎖，支持外鍵，適合數據增刪改查都頻繁的情況。
InnoDB 采用 MVCC 來支持高并發(fā)，并且實現(xiàn)了四個標準的隔離級別。其默認級別是 REPEATABLE READ，并通過間隙鎖策略防止幻讀，間隙鎖使 InnoDB 不僅僅鎖定查詢涉及的行，還會對索引中的間隙進行鎖定防止幻行的插入。
簡述MyISAM存儲引擎
MySQL5.1及之前，MyISAM 是默認存儲引擎。MyISAM不支持事務，Myisam支持表級鎖，不支持行級鎖，表不支持外鍵，該存儲引擎存有表的行數，count運算會更快。適合查詢頻繁，不適合對于增刪改要求高的情況
簡述Memory存儲引擎
Memory存儲引擎將所有數據都保存在內存，不需要磁盤 IO。支持哈希索引，因此查找速度極快。Memory 表使用表級鎖，因此并發(fā)寫入的性能較低。
索引是什么？
索引是存儲引擎中用于快速找到記錄的一種數據結構。在關系型數據庫中，索引具體是一種對數據庫中一列或多列的值進行排序的存儲結構。
為什么引入索引？
為了提高數據查詢的效率。索引對數據庫查詢良好的性能非常關鍵，當表中數據量越來越大，索引對性能的影響越重要。
Mysql有哪些常見索引類型？
數據結構角度
“
B-Tree索引 哈希索引 R-Tree索引 全文索引
”物理存儲角度
“
主鍵索引（聚簇索引）：葉子節(jié)點存的是整行的數據 非主鍵索引（二級索引）：葉子節(jié)點存的主鍵的值
”
簡述B-Tree與B+樹
B-Tree 是一種自平衡的多叉樹。每個節(jié)點都存儲關鍵字值。其左子節(jié)點的關鍵字值小于該節(jié)點關鍵字值，且右子節(jié)點的關鍵字值大于或等于該節(jié)點關鍵字值。
B+樹也是是一種自平衡的多叉樹。其基本定義與B樹相同，不同點在于數據只出現(xiàn)在葉子節(jié)點，所有葉子節(jié)點增加了一個鏈指針，方便進行范圍查詢。
B+樹中間節(jié)點不存放數據，所以同樣大小的磁盤頁上可以容納更多節(jié)點元素，訪問葉子節(jié)點上關聯(lián)的數據也具有更好的緩存命中率。并且數據順序排列并且相連，所以便于區(qū)間查找和搜索。
B樹每一個節(jié)點都包含key和value，查詢效率比B+樹高。
簡述Hash索引
哈希索引對于每一行數據計算一個哈希碼，并將所有的哈希碼存儲在索引中，同時在哈希表中保存指向每個數據行的指針。只有 Memory 引擎顯式支持哈希索引。
Hash索引不支持范圍查詢，無法用于排序，也不支持部分索引列匹配查找。
簡述自適應Hash索引
InnoDB對于頻繁使用的某些索引值，會在內存中基于 B-Tree 索引之上再創(chuàng)鍵一個哈希索引，這也被稱為自適應Hash索引。
簡述聚集索引和稀疏索引
聚集索引按每張表的主鍵構建一棵B+樹，數據庫中的每個搜索鍵值都有一個索引記錄，每個數據頁通過雙向鏈表連接。表數據訪問更快，但表更新代價高。
稀疏索引不會為每個搜索關鍵字創(chuàng)建索引記錄。搜索過程需要，我們首先按索引記錄進行操作，并按順序搜索，直到找到所需的數據為止。
簡述輔助索引與回表查詢
輔助索引是非聚集索引，葉子節(jié)點不包含記錄的全部數據，包含了一個書簽用來告訴InnoDB哪里可以找到與索引相對應的行數據。
通過輔助索引查詢，先通過書簽查到聚集索引，再根據聚集索引查對應的值，需要兩次，也稱為回表查詢。
簡述聯(lián)合索引和最左匹配原則
聯(lián)合索引是指對表上的多個列的關鍵詞進行索引。
對于聯(lián)合索引的查詢，如果精確匹配聯(lián)合索引的左邊連續(xù)一列或者多列，則mysql會一直向右匹配直到遇到范圍查詢（>,<,between,like）就停止匹配。Mysql會對第一個索引字段數據進行排序，在第一個字段基礎上，再對第二個字段排序。
簡述覆蓋索引
覆蓋索引指一個索引包含或覆蓋了所有需要查詢的字段的值，不需要回表查詢，即索引本身存了對應的值。
為什么數據庫不用紅黑樹用B+樹
紅黑樹的出度為 2，而 B Tree 的出度一般都非常大。紅黑樹的樹高 h 很明顯比 B Tree 大非常多，IO次數很多，導致會比較慢，因此檢索的次數也就更多。
B+Tree 相比于 B-Tree 更適合外存索引，擁有更大的出度，IO次數較少，檢索效率會更高。
基于主鍵索引的查詢和非主鍵索引的查詢有什么區(qū)別？
對于select * from 主鍵=XX，基于主鍵的普通查詢僅查找主鍵這棵樹，對于select * from 非主鍵=XX，基于非主鍵的查詢有可能存在回表過程（回到主鍵索引樹搜索的過程稱為回表），因為非主鍵索引葉子節(jié)點僅存主鍵值，無整行全部信息。
非主鍵索引的查詢一定會回表嗎？
不一定，當查詢語句的要求字段全部命中索引，不用回表查詢。如select 主鍵 from 非主鍵=XX，此時非主鍵索引葉子節(jié)點即可拿到主鍵信息，不用回表。
簡述MySQL使用EXPLAIN 的關鍵字段
explain關鍵字用于分析sql語句的執(zhí)行情況，可以通過他進行sql語句的性能分析。
type：表示連接類型，從好到差的類型排序為
system：系統(tǒng)表，數據已經加載到內存里。 const：常量連接，通過索引一次就找到。 eq_ref：唯一性索引掃描，返回所有匹配某個單獨值的行。 ref：非主鍵非唯一索引等值掃描，const或eq_ref改為普通非唯一索引。 range：范圍掃描，在索引上掃碼特定范圍內的值。 index：索引樹掃描，掃描索引上的全部數據。 all：全表掃描。
key：顯示MySQL實際決定使用的鍵。
key_len：顯示MySQL決定使用的鍵長度，長度越短越好
Extra：額外信息
Using filesort：MySQL使用外部的索引排序，很慢需要優(yōu)化。 Using temporary：使用了臨時表保存中間結果，很慢需要優(yōu)化。 Using index：使用了覆蓋索引。 Using where：使用了where。
簡述MySQL優(yōu)化流程
通過慢日志定位執(zhí)行較慢的SQL語句 利用explain對這些關鍵字段進行分析 根據分析結果進行優(yōu)化
簡述MySQL中的日志log
redo log: 存儲引擎級別的log（InnoDB有，MyISAM沒有），該log關注于事務的恢復.在重啟mysql服務的時候，根據redo log進行重做，從而使事務有持久性。
undo log：是存儲引擎級別的log（InnoDB有，MyISAM沒有）保證數據的原子性，該log保存了事務發(fā)生之前的數據的一個版本，可以用于回滾，是MVCC的重要實現(xiàn)方法之一。
bin log：數據庫級別的log，關注恢復數據庫的數據。
簡述事務
事務內的語句要么全部執(zhí)行成功，要么全部執(zhí)行失敗。
事務滿足如下幾個特性：
原子性（Atomicity）: “
一個事務中的所有操作要么全部完成，要么全部不完成。
”一致性（Consistency）: “
事務執(zhí)行前后數據庫的狀態(tài)保存一致。
”隔離性（Isolation） “
多個并發(fā)事務對數據庫進行操作，事務間互不干擾。
”持久性（Durability） “
事務執(zhí)行完畢，對數據的修改是永久的，即使系統(tǒng)故障也不會丟失
”
數據庫中多個事務同時進行可能會出現(xiàn)什么問題？
丟失修改 臟讀：當前事務可以查看到別的事務未提交的數據。 不可重讀：在同一事務中，使用相同的查詢語句，同一數據資源莫名改變了。 幻讀：在同一事務中，使用相同的查詢語句，莫名多出了一些之前不存在的數據，或莫名少了一些原先存在的數據。
SQL的事務隔離級別有哪些？
讀未提交： “
一個事務還沒提交，它做的變更就能被別的事務看到。
”讀提交： “
一個事務提交后，它做的變更才能被別的事務看到。
”可重復讀： “
一個事務執(zhí)行過程中看到的數據總是和事務啟動時看到的數據是一致的。在這個級別下事務未提交，做出的變更其它事務也看不到。
”串行化： “
對于同一行記錄進行讀寫會分別加讀寫鎖，當發(fā)生讀寫鎖沖突，后面執(zhí)行的事務需等前面執(zhí)行的事務完成才能繼續(xù)執(zhí)行。
”
什么是MVCC？
MVCC為多版本并發(fā)控制，即同一條記錄在系統(tǒng)中存在多個版本。其存在目的是在保證數據一致性的前提下提供一種高并發(fā)的訪問性能。對數據讀寫在不加讀寫鎖的情況下實現(xiàn)互不干擾,從而實現(xiàn)數據庫的隔離性,在事務隔離級別為讀提交和可重復讀中使用到。
在InnoDB中，事務在開始前會向事務系統(tǒng)申請一個事務ID，該ID是按申請順序嚴格遞增的。每行數據具有多個版本，每次事務更新數據都會生成新的數據版本，而不會直接覆蓋舊的數據版本。數據的行結構中包含多個信息字段。其中實現(xiàn)MVCC的主要涉及最近更改該行數據的事務ID（DB_TRX_ID）和可以找到歷史數據版本的指針（DB_ROLL_PTR）。InnoDB在每個事務開啟瞬間會為其構造一個記錄當前已經開啟但未提交的事務ID的視圖數組。通過比較鏈表中的事務ID與該行數據的值與對應的DB_TRX_ID，并通過DB_ROLL_PTR找到歷史數據的值以及對應的DB_TRX_ID來決定當前版本的數據是否應該被當前事務所見。最終實現(xiàn)在不加鎖的情況下保證數據的一致性。
讀提交和可重復讀都基于MVCC實現(xiàn)，有什么區(qū)別？
在可重復讀級別下，只會在事務開始前創(chuàng)建視圖，事務中后續(xù)的查詢共用一個視圖。而讀提交級別下每個語句執(zhí)行前都會創(chuàng)建新的視圖。因此對于可重復讀，查詢只能看到事務創(chuàng)建前就已經提交的數據。而對于讀提交，查詢能看到每個語句啟動前已經提交的數據。
InnoDB如何保證事務的原子性、持久性和一致性？
利用undo log保障原子性。該log保存了事務發(fā)生之前的數據的一個版本，可以用于回滾，從而保證事務原子性。
利用redo log保證事務的持久性，該log關注于事務的恢復.在重啟mysql服務的時候，根據redo log進行重做，從而使事務有持久性。
利用undo log+redo log保障一致性。事務中的執(zhí)行需要redo log，如果執(zhí)行失敗，需要undo log 回滾。
MySQL是如何保證主備一致的？
MySQL通過binlog（二進制日志）實現(xiàn)主備一致。binlog記錄了所有修改了數據庫或可能修改數據庫的語句，而不會記錄select、show這種不會修改數據庫的語句。在備份的過程中，主庫A會有一個專門的線程將主庫A的binlog發(fā)送給 備庫B進行備份。其中binlog有三種記錄格式：
statement:記錄對數據庫進行修改的語句本身，有可能會記錄一些額外的相關信息。優(yōu)點是binlog日志量少，IO壓力小，性能較高。缺點是由于記錄的信息相對較少，在不同庫執(zhí)行時由于上下文的環(huán)境不同可能導致主備不一致。 row:記錄對數據庫做出修改的語句所影響到的數據行以及對這些行的修改。比如當修改涉及多行數據，會把涉及的每行數據都記錄到binlog。優(yōu)點是能夠完全的還原或者復制日志被記錄時的操作。缺點是日志量占用空間較大，IO壓力大，性能消耗較大。 mixed:混合使用上述兩種模式，一般的語句使用statment方式進行保存，如果遇到一些特殊的函數，則使用row模式進行記錄。MySQL自己會判斷這條SQL語句是否可能引起主備不一致，如果有可能，就用row格式， 否則就用statement格式。但是在生產環(huán)境中，一般會使用row模式。
redo log與binlog的區(qū)別？
redo log是InnoDB引擎特有的，只記錄該引擎中表的修改記錄。binlog是MySQL的Server層實現(xiàn)的，會記錄所有引擎對數據庫的修改。 redo log是物理日志，記錄的是在具體某個數據頁上做了什么修改；binlog是邏輯日志，記錄的是這個語句的原始邏輯。 redo log是循環(huán)寫的，空間固定會用完；binlog是可以追加寫入的，binlog文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。
crash-safe能力是什么？
InnoDB通過redo log保證即使數據庫發(fā)生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。
WAL技術是什么？
WAL的全稱是Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤。事務在提交寫入磁盤前，會先寫到redo log里面去。如果直接寫入磁盤涉及磁盤的隨機I/O訪問，涉及磁盤隨機I/O訪問是非常消耗時間的一個過程，相比之下先寫入redo log，后面再找合適的時機批量刷盤能提升性能。
兩階段提交是什么？
為了保證binlog和redo log兩份日志的邏輯一致，最終保證恢復到主備數據庫的數據是一致的，采用兩階段提交的機制。
執(zhí)行器調用存儲引擎接口，存儲引擎將修改更新到內存中后，將修改操作記錄redo log中，此時redo log處于prepare狀態(tài)。 存儲引擎告知執(zhí)行器執(zhí)行完畢，執(zhí)行器生成這個操作對應的binlog，并把binlog寫入磁盤。 執(zhí)行器調用引擎的提交事務接口，引擎把剛剛寫入的redo log改成提交commit狀態(tài)，更新完成。
只靠binlog可以支持數據庫崩潰恢復嗎？
不可以。歷史原因：
InnoDB在作為MySQL的插件加入MySQL引擎家族之前，就已經是一個提供了崩潰恢復和事務支持的引擎了。InnoDB接入了MySQL后，發(fā)現(xiàn)既然binlog沒有崩潰恢復的能力，那引入InnoDB原有的redo log來保證崩潰恢復能力。實現(xiàn)原因： binlog沒有記錄數據頁修改的詳細信息，不具備恢復數據頁的能力。binlog記錄著數據行的增刪改，但是不記錄事務對數據頁的改動，這樣細致的改動只記錄在redo log中。當一個事務做增刪改時，其實涉及到的數據頁改動非常細致和復雜，包括行的字段改動以及行頭部以及數據頁頭部的改動，甚至b+tree會因為插入一行而發(fā)生若干次頁面分裂，那么事務也會把所有這些改動記錄下來到redo log中。因為數據庫系統(tǒng)進程crash時刻，磁盤上面頁面鏡像可以非常混亂，其中有些頁面含有一些正在運行著的事務的改動，而一些已提交的事務的改動并沒有刷上磁盤。事務恢復過程可以理解為是要把沒有提交的事務的頁面改動都去掉，并把已經提交的事務的頁面改動都加上去這樣一個過程。這些信息，都是binlog中沒有記錄的，只記錄在了存儲引擎的redo log中。 操作寫入binlog可細分為write和fsync兩個過程，write指的就是指把日志寫入到文件系統(tǒng)的page cache，并沒有把數據持久化到磁盤,fsync才是將數據持久化到磁盤的操作。通過參數設置sync_binlog為0的時候，表示每次提交事務都只write，不fsync。此時數據庫崩潰可能導致部分提交的事務以及binlog日志由于沒有持久化而丟失。
簡述MySQL主從復制
MySQL提供主從復制功能，可以方便的實現(xiàn)數據的多處自動備份，不僅能增加數據庫的安全性，還能進行讀寫分離，提升數據庫負載性能。
主從復制流程：
在事務完成之前，主庫在binlog上記錄這些改變，完成binlog寫入過程后，主庫通知存儲引擎提交事物 從庫將主庫的binlog復制到對應的中繼日志，即開辟一個I/O工作線程，I/O線程在主庫上打開一個普通的連接，然后開始binlog dump process，將這些事件寫入中繼日志。從主庫的binlog中讀取事件，如果已經讀到最新了，線程進入睡眠并等待ma主庫產生新的事件。
讀寫分離：即只在MySQL主庫上寫，只在MySQL從庫上讀，以減少數據庫壓力，提高性能。
MySQL數據存儲過程
一般來說，普通的SQL語句需要先編譯然后執(zhí)行，而存儲過程可以理解為為了完成特定功能的已經編譯后的SQL語句集。用戶可通過存儲過程的名字并給定參數來調用。
MySQL數據庫觸發(fā)器
觸發(fā)器簡單來說就是監(jiān)視某種情況，并觸發(fā)某種操作。當觸發(fā)器所在表上出現(xiàn)指定事件(insert/update/delete)時，可指定時間(after/before)執(zhí)行特定事件(insert/update/delete)。
SQL優(yōu)化方法
核心就是避免全表掃描，多走索引。列舉常用的一些優(yōu)化方法：
盡量對利用字段較多的建立索引，即在 where 及 order by 涉及的列上建立索引。 盡量避免在 where 子句中使用 or ，null值判斷，in 和對字段進行表達式操作 建立索引時需要多考慮最左匹配原則
mysql的操作 增刪改查
增：INSERT INTO 表名（字段名1，字段名2，…）VALUES（值1，值2，…）
刪：DELETE FROM 表名 [WHERE 條件表達式] TRUNCTE [TABLE ] 表名（刪除整張表數據）
改：UPDATE 表名 SET 字段名1=值1，[ ，字段名2=值2，…] [ WHERE 條件表達式 ]
查：SELECT 字段名1，字段名2，… FROM 表名 [ WHERE 條件表達式 ]
mysql的查詢語法順序
where、group by、having、order by、limit
delete和truncate區(qū)別
delete是數據操縱語言（DML），其按行刪除，支持where語句，執(zhí)行操作采用行鎖，執(zhí)行操作時會將該操作記錄在redo和undo中，因此支持回滾。
truncate是數據定義語言（DDL），其操作隱式提交，不支持回滾，不支持where，刪除時采用表級鎖進行刪除。
什么情況下分表合適
針對存儲了百萬級乃至千萬級條記錄的大表。數據庫在查詢和插入的時候耗時太長，可通過分表，將大表拆分成小表，提升數據庫性能。
關系型數據庫與非關系型數據庫區(qū)別
關系型數據庫采用了關系模型（可以簡單理解為二維表格類型）組織數據，一般可以遵守事務的ACID特性 不是由關系模型進行存儲的均可視作非關系型數據庫，比如以鍵值對的redis，圖數據庫等。
樂觀鎖如何保證一致性
樂觀鎖保持一致性主要通過兩個方法。
通過數據屬性中，增加版本號屬性，進行比較，比較目前操作數據是否是最新版本。 CAS（compare and swap）即在對數據修改過程中，采用CAS算法，保證在并發(fā)下的一致性。
mysql為什么要用自增id作為主鍵
直接原因是其存儲機制。MySQL采用數據頁進行數據存儲。如果采用自增主鍵，在原先數據頁寫滿的情況下，MySQL對于新數據，直接開辟新頁進行寫操作。如果不采用自增主鍵，為保障索引有序，新數據需插入到合適位置上，由此針對頁數據滿的情況下，MySQL需要申請新頁，并將一部分之前的頁數據挪到新頁上，保證按索引有序存儲，相對自增主鍵IO開銷更大。
大數據量的分頁查詢怎么優(yōu)化
定位對應索引id所處的偏移位置，之后進行查詢。
select * from table where num = 8 limit 100000,1;
變?yōu)?/p>
select * from table where num = 8 and id >= (
select id from table where num = 8 limit 100000,1
) limit 100;
由于id走了索引，因此速度會有一定提升。
分庫分表怎么做
對于分庫，即將一個數據庫拆分為多個庫?？梢酝ㄟ^水平拆分，或者垂直拆分的方式，將表進行拆分。一般可以采用中間件Sharding-JDBC進行分庫分表。
char和varchar區(qū)別
CHAR的長度是不可變的，而VARCHAR的長度是可變的。因此CHAR效率高，VARCHAR效率偏低。
臟讀是什么，如何解決
一個事務讀取了另一個事務修改但未提交的數據
將事務隔離級別設置為：讀已提交，串行化，可重復讀進行解決。
不可重復讀是什么，如何解決
一個事務連續(xù)讀兩次數據，但結果不一樣。(兩次讀之間，數據被其他事務修改)。
將事務隔離級別設置為：串行化，可重復讀進行解決。
幻讀是什么，如何解決
一個事務連續(xù)讀兩次數據，讀取數據量不一樣。(兩次讀之前，數據被其他事務刪除或新增)。
將事務隔離級別設置為：串行化，或在innodb引擎中有gap鎖的情況下設置可重復讀進行解決。
丟失修改是什么
數據被兩個事務連續(xù)修改，導致第一個事務的修改被第二個事務覆蓋丟失。
簡述主鍵索引和唯一索引
主鍵是能夠唯一標識表中某一行的屬性或屬性組。對于表創(chuàng)建時未指定唯一索引的情況下，數據庫會自動生成某一隱藏字段，作為唯一索引。
唯一索引是在表上一個或者多個字段組合建立的索引。
什么時候需要創(chuàng)建索引
需要頻繁被作為查詢條件的字段 查詢過程中排序的字段創(chuàng)建索引 查詢過程中統(tǒng)計或者分組的字段
何時索引會失效
復合索引不滿足最左匹配原則 查詢條件有or where 查詢語句對索引列有數學運算或函數
Mysql varchar字段怎么存儲
varchar字段開頭包含一個變長字段的實際長度，后面存儲的是真實字符。