前言
本文主要受眾為開(kāi)發(fā)人員,所以不涉及到MySQL的服務(wù)部署等操作,且內(nèi)容較多,大家準(zhǔn)備好耐心和瓜子礦泉水.
前一陣系統(tǒng)的學(xué)習(xí)了一下MySQL,也有一些實(shí)際操作經(jīng)驗(yàn),偶然看到一篇和MySQL相關(guān)的面試文章,發(fā)現(xiàn)其中的一些問(wèn)題自己也回答不好,雖然知識(shí)點(diǎn)大部分都知道,但是無(wú)法將知識(shí)串聯(lián)起來(lái).
因此決定搞一個(gè)MySQL靈魂100問(wèn),試著用回答問(wèn)題的方式,讓自己對(duì)知識(shí)點(diǎn)的理解更加深入一點(diǎn).
此文不會(huì)事無(wú)巨細(xì)的從select的用法開(kāi)始講解mysql,主要針對(duì)的是開(kāi)發(fā)人員需要知道的一些MySQL的知識(shí)點(diǎn),主要包括索引,事務(wù),優(yōu)化等方面,以在面試中高頻的問(wèn)句形式給出答案.
索引相關(guān)
關(guān)于MySQL的索引,曾經(jīng)進(jìn)行過(guò)一次總結(jié),文章鏈接在這里 Mysql索引原理及其優(yōu)化.
1. 什么是索引?
索引是一種數(shù)據(jù)結(jié)構(gòu),可以幫助我們快速的進(jìn)行數(shù)據(jù)的查找.
2. 索引是個(gè)什么樣的數(shù)據(jù)結(jié)構(gòu)呢?
索引的數(shù)據(jù)結(jié)構(gòu)和具體存儲(chǔ)引擎的實(shí)現(xiàn)有關(guān), 在MySQL中使用較多的索引有Hash索引,B+樹(shù)索引等,而我們經(jīng)常使用的InnoDB存儲(chǔ)引擎的默認(rèn)索引實(shí)現(xiàn)為:B+樹(shù)索引.
3. Hash索引和B+樹(shù)所有有什么區(qū)別或者說(shuō)優(yōu)劣呢?
首先要知道Hash索引和B+樹(shù)索引的底層實(shí)現(xiàn)原理:
hash索引底層就是hash表,進(jìn)行查找時(shí),調(diào)用一次hash函數(shù)就可以獲取到相應(yīng)的鍵值,之后進(jìn)行回表查詢獲得實(shí)際數(shù)據(jù).B+樹(shù)底層實(shí)現(xiàn)是多路平衡查找樹(shù).對(duì)于每一次的查詢都是從根節(jié)點(diǎn)出發(fā),查找到葉子節(jié)點(diǎn)方可以獲得所查鍵值,然后根據(jù)查詢判斷是否需要回表查詢數(shù)據(jù).
那么可以看出他們有以下的不同:
- hash索引進(jìn)行等值查詢更快(一般情況下),但是卻無(wú)法進(jìn)行范圍查詢.
因?yàn)樵趆ash索引中經(jīng)過(guò)hash函數(shù)建立索引之后,索引的順序與原順序無(wú)法保持一致,不能支持范圍查詢.而B(niǎo)+樹(shù)的的所有節(jié)點(diǎn)皆遵循(左節(jié)點(diǎn)小于父節(jié)點(diǎn),右節(jié)點(diǎn)大于父節(jié)點(diǎn),多叉樹(shù)也類似),天然支持范圍.
- hash索引不支持使用索引進(jìn)行排序,原理同上.
- hash索引不支持模糊查詢以及多列索引的最左前綴匹配.原理也是因?yàn)閔ash函數(shù)的不可預(yù)測(cè).AAAA和AAAAB的索引沒(méi)有相關(guān)性.
- hash索引任何時(shí)候都避免不了回表查詢數(shù)據(jù),而B(niǎo)+樹(shù)在符合某些條件(聚簇索引,覆蓋索引等)的時(shí)候可以只通過(guò)索引完成查詢.
- hash索引雖然在等值查詢上較快,但是不穩(wěn)定.性能不可預(yù)測(cè),當(dāng)某個(gè)鍵值存在大量重復(fù)的時(shí)候,發(fā)生hash碰撞,此時(shí)效率可能極差.而B(niǎo)+樹(shù)的查詢效率比較穩(wěn)定,對(duì)于所有的查詢都是從根節(jié)點(diǎn)到葉子節(jié)點(diǎn),且樹(shù)的高度較低.
因此,在大多數(shù)情況下,直接選擇B+樹(shù)索引可以獲得穩(wěn)定且較好的查詢速度.而不需要使用hash索引.
4. 上面提到了B+樹(shù)在滿足聚簇索引和覆蓋索引的時(shí)候不需要回表查詢數(shù)據(jù),什么是聚簇索引?
在B+樹(shù)的索引中,葉子節(jié)點(diǎn)可能存儲(chǔ)了當(dāng)前的key值,也可能存儲(chǔ)了當(dāng)前的key值以及整行的數(shù)據(jù),這就是聚簇索引和非聚簇索引. 在InnoDB中,只有主鍵索引是聚簇索引,如果沒(méi)有主鍵,則挑選一個(gè)唯一鍵建立聚簇索引.如果沒(méi)有唯一鍵,則隱式的生成一個(gè)鍵來(lái)建立聚簇索引.
當(dāng)查詢使用聚簇索引時(shí),在對(duì)應(yīng)的葉子節(jié)點(diǎn),可以獲取到整行數(shù)據(jù),因此不用再次進(jìn)行回表查詢.
5. 非聚簇索引一定會(huì)回表查詢嗎?
不一定,這涉及到查詢語(yǔ)句所要求的字段是否全部命中了索引,如果全部命中了索引,那么就不必再進(jìn)行回表查詢.
舉個(gè)簡(jiǎn)單的例子,假設(shè)我們?cè)趩T工表的年齡上建立了索引,那么當(dāng)進(jìn)行select age from employee where age < 20的查詢時(shí),在索引的葉子節(jié)點(diǎn)上,已經(jīng)包含了age信息,不會(huì)再次進(jìn)行回表查詢.
6. 在建立索引的時(shí)候,都有哪些需要考慮的因素呢?
建立索引的時(shí)候一般要考慮到字段的使用頻率,經(jīng)常作為條件進(jìn)行查詢的字段比較適合.如果需要建立聯(lián)合索引的話,還需要考慮聯(lián)合索引中的順序.此外也要考慮其他方面,比如防止過(guò)多的所有對(duì)表造成太大的壓力.這些都和實(shí)際的表結(jié)構(gòu)以及查詢方式有關(guān).
7. 聯(lián)合索引是什么?為什么需要注意聯(lián)合索引中的順序?
MySQL可以使用多個(gè)字段同時(shí)建立一個(gè)索引,叫做聯(lián)合索引.在聯(lián)合索引中,如果想要命中索引,需要按照建立索引時(shí)的字段順序挨個(gè)使用,否則無(wú)法命中索引.
具體原因?yàn)?
MySQL使用索引時(shí)需要索引有序,假設(shè)現(xiàn)在建立了"name,age,school"的聯(lián)合索引,那么索引的排序?yàn)? 先按照name排序,如果name相同,則按照age排序,如果age的值也相等,則按照school進(jìn)行排序.
當(dāng)進(jìn)行查詢時(shí),此時(shí)索引僅僅按照name嚴(yán)格有序,因此必須首先使用name字段進(jìn)行等值查詢,之后對(duì)于匹配到的列而言,其按照age字段嚴(yán)格有序,此時(shí)可以使用age字段用做索引查找,,,以此類推.因此在建立聯(lián)合索引的時(shí)候應(yīng)該注意索引列的順序,一般情況下,將查詢需求頻繁或者字段選擇性高的列放在前面.此外可以根據(jù)特例的查詢或者表結(jié)構(gòu)進(jìn)行單獨(dú)的調(diào)整.
8. 創(chuàng)建的索引有沒(méi)有被使用到?或者說(shuō)怎么才可以知道這條語(yǔ)句運(yùn)行很慢的原因?
MySQL提供了explain命令來(lái)查看語(yǔ)句的執(zhí)行計(jì)劃,MySQL在執(zhí)行某個(gè)語(yǔ)句之前,會(huì)將該語(yǔ)句過(guò)一遍查詢優(yōu)化器,之后會(huì)拿到對(duì)語(yǔ)句的分析,也就是執(zhí)行計(jì)劃,其中包含了許多信息. 可以通過(guò)其中和索引有關(guān)的信息來(lái)分析是否命中了索引,例如possilbe_key,key,key_len等字段,分別說(shuō)明了此語(yǔ)句可能會(huì)使用的索引,實(shí)際使用的索引以及使用的索引長(zhǎng)度.
9. 那么在哪些情況下會(huì)發(fā)生針對(duì)該列創(chuàng)建了索引但是在查詢的時(shí)候并沒(méi)有使用呢?
- 使用不等于查詢,
- 列參與了數(shù)學(xué)運(yùn)算或者函數(shù)
- 在字符串like時(shí)左邊是通配符.類似于'%aaa'.
- 當(dāng)mysql分析全表掃描比使用索引快的時(shí)候不使用索引.
- 當(dāng)使用聯(lián)合索引,前面一個(gè)條件為范圍查詢,后面的即使符合最左前綴原則,也無(wú)法使用索引.
以上情況,MySQL無(wú)法使用索引.
事務(wù)相關(guān)
1. 什么是事務(wù)?
理解什么是事務(wù)最經(jīng)典的就是轉(zhuǎn)賬的栗子,相信大家也都了解,這里就不再說(shuō)一邊了.
事務(wù)是一系列的操作,他們要符合ACID特性.最常見(jiàn)的理解就是:事務(wù)中的操作要么全部成功,要么全部失敗.但是只是這樣還不夠的.
2. ACID是什么?可以詳細(xì)說(shuō)一下嗎?
A=Atomicity
原子性,就是上面說(shuō)的,要么全部成功,要么全部失敗.不可能只執(zhí)行一部分操作.
C=Consistency
系統(tǒng)(數(shù)據(jù)庫(kù))總是從一個(gè)一致性的狀態(tài)轉(zhuǎn)移到另一個(gè)一致性的狀態(tài),不會(huì)存在中間狀態(tài).
I=Isolation
隔離性: 通常來(lái)說(shuō):一個(gè)事務(wù)在完全提交之前,對(duì)其他事務(wù)是不可見(jiàn)的.注意前面的通常來(lái)說(shuō)加了紅色,意味著有例外情況.
D=Durability
持久性,一旦事務(wù)提交,那么就永遠(yuǎn)是這樣子了,哪怕系統(tǒng)崩潰也不會(huì)影響到這個(gè)事務(wù)的結(jié)果.
3. 同時(shí)有多個(gè)事務(wù)在進(jìn)行會(huì)怎么樣呢?
多事務(wù)的并發(fā)進(jìn)行一般會(huì)造成以下幾個(gè)問(wèn)題:
- 臟讀: A事務(wù)讀取到了B事務(wù)未提交的內(nèi)容,而B(niǎo)事務(wù)后面進(jìn)行了回滾.
- 不可重復(fù)讀: 當(dāng)設(shè)置A事務(wù)只能讀取B事務(wù)已經(jīng)提交的部分,會(huì)造成在A事務(wù)內(nèi)的兩次查詢,結(jié)果竟然不一樣,因?yàn)樵诖似陂gB事務(wù)進(jìn)行了提交操作.
- 幻讀: A事務(wù)讀取了一個(gè)范圍的內(nèi)容,而同時(shí)B事務(wù)在此期間插入了一條數(shù)據(jù).造成"幻覺(jué)".
4. 怎么解決這些問(wèn)題呢?MySQL的事務(wù)隔離級(jí)別了解嗎?
MySQL的四種隔離級(jí)別如下:
- 未提交讀(READ UNCOMMITTED)
這就是上面所說(shuō)的例外情況了,這個(gè)隔離級(jí)別下,其他事務(wù)可以看到本事務(wù)沒(méi)有提交的部分修改.因此會(huì)造成臟讀的問(wèn)題(讀取到了其他事務(wù)未提交的部分,而之后該事務(wù)進(jìn)行了回滾).
這個(gè)級(jí)別的性能沒(méi)有足夠大的優(yōu)勢(shì),但是又有很多的問(wèn)題,因此很少使用.
- 已提交讀(READ COMMITTED)
其他事務(wù)只能讀取到本事務(wù)已經(jīng)提交的部分.這個(gè)隔離級(jí)別有 不可重復(fù)讀的問(wèn)題,在同一個(gè)事務(wù)內(nèi)的兩次讀取,拿到的結(jié)果竟然不一樣,因?yàn)榱硗庖粋€(gè)事務(wù)對(duì)數(shù)據(jù)進(jìn)行了修改.
- REPEATABLE READ(可重復(fù)讀)
可重復(fù)讀隔離級(jí)別解決了上面不可重復(fù)讀的問(wèn)題(看名字也知道),但是仍然有一個(gè)新問(wèn)題,就是 幻讀,當(dāng)你讀取id> 10 的數(shù)據(jù)行時(shí),對(duì)涉及到的所有行加上了讀鎖,此時(shí)例外一個(gè)事務(wù)新插入了一條id=11的數(shù)據(jù),因?yàn)槭切虏迦氲?所以不會(huì)觸發(fā)上面的鎖的排斥,那么進(jìn)行本事務(wù)進(jìn)行下一次的查詢時(shí)會(huì)發(fā)現(xiàn)有一條id=11的數(shù)據(jù),而上次的查詢操作并沒(méi)有獲取到,再進(jìn)行插入就會(huì)有主鍵沖突的問(wèn)題.
- SERIALIZABLE(可串行化)
這是最高的隔離級(jí)別,可以解決上面提到的所有問(wèn)題,因?yàn)樗麖?qiáng)制將所以的操作串行執(zhí)行,這會(huì)導(dǎo)致并發(fā)性能極速下降,因此也不是很常用.
5. Innodb使用的是哪種隔離級(jí)別呢?
InnoDB默認(rèn)使用的是可重復(fù)讀隔離級(jí)別.
6. 對(duì)MySQL的鎖了解嗎?
當(dāng)數(shù)據(jù)庫(kù)有并發(fā)事務(wù)的時(shí)候,可能會(huì)產(chǎn)生數(shù)據(jù)的不一致,這時(shí)候需要一些機(jī)制來(lái)保證訪問(wèn)的次序,鎖機(jī)制就是這樣的一個(gè)機(jī)制.
就像酒店的房間,如果大家隨意進(jìn)出,就會(huì)出現(xiàn)多人搶奪同一個(gè)房間的情況,而在房間上裝上鎖,申請(qǐng)到鑰匙的人才可以入住并且將房間鎖起來(lái),其他人只有等他使用完畢才可以再次使用.
7. MySQL都有哪些鎖呢?像上面那樣子進(jìn)行鎖定豈不是有點(diǎn)阻礙并發(fā)效率了?
從鎖的類別上來(lái)講,有共享鎖和排他鎖.
共享鎖: 又叫做讀鎖. 當(dāng)用戶要進(jìn)行數(shù)據(jù)的讀取時(shí),對(duì)數(shù)據(jù)加上共享鎖.共享鎖可以同時(shí)加上多個(gè).
排他鎖: 又叫做寫(xiě)鎖. 當(dāng)用戶要進(jìn)行數(shù)據(jù)的寫(xiě)入時(shí),對(duì)數(shù)據(jù)加上排他鎖.排他鎖只可以加一個(gè),他和其他的排他鎖,共享鎖都相斥.
用上面的例子來(lái)說(shuō)就是用戶的行為有兩種,一種是來(lái)看房,多個(gè)用戶一起看房是可以接受的. 一種是真正的入住一晚,在這期間,無(wú)論是想入住的還是想看房的都不可以.
鎖的粒度取決于具體的存儲(chǔ)引擎,InnoDB實(shí)現(xiàn)了行級(jí)鎖,頁(yè)級(jí)鎖,表級(jí)鎖.
他們的加鎖開(kāi)銷從大大小,并發(fā)能力也是從大到小.
表結(jié)構(gòu)設(shè)計(jì)
1. 為什么要盡量設(shè)定一個(gè)主鍵?
主鍵是數(shù)據(jù)庫(kù)確保數(shù)據(jù)行在整張表唯一性的保障,即使業(yè)務(wù)上本張表沒(méi)有主鍵,也建議添加一個(gè)自增長(zhǎng)的ID列作為主鍵.設(shè)定了主鍵之后,在后續(xù)的刪改查的時(shí)候可能更加快速以及確保操作數(shù)據(jù)范圍安全.
2. 主鍵使用自增ID還是UUID?
推薦使用自增ID,不要使用UUID.
因?yàn)樵贗nnoDB存儲(chǔ)引擎中,主鍵索引是作為聚簇索引存在的,也就是說(shuō),主鍵索引的B+樹(shù)葉子節(jié)點(diǎn)上存儲(chǔ)了主鍵索引以及全部的數(shù)據(jù)(按照順序),如果主鍵索引是自增ID,那么只需要不斷向后排列即可,如果是UUID,由于到來(lái)的ID與原來(lái)的大小不確定,會(huì)造成非常多的數(shù)據(jù)插入,數(shù)據(jù)移動(dòng),然后導(dǎo)致產(chǎn)生很多的內(nèi)存碎片,進(jìn)而造成插入性能的下降.
總之,在數(shù)據(jù)量大一些的情況下,用自增主鍵性能會(huì)好一些.
圖片來(lái)源于《高性能MySQL》: 其中默認(rèn)后綴為使用自增ID,_uuid為使用UUID為主鍵的測(cè)試,測(cè)試了插入100w行和300w行的性能.
關(guān)于主鍵是聚簇索引,如果沒(méi)有主鍵,InnoDB會(huì)選擇一個(gè)唯一鍵來(lái)作為聚簇索引,如果沒(méi)有唯一鍵,會(huì)生成一個(gè)隱式的主鍵.
If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.
If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index.
3. 字段為什么要求定義為not null?
MySQL官網(wǎng)這樣介紹:
NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL columntakes one bit extra, rounded up to the nearest byte.
null值會(huì)占用更多的字節(jié),且會(huì)在程序中造成很多與預(yù)期不符的情況.
4. 如果要存儲(chǔ)用戶的密碼散列,應(yīng)該使用什么字段進(jìn)行存儲(chǔ)?
密碼散列,鹽,用戶身份證號(hào)等固定長(zhǎng)度的字符串應(yīng)該使用char而不是varchar來(lái)存儲(chǔ),這樣可以節(jié)省空間且提高檢索效率.
存儲(chǔ)引擎相關(guān)
1. MySQL支持哪些存儲(chǔ)引擎?
MySQL支持多種存儲(chǔ)引擎,比如InnoDB,MyISAM,Memory,Archive等等.在大多數(shù)的情況下,直接選擇使用InnoDB引擎都是最合適的,InnoDB也是MySQL的默認(rèn)存儲(chǔ)引擎.
- InnoDB和MyISAM有什么區(qū)別?
- InnoDB支持事物畔咧，而MyISAM不支持事物
- InnoDB支持行級(jí)鎖茵乱，而MyISAM支持表級(jí)鎖
- InnoDB支持MVCC, 而MyISAM不支持
- InnoDB支持外鍵唠帝，而MyISAM不支持
- InnoDB不支持全文索引众羡，而MyISAM支持擒悬。
零散問(wèn)題
1. MySQL中的varchar和char有什么區(qū)別.
char是一個(gè)定長(zhǎng)字段,假如申請(qǐng)了char(10)的空間,那么無(wú)論實(shí)際存儲(chǔ)多少內(nèi)容.該字段都占用10個(gè)字符,而varchar是變長(zhǎng)的,也就是說(shuō)申請(qǐng)的只是最大長(zhǎng)度,占用的空間為實(shí)際字符長(zhǎng)度+1,最后一個(gè)字符存儲(chǔ)使用了多長(zhǎng)的空間.
在檢索效率上來(lái)講,char > varchar,因此在使用中,如果確定某個(gè)字段的值的長(zhǎng)度,可以使用char,否則應(yīng)該盡量使用varchar.例如存儲(chǔ)用戶MD5加密后的密碼,則應(yīng)該使用char.
2. varchar(10)和int(10)代表什么含義?
varchar的10代表了申請(qǐng)的空間長(zhǎng)度,也是可以存儲(chǔ)的數(shù)據(jù)的最大長(zhǎng)度,而int的10只是代表了展示的長(zhǎng)度,不足10位以0填充.也就是說(shuō),int(1)和int(10)所能存儲(chǔ)的數(shù)字大小以及占用的空間都是相同的,只是在展示時(shí)按照長(zhǎng)度展示.
3. MySQL的binlog有有幾種錄入格式?分別有什么區(qū)別?
有三種格式,statement,row和mixed.
- statement模式下,記錄單元為語(yǔ)句.即每一個(gè)sql造成的影響會(huì)記錄.由于sql的執(zhí)行是有上下文的,因此在保存的時(shí)候需要保存相關(guān)的信息,同時(shí)還有一些使用了函數(shù)之類的語(yǔ)句無(wú)法被記錄復(fù)制.
- row級(jí)別下,記錄單元為每一行的改動(dòng),基本是可以全部記下來(lái)但是由于很多操作,會(huì)導(dǎo)致大量行的改動(dòng)(比如alter table),因此這種模式的文件保存的信息太多,日志量太大.
- mixed. 一種折中的方案,普通操作使用statement記錄,當(dāng)無(wú)法使用statement的時(shí)候使用row.
此外,新版的MySQL中對(duì)row級(jí)別也做了一些優(yōu)化,當(dāng)表結(jié)構(gòu)發(fā)生變化的時(shí)候,會(huì)記錄語(yǔ)句而不是逐行記錄.
4. 超大分頁(yè)怎么處理?
超大的分頁(yè)一般從兩個(gè)方向上來(lái)解決.
- 數(shù)據(jù)庫(kù)層面,這也是我們主要集中關(guān)注的(雖然收效沒(méi)那么大),類似于
select * from table where age > 20 limit 1000000,10這種查詢其實(shí)也是有可以優(yōu)化的余地的. 這條語(yǔ)句需要load1000000數(shù)據(jù)然后基本上全部丟棄,只取10條當(dāng)然比較慢. 當(dāng)時(shí)我們可以修改為select * from table where id in (select id from table where age > 20 limit 1000000,10).這樣雖然也load了一百萬(wàn)的數(shù)據(jù),但是由于索引覆蓋,要查詢的所有字段都在索引中,所以速度會(huì)很快. 同時(shí)如果ID連續(xù)的好,我們還可以select * from table where id > 1000000 limit 10,效率也是不錯(cuò)的,優(yōu)化的可能性有許多種,但是核心思想都一樣,就是減少load的數(shù)據(jù). - 從需求的角度減少這種請(qǐng)求….主要是不做類似的需求(直接跳轉(zhuǎn)到幾百萬(wàn)頁(yè)之后的具體某一頁(yè).只允許逐頁(yè)查看或者按照給定的路線走,這樣可預(yù)測(cè),可緩存)以及防止ID泄漏且連續(xù)被人惡意攻擊.
解決超大分頁(yè),其實(shí)主要是靠緩存,可預(yù)測(cè)性的提前查到內(nèi)容,緩存至redis等k-V數(shù)據(jù)庫(kù)中,直接返回即可.
在阿里巴巴《Java開(kāi)發(fā)手冊(cè)》中,對(duì)超大分頁(yè)的解決辦法是類似于上面提到的第一種.
5. 關(guān)心過(guò)業(yè)務(wù)系統(tǒng)里面的sql耗時(shí)嗎?統(tǒng)計(jì)過(guò)慢查詢嗎?對(duì)慢查詢都怎么優(yōu)化過(guò)?
在業(yè)務(wù)系統(tǒng)中,除了使用主鍵進(jìn)行的查詢,其他的我都會(huì)在測(cè)試庫(kù)上測(cè)試其耗時(shí),慢查詢的統(tǒng)計(jì)主要由運(yùn)維在做,會(huì)定期將業(yè)務(wù)中的慢查詢反饋給我們.
慢查詢的優(yōu)化首先要搞明白慢的原因是什么? 是查詢條件沒(méi)有命中索引?是load了不需要的數(shù)據(jù)列?還是數(shù)據(jù)量太大?
所以優(yōu)化也是針對(duì)這三個(gè)方向來(lái)的,
- 首先分析語(yǔ)句,看看是否load了額外的數(shù)據(jù),可能是查詢了多余的行并且拋棄掉了,可能是加載了許多結(jié)果中并不需要的列,對(duì)語(yǔ)句進(jìn)行分析以及重寫(xiě).
- 分析語(yǔ)句的執(zhí)行計(jì)劃,然后獲得其使用索引的情況,之后修改語(yǔ)句或者修改索引,使得語(yǔ)句可以盡可能的命中索引.
- 如果對(duì)語(yǔ)句的優(yōu)化已經(jīng)無(wú)法進(jìn)行,可以考慮表中的數(shù)據(jù)量是否太大,如果是的話可以進(jìn)行橫向或者縱向的分表.
6. 上面提到橫向分表和縱向分表,可以分別舉一個(gè)適合他們的例子嗎?
橫向分表是按行分表.假設(shè)我們有一張用戶表,主鍵是自增ID且同時(shí)是用戶的ID.數(shù)據(jù)量較大,有1億多條,那么此時(shí)放在一張表里的查詢效果就不太理想.我們可以根據(jù)主鍵ID進(jìn)行分表,無(wú)論是按尾號(hào)分,或者按ID的區(qū)間分都是可以的. 假設(shè)按照尾號(hào)0-99分為100個(gè)表,那么每張表中的數(shù)據(jù)就僅有100w.這時(shí)的查詢效率無(wú)疑是可以滿足要求的.
縱向分表是按列分表.假設(shè)我們現(xiàn)在有一張文章表.包含字段id-摘要-內(nèi)容.而系統(tǒng)中的展示形式是刷新出一個(gè)列表,列表中僅包含標(biāo)題和摘要,當(dāng)用戶點(diǎn)擊某篇文章進(jìn)入詳情時(shí)才需要正文內(nèi)容.此時(shí),如果數(shù)據(jù)量大,將內(nèi)容這個(gè)很大且不經(jīng)常使用的列放在一起會(huì)拖慢原表的查詢速度.我們可以將上面的表分為兩張.id-摘要,id-內(nèi)容.當(dāng)用戶點(diǎn)擊詳情,那主鍵再來(lái)取一次內(nèi)容即可.而增加的存儲(chǔ)量只是很小的主鍵字段.代價(jià)很小.
當(dāng)然,分表其實(shí)和業(yè)務(wù)的關(guān)聯(lián)度很高,在分表之前一定要做好調(diào)研以及benchmark.不要按照自己的猜想盲目操作.
7. 什么是存儲(chǔ)過(guò)程摊唇？有哪些優(yōu)缺點(diǎn)左医？
存儲(chǔ)過(guò)程是一些預(yù)編譯的SQL語(yǔ)句。1特姐、更加直白的理解：存儲(chǔ)過(guò)程可以說(shuō)是一個(gè)記錄集晶丘，它是由一些T-SQL語(yǔ)句組成的代碼塊，這些T-SQL語(yǔ)句代碼像一個(gè)方法一樣實(shí)現(xiàn)一些功能（對(duì)單表或多表的增刪改查），然后再給這個(gè)代碼塊取一個(gè)名字浅浮，在用到這個(gè)功能的時(shí)候調(diào)用他就行了沫浆。2、存儲(chǔ)過(guò)程是一個(gè)預(yù)編譯的代碼塊滚秩，執(zhí)行效率比較高,一個(gè)存儲(chǔ)過(guò)程替代大量T_SQL語(yǔ)句 专执，可以降低網(wǎng)絡(luò)通信量，提高通信速率,可以一定程度上確保數(shù)據(jù)安全
但是,在互聯(lián)網(wǎng)項(xiàng)目中,其實(shí)是不太推薦存儲(chǔ)過(guò)程的,比較出名的就是阿里的《Java開(kāi)發(fā)手冊(cè)》中禁止使用存儲(chǔ)過(guò)程,我個(gè)人的理解是,在互聯(lián)網(wǎng)項(xiàng)目中,迭代太快,項(xiàng)目的生命周期也比較短,人員流動(dòng)相比于傳統(tǒng)的項(xiàng)目也更加頻繁,在這樣的情況下,存儲(chǔ)過(guò)程的管理確實(shí)是沒(méi)有那么方便,同時(shí),復(fù)用性也沒(méi)有寫(xiě)在服務(wù)層那么好.
8. 說(shuō)一說(shuō)三個(gè)范式
第一范式: 每個(gè)列都不可以再拆分. 第二范式: 非主鍵列完全依賴于主鍵,而不能是依賴于主鍵的一部分. 第三范式: 非主鍵列只依賴于主鍵,不依賴于其他非主鍵.
在設(shè)計(jì)數(shù)據(jù)庫(kù)結(jié)構(gòu)的時(shí)候,要盡量遵守三范式,如果不遵守,必須有足夠的理由.比如性能. 事實(shí)上我們經(jīng)常會(huì)為了性能而妥協(xié)數(shù)據(jù)庫(kù)的設(shè)計(jì).
9. MyBatis中的#
亂入了一個(gè)奇怪的問(wèn)題…..我只是想單獨(dú)記錄一下這個(gè)問(wèn)題,因?yàn)槌霈F(xiàn)頻率太高了.
會(huì)將傳入的內(nèi)容當(dāng)做字符串,而有什么區(qū)別???亂入了一個(gè)奇怪的問(wèn)題.....我只是想單獨(dú)記錄一下這個(gè)問(wèn)題,因?yàn)槌霈F(xiàn)頻率太高了.#會(huì)將傳入的內(nèi)容當(dāng)做字符串,而會(huì)直接將傳入值拼接在sql語(yǔ)句中.
所以#可以在一定程度上預(yù)防sql注入攻擊.
