1.1數(shù)據(jù)庫(kù)架構(gòu)：

如何設(shè)計(jì)一個(gè)關(guān)系型數(shù)據(jù)庫(kù)?

存儲(chǔ)模塊（文件系統(tǒng)）用塊或者頁(yè)作為存儲(chǔ)單位

程序?qū)嵗?#xff1a;

存儲(chǔ)管理

緩存機(jī)制 不宜過(guò)大，要有淘汰機(jī)制

SQL解析

日志管理

權(quán)限劃分

容災(zāi)機(jī)制

索引管理

鎖管理

1.2 索引

為什么要使用索引？

全表掃描：

數(shù)據(jù)庫(kù)存儲(chǔ)用塊或者頁(yè)存儲(chǔ)，全表掃描時(shí)，需要將整個(gè)表加載到緩存中，當(dāng)數(shù)據(jù)量很小的時(shí)候，緩存可以一次加載所有數(shù)據(jù)量，全表掃描就會(huì)比較快，而當(dāng)數(shù)據(jù)量很大需要緩存多次加載，就會(huì)很慢，這個(gè)時(shí)候就要用到索引。

索引來(lái)源于字典，將關(guān)鍵信息集中起來(lái)，快速查找數(shù)據(jù)

因?yàn)樗饕軌虮苊馊頀呙璨檎覕?shù)據(jù)，提升檢索效率

什么樣的信息能成為索引？

能把該記錄限定在一定查找范圍中的字段

主鍵，唯一鍵以及普通鍵 能夠讓數(shù)據(jù)具備一定區(qū)分度的字段

索引的數(shù)據(jù)結(jié)構(gòu)？

主流是B+Tree，還有Hash結(jié)構(gòu) bitMap索引，其中MySql不支持BitMap索引，同時(shí)基于MyISAM 或 InnoDB的MySql不支持Hash

二叉查找樹(shù)：

有左右子樹(shù)，對(duì)于樹(shù)中的節(jié)點(diǎn)值X 他的左子樹(shù)的任意節(jié)點(diǎn)值小于X，右字?jǐn)?shù)任意節(jié)點(diǎn)值大于X，時(shí)間復(fù)雜度O(logn)

但在插入過(guò)程中可能會(huì)產(chǎn)生以下問(wèn)題 導(dǎo)致IO次數(shù)變多時(shí)間復(fù)雜度變?yōu)镺(n)，比全表掃描都要慢得多

B-Tree （通過(guò)合并上移下移來(lái)保證特征）

特征：

根節(jié)點(diǎn)至少包括兩個(gè)孩子

樹(shù)中每個(gè)節(jié)點(diǎn)最多含有M個(gè)孩子（m>=2）

除根節(jié)點(diǎn)和葉節(jié)點(diǎn)外，其他每個(gè)節(jié)點(diǎn)至少有ceil(m/2)個(gè)孩子

所有終端葉子節(jié)點(diǎn)都位于同一層（即葉子節(jié)點(diǎn)高度一致）

假設(shè)每個(gè)非終端結(jié)點(diǎn)中包含N個(gè)關(guān)鍵字信息，其中1)Ki（i=1...n）為關(guān)鍵字，且關(guān)鍵字按順序升序排序K(i-1)<Ki, 2)關(guān)鍵字的個(gè)數(shù)N必須滿足：{cell（m/2）-1} <= n <= m-1，3）非葉子結(jié)點(diǎn)的指針P[1],P[2] P[3]... P[M]其中P[1]指向關(guān)鍵字小于K[1]的子樹(shù)，P[m]指向關(guān)鍵字大于K[m-1]的子樹(shù)，其他P[i]指向關(guān)鍵字屬于(K[i-1],k[i])的子樹(shù)

B+-Tree （B-Tree 的變體）

非葉子節(jié)點(diǎn)的子樹(shù)指針與關(guān)鍵字個(gè)數(shù)相同

非葉子節(jié)點(diǎn)得子樹(shù)指針P[I]，指向關(guān)鍵字【K[i],K[i+1]】的子樹(shù)

非葉子節(jié)點(diǎn)僅用來(lái)做索引，數(shù)據(jù)保存在葉子節(jié)點(diǎn)中，即非葉子節(jié)點(diǎn)值和葉子節(jié)點(diǎn)值可能相同(保證樹(shù)更矮)

所有葉子節(jié)點(diǎn)均有一個(gè)鏈指針指向下一個(gè)葉子節(jié)點(diǎn)并按大小順序鏈接（可以方便橫向跨子樹(shù)進(jìn)行統(tǒng)計(jì)，比如n>10 會(huì)直接統(tǒng)計(jì)10以后的葉子節(jié)點(diǎn)而不統(tǒng)計(jì)10以前的）

結(jié)論：

B+Tree更適合用于做存儲(chǔ)索引

1）B+樹(shù)的磁盤讀寫代價(jià)更低，B+樹(shù)的內(nèi)部結(jié)構(gòu)沒(méi)有存儲(chǔ)指向關(guān)鍵字具體信息的指針，所容納的關(guān)鍵字多，一次IO可讀取關(guān)鍵字?jǐn)?shù)量更多。

2）B+樹(shù)的查詢效率更加穩(wěn)定，由于非終端點(diǎn)并不是最終指向文件內(nèi)容的結(jié)點(diǎn)，而只是葉子結(jié)點(diǎn)中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點(diǎn)到葉子結(jié)點(diǎn)的路。所有關(guān)鍵字查詢的路徑長(zhǎng)度相同，導(dǎo)致每一個(gè)數(shù)據(jù)的查詢效率相當(dāng)。

3）B+樹(shù)更有利于數(shù)據(jù)庫(kù)的掃描，只需要遍歷節(jié)點(diǎn)就可以完成對(duì)整個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)的掃描查找

Hash索引（理論上高于B+Tree）：不穩(wěn)定不支持線性查詢

存放通過(guò)HASH算法計(jì)算出來(lái)的Hash值和行指針

優(yōu)點(diǎn)

根據(jù)Hash的運(yùn)算可以一次查找到數(shù)據(jù)所在的鏈表

缺點(diǎn)

僅僅能滿足“=”，“in”,不能使用范圍查詢

無(wú)法被用來(lái)避免數(shù)據(jù)的排序操作

(HASH索引比較的是Hash算法計(jì)算后的值，不能保證和原有順序（大小）一致）

組合索引中Hash是用組合全部索引值的方式進(jìn)行查找的，無(wú)法通過(guò)組合索引中的部分索引鍵進(jìn)行查詢

無(wú)法避免表掃描，不同索引鍵可能存在相同索引值，需要通過(guò)訪問(wèn)實(shí)際數(shù)據(jù)進(jìn)行比較

遇到大量Hash值相等的情況后，性能并不一定就會(huì)比B-Tree索引高（有可能出現(xiàn)極端情況，即很多不同數(shù)據(jù)計(jì)算出的索引值都一樣變成線性存儲(chǔ)結(jié)構(gòu)）

BitMap（位圖）索引：

存儲(chǔ)時(shí)按照狀態(tài)分開(kāi)，每個(gè)數(shù)據(jù)是否是這個(gè)值，按位存儲(chǔ)

只適用于某個(gè)字段的值只有某種幾個(gè)的情況

鎖力度較大，不適合高并發(fā)聯(lián)機(jī)系統(tǒng)，適用于并發(fā)低但是統(tǒng)計(jì)多的。

密集索引和稀疏索引的區(qū)別：

密集索引文件中的每個(gè)搜索碼值都對(duì)應(yīng)一個(gè)索引值，葉子節(jié)點(diǎn)不僅僅保存鍵值 并且保存了位于同一行記錄里的其他列的信息，由于密集索引決定了一個(gè)表的物理排序，一個(gè)表只能有一個(gè)物理排列順序故只能創(chuàng)建一個(gè)密集索引

稀疏索引文件只為索引碼的某些值建立索引項(xiàng)，葉子節(jié)點(diǎn)僅保存鍵位信息和該行指針地址（或主鍵）定位到葉子后通過(guò)地址或主鍵尋找

存儲(chǔ)引擎：

MyISAM 索引和數(shù)據(jù)是分開(kāi)存儲(chǔ)的 （更適合大量的查詢操作）

InnoDB 索引和數(shù)據(jù)是一起存儲(chǔ)的 （支持事務(wù) 支持行級(jí)鎖 set update更快）

有且僅有一個(gè)密集索引

如果一個(gè)主鍵被定義，該主鍵作為密集索引

如果沒(méi)有主鍵被定義，該表的第一個(gè)唯一非空索引作為密集索引

若不滿足以上條件，innodb會(huì)在內(nèi)部生成一個(gè)隱藏主鍵

非主鍵索引存儲(chǔ)箱關(guān)鍵為何其對(duì)應(yīng)的主鍵值，兩次查找（查找次級(jí)索引自身，再查找主鍵索引或者物理索引索引）

如何定位并優(yōu)化慢SQL？

該題目比較看經(jīng)驗(yàn)

1）根據(jù)慢日志定位慢查詢SQL（數(shù)據(jù)定義語(yǔ)言不會(huì)進(jìn)入慢查詢

慢日志：記錄執(zhí)行比較慢的SQL 執(zhí)行命令：Show variables like‘ %quer%’

從上到下分別是：

SQL執(zhí)行時(shí)間即超過(guò)多少時(shí)間算執(zhí)行較慢，會(huì)記錄超過(guò)這個(gè)時(shí)間的慢查詢

慢日志開(kāi)關(guān)：set global slow_query_log= on；

慢日志路徑：set global long_query_time=1；(此句變量需要重連數(shù)據(jù)庫(kù)后才生效)

使用命令修改后再重啟數(shù)據(jù)庫(kù)服務(wù)后會(huì)回復(fù)默認(rèn)，可以在配置文件中修改

2）使用explain等工具分析sql：

顯示了mysql如何使用索引來(lái)處理select語(yǔ)句以及連接表。可以幫助選擇更好的索引和寫出更優(yōu)化的查詢語(yǔ)句

type：mysql找到數(shù)據(jù)行的方式 最優(yōu)—>最差(紅字需要優(yōu)化)

extra：中出現(xiàn)以下兩項(xiàng)表示mysql沒(méi)有使用索引

3+）修改sql（減少使用*，減少使用模糊查詢）或者使SQL盡量走索引（like‘%趙%’這種形式不會(huì)走索引，但是like‘趙%會(huì)走索引’、強(qiáng)制索引等）

mysql的查詢優(yōu)化器會(huì)盡可能的使用索引并且使用最嚴(yán)格的索引消除盡可能多的數(shù)據(jù)行，最終目標(biāo)是提交SQL語(yǔ)句查詢數(shù)據(jù)行而不是排除數(shù)據(jù)行，sql優(yōu)化器試圖排除語(yǔ)句的目的在于排除數(shù)據(jù)行的素的越快，找到與條件匹配的數(shù)據(jù)行就越快，sql優(yōu)化器會(huì)判斷密集索引的葉子結(jié)點(diǎn)會(huì)帶有數(shù)據(jù)，效率可能會(huì)低，故選擇稀疏索引（有時(shí)候不一定會(huì)最優(yōu)）。

聯(lián)合索引的最左匹配原則的成因？

最左匹配原則：對(duì)于索引（A，B），有where A=1會(huì)走該索引，where A=1and B=1也會(huì)走該索引，where B=1則不會(huì)走該索引；

mysql會(huì)一直向右匹配直到遇到范圍查詢（<,>,between,like）就停止匹配，比如a=3 and b=2 and c>5 and d=6,如果建立（abcd）順序的索引，d是用不到索引的，如果建立（abdc）順序的索引，abdc的索引都可以用到，abd 的順序可以任意調(diào)整；=和in可以亂序，比如a=1 and b=2 and c=3 建立（abc）索引可以任意順序，musql的查詢優(yōu)化器會(huì)幫你優(yōu)化成索引可以識(shí)別的形式。

mysql創(chuàng)建聯(lián)合索引會(huì)對(duì)復(fù)合索引的第一個(gè)索引字段排序在此基礎(chǔ)上再對(duì)第二個(gè)字段排序，其中第一個(gè)字段是有序的，第二個(gè)字段是無(wú)序的、所以用第一個(gè)字段是可以用到索引的，單獨(dú)用第二個(gè)字段是用不到索引的

從col3,col2,col1做索引會(huì)做出下圖所示的索引，單使用col2無(wú)法走索引。

索引是建立的越多越好嗎？

1）否定的，物極必反，數(shù)據(jù)量小的表不需要建立索引，建立會(huì)增加額外的索引開(kāi)銷

2）數(shù)據(jù)變更需要維護(hù)索引，更多的索引意味著更多的維護(hù)成本

3）更多的索引意味著需要更多的空間。

總結(jié)

以上是生活随笔為你收集整理的sql管理:索引超出范围必须为非负值并小于集合大小_java面试基础知识-数据库基础知识（数据库索引部分）...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。