2022年數(shù)據(jù)庫(kù)面試題及答案

2022年數(shù)據(jù)庫(kù)面試題及答案.主鍵、外鍵、超鍵、候選鍵超鍵：在關(guān)系中能唯一標(biāo)識(shí)元組的屬性集稱為關(guān)系模式的超鍵。一個(gè)屬性可以為作為一個(gè)超鍵，多個(gè)屬性組合在一起也可以作為一個(gè)超鍵。超鍵包含候選鍵和主鍵。候選鍵：是最小超鍵，即沒(méi)有冗余元素的超鍵。主鍵：數(shù)據(jù)庫(kù)表中對(duì)儲(chǔ)存數(shù)據(jù)對(duì)象予以唯一和完整標(biāo)識(shí)的數(shù)據(jù)列或?qū)傩缘慕M合。一個(gè)數(shù)據(jù)列只能有一個(gè)主鍵，且主鍵的取值不能缺失，即不能為空值（Null）。外鍵：在一個(gè)表中存在的另一個(gè)表的主鍵稱此表的外鍵。.為什么用自增列作為主鍵如果我們定義了主鍵（PRIMARYKEY）,那么InnoDB會(huì)選擇主鍵作為聚集索引、如果沒(méi)有顯式定義主鍵，那么InnoDB會(huì)選擇第一個(gè)不包含有NULL值的唯一索引作為主鍵索引、如果也沒(méi)有這樣的唯一索引，那么InnoDB會(huì)選擇內(nèi)置6字節(jié)長(zhǎng)的R0WID作為隱含的聚集索引（R0WID隨著行記錄的寫(xiě)入而主鍵遞增，這個(gè)R0WID不像ORACLE的ROWID那樣可引用,是隱含的）。數(shù)據(jù)記錄本身被存于主索引（一顆B+Tree）的葉子節(jié)點(diǎn)上。這就要求同一個(gè)葉子節(jié)點(diǎn)內(nèi)（大小為一個(gè)內(nèi)存頁(yè)或磁盤頁(yè)）的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當(dāng)有一條新的記錄插入時(shí)，MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置，如果頁(yè)面到達(dá)裝載因子（InnoDB默認(rèn)為15/16）,那么開(kāi)辟一個(gè)新的頁(yè)（節(jié)點(diǎn)）注意:很多公司都只是考察是否知道其概念，但是也有很多公司需要不僅僅知道概念，還需要?jiǎng)邮謱?xiě)sql,一般都是簡(jiǎn)單的連接查詢，具體關(guān)于連接查詢的sql練習(xí)，參見(jiàn)以下鏈接：?？途W(wǎng)數(shù)據(jù)庫(kù)SQL實(shí)戰(zhàn)Ieetcode中文網(wǎng)站數(shù)據(jù)庫(kù)練習(xí)我的另一篇文章，常用sql練習(xí)50題varchar和char的使用場(chǎng)景？char的長(zhǎng)度是不可變的，而varchar的長(zhǎng)度是可變的。定義一個(gè)char[10]和varchar[10]o如果存進(jìn)去的是'csdn’,那么char所占的長(zhǎng)度依然為10,除了字符'csdn'夕卜，后面跟六個(gè)空格，varchar就立馬把長(zhǎng)度變?yōu)?了，取數(shù)據(jù)的時(shí)候，char類型的要用trim()去掉多余的空格，而varchar是不需要的。char的存取數(shù)度還是要比varchar要快得多，因?yàn)槠溟L(zhǎng)度固定，方便程序的存儲(chǔ)與查找。char也為此付出的是空間的代價(jià)，因?yàn)槠溟L(zhǎng)度固定，所以難免會(huì)有多余的空格占位符占據(jù)空間，可謂是以空間換取時(shí)間效率。varchar是以空間效率為首位。char的存儲(chǔ)方式是：對(duì)英文字符(ASCII)占用1個(gè)字節(jié)，對(duì)一個(gè)漢字占用兩個(gè)字節(jié)。varchar的存儲(chǔ)方式是：對(duì)每個(gè)英文字符占用2個(gè)字節(jié)，漢字也占用2個(gè)字節(jié)。兩者的存儲(chǔ)數(shù)據(jù)都非unicode的字符數(shù)據(jù)。SQL語(yǔ)言分類SQL語(yǔ)言共分為四大類：數(shù)據(jù)查詢語(yǔ)言DQL數(shù)據(jù)操縱語(yǔ)言DML數(shù)據(jù)定義語(yǔ)言DDL數(shù)據(jù)控制語(yǔ)言DCLo.數(shù)據(jù)查詢語(yǔ)言DQL數(shù)據(jù)查詢語(yǔ)言DQL基本結(jié)構(gòu)是由SELECT子句，F(xiàn)ROM子句，WHERE子句組成的查詢塊：SELECTFROMWHERE.數(shù)據(jù)操縱語(yǔ)言DML數(shù)據(jù)操縱語(yǔ)言DML主要有三種形式：插入：INSERT更新：UPDATE刪除：DELETE.數(shù)據(jù)定義語(yǔ)言DDL數(shù)據(jù)定義語(yǔ)言DDL用來(lái)創(chuàng)立數(shù)據(jù)庫(kù)中的各種對(duì)象表、視圖、索引、同義詞、聚簇等如：CREATETABLE/VIEW/INDEX/SYN/CLUSTER表視圖索引同義詞簇DDL操作是隱性提交的!不能rollback.數(shù)據(jù)控制語(yǔ)言DCL數(shù)據(jù)控制語(yǔ)言DCL用來(lái)授予或回收訪問(wèn)數(shù)據(jù)庫(kù)的某種特權(quán)，并控制數(shù)據(jù)庫(kù)操縱事務(wù)發(fā)生的時(shí)間及效果，對(duì)數(shù)據(jù)庫(kù)實(shí)行監(jiān)視等。如：GRANT：授權(quán)。ROLLBACK[WORK]TO[SAVEPOINT]:回退到某一點(diǎn)?；貪L-—ROLLBACK；回滾命令使數(shù)據(jù)庫(kù)狀態(tài)回到上次最后提交的狀態(tài)。其格式為：SQL>ROLLBACK;COMMIT[WORK]：提交。在數(shù)據(jù)庫(kù)的插入、刪除和修改操作時(shí)，只有當(dāng)事務(wù)在提交到數(shù)據(jù)庫(kù)時(shí)才算完成。在事務(wù)提交前，只有操作數(shù)據(jù)庫(kù)的這個(gè)人才能有權(quán)看到所做的事情，別人只有在最后提交完成后才可以看到。提交數(shù)據(jù)有三種類型：顯式提交、隱式提交及自動(dòng)提交。下面分別說(shuō)明這三種類型。(1)顯式提交用COMMIT命令直接完成的提交為顯式提交。其格式為：SQL>COMMIT；(2)隱式提交用SQL命令間接完成的提交為隱式提交。這些命令是：ALTER,AUDIT,COMMENT,CONNECT,CREATE,DISCONNECT,DROP,EXIT,GRANT,NOAUDIT,QUIT,REVOKE,RENAMEo(3)自動(dòng)提交假設(shè)把AUTOCOMMIT設(shè)置為ON,那么在插入、修改、刪除語(yǔ)句執(zhí)行后，系統(tǒng)將自動(dòng)進(jìn)行提交，這就是自動(dòng)提交。其格式為：SQL>SETAUTOCOMMITON；參考文章：.htmIlike%和-的區(qū)別通配符的分類：%百分號(hào)通配符:表示任何字符出現(xiàn)任意次數(shù)(可以是0次).下劃線通配符：表示只能匹配單個(gè)字符，不能多也不能少，就是一個(gè)字符.Iike操作符：LIKE作用是指示mysql后面的搜索模式是利用通配符而不是直接相等匹配進(jìn)行比擬.注意：如果在使用like操作符時(shí)，后面的沒(méi)有使用通用匹配符效果是和二一致的，SELECT*FROMproductsWHEREd_nameIike'1000';只能匹配的結(jié)果為1000,而不能匹配像JetPack1000這樣的結(jié)果.%通配符使用：匹配以"yves"開(kāi)頭的記錄：（包括記錄“yves"）SELECTFROMproductsWHEREd_nameIike'yves%';匹配包含"yves”的記錄（包括記錄"yves"）SELECTFROMproductsWHEREd_nameIike'%yves%';匹配以"yves"結(jié)尾的記錄（包括記錄"yves",不包括記錄"yves",也就是yves后面有空格的記錄，這里需要注意）SELECT*FROMproductsWHEREd_nameIike'%yves';通配符使用:SELECTFROMproductsWHEREd_nameIike'_yves';匹配結(jié)果為：像"yyves”這樣記錄.SELECTFROMproductsWHEREd*nameIike'yves*';匹配結(jié)果為：像"yvesHe"這樣的記錄.（一個(gè)下劃線只能匹配一個(gè)字符，不能多也不能少）考前須知：注意大小寫(xiě)，在使用模糊匹配時(shí)，也就是匹配文本時(shí)，mysql是可能區(qū)分大小的，也可能是不區(qū)分大小寫(xiě)的，這個(gè)結(jié)果是取決于用戶對(duì)MySQL的配置方式.如果是區(qū)分大小寫(xiě)，那么像YvesHe這樣記錄是不能被"yves_"這樣的匹配條件匹配的.注意尾部空格，％yves"是不能匹配"heyves"這樣的記錄的.注意NULL,%通配符可以匹配任意字符，但是不能匹配NULL,也就是說(shuō)SELECT*FROMproductsWHEREd_nameIike'%;是匹配不到d_name為NULL的的記錄.技巧與建議：正如所見(jiàn)，MySQL的通配符很有用。但這種功能是有代價(jià)的：通配符搜索的處理一般要比前面討論的其他搜索所花時(shí)間更長(zhǎng)。這里給出一些使用通配符要記住的技巧。不要過(guò)度使用通配符。如果其他操作符能到達(dá)相同的目的，應(yīng)該使用其他操作符。在確實(shí)需要使用通配符時(shí)，除非絕對(duì)有必要，否那么不要把它們用在搜索模式的開(kāi)始處。把通配符置于搜索模式的開(kāi)始處，搜索起來(lái)是最慢的。仔細(xì)注意通配符的位置。如果放錯(cuò)地方，可能不會(huì)返回想要的數(shù).參考博文s://bI/uO11479200/articIe/detaiIs/78513632count(*)>count(1)>count(coIumn)的區(qū)別count(*)對(duì)行的數(shù)目進(jìn)行計(jì)算，包含NULLcount(coIumn)對(duì)特定的列的值具有的行數(shù)進(jìn)行計(jì)算，不包含NULL值。count()還有一中使用方式，count(1)這個(gè)用法和count(*)的結(jié)果是一樣的。.任何情況下SELECTCOUNT(*)FROMtabIename是最優(yōu)選擇；.盡量減少SELECTCOUNT(*)FROMtablenameWHERECOL='value'這種查詢；.杜絕SELECTCOUNT(COL)FROMtablenameWHEREC0L2='value'的出現(xiàn)。如果表沒(méi)有主鍵，那么count(1)比count(*)快。如果有主鍵，那么count(主鍵，聯(lián)合主鍵)比count(*)快。如果表只有一個(gè)字段,count(*)最快。count。)跟count(主鍵)一樣，只掃描主鍵。count(*)跟count(非主鍵)一樣，掃描整個(gè)表。明顯前者更快一些。.最左前綴原那么多列索引：ALTERTABLEpeopIeADDINDEXIname_fname_age(Iame,fname,age);為了提高搜索效率，我們需要考慮運(yùn)用多列索引，由于索引文件以B-Tree格式保存，所以我們不用掃描任何記錄，即可得到最終結(jié)果。注：在mysql中執(zhí)行查詢時(shí)，只能使用一個(gè)索引，如果我們?cè)贗name,fname,age上分別建索引,執(zhí)行查詢時(shí)，只能使用一個(gè)索引，mysqI會(huì)選擇一個(gè)最嚴(yán)格(獲得結(jié)果集記錄數(shù)最少)的索引。最左前綴原那么：顧名思義，就是最左優(yōu)先，上例中我們創(chuàng)立了Iname_fname_age多歹U索弓I,相當(dāng)于創(chuàng)立了(Iname)單列索弓I,(Iname,fname)組合索引以及(Iname,fname,age)組合索引。什么是索引？何為索引:數(shù)據(jù)庫(kù)索引，是數(shù)據(jù)庫(kù)管理系統(tǒng)中一個(gè)排序的數(shù)據(jù)結(jié)構(gòu)，索引的實(shí)現(xiàn)通常使用B樹(shù)及其變種B+樹(shù)。在數(shù)據(jù)之外，數(shù)據(jù)庫(kù)系統(tǒng)還維護(hù)著滿足特定查找算法的數(shù)據(jù)結(jié)構(gòu),這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用（指向）數(shù)據(jù)，這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)上實(shí)現(xiàn)高級(jí)查找算法。這種數(shù)據(jù)結(jié)構(gòu)，就是索引。索引的作用？它的優(yōu)點(diǎn)缺點(diǎn)是什么？索引作用：協(xié)助快速查詢、更新數(shù)據(jù)庫(kù)表中數(shù)據(jù)。為表設(shè)置索引要付出代價(jià)的：一是增加了數(shù)據(jù)庫(kù)的存儲(chǔ)空間二是在插入和修改數(shù)據(jù)時(shí)要花費(fèi)較多的時(shí)間（因?yàn)樗饕惨S之變動(dòng)）。索引的優(yōu)缺點(diǎn)？創(chuàng)立索引可以大大提高系統(tǒng)的性能（優(yōu)點(diǎn)）：.通過(guò)創(chuàng)立唯一性索引，可以保證數(shù)據(jù)庫(kù)表中每一行數(shù)據(jù)的唯一性。.可以大大加快數(shù)據(jù)的檢索速度，這也是創(chuàng)立索引的最主要的原因。.可以加速表和表之間的連接，特別是在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面特別有意義。.在使用分組和排序子句進(jìn)行數(shù)據(jù)檢索時(shí)，同樣可以顯著減少查詢中分組和排序的時(shí)間。.通過(guò)使用索引，可以在查詢的過(guò)程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能。增加索引也有許多不利的方面(缺點(diǎn))：.創(chuàng)立索引和維護(hù)索引要耗費(fèi)時(shí)間，這種時(shí)間隨著數(shù)據(jù)量的增加而增加。.索引需要占物理空間，除了數(shù)據(jù)表占數(shù)據(jù)空間之外，每一個(gè)索引還要占一定的物理空間，如果要建立聚簇索引，那么需要的空間就會(huì)更大。.當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時(shí)候，索引也要?jiǎng)討B(tài)的維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。.哪些列適合建立索引、哪些不適合建索引？索引是建立在數(shù)據(jù)庫(kù)表中的某些列的上面。在創(chuàng)立索引的時(shí)候，應(yīng)該考慮在哪些列上可以創(chuàng)立索引，在哪些列上不能創(chuàng)立索引。一般來(lái)說(shuō)，應(yīng)該在這些列上創(chuàng)立索引：(1)在經(jīng)常需要搜索的列上，可以加快搜索的速度；(2)在作為主鍵的列上，強(qiáng)制該列的唯一性和組織表中數(shù)據(jù)的排列結(jié)構(gòu)；(3)在經(jīng)常用在連接的列上，這些列主要是一些外鍵，可以加快連接的速度；(4)在經(jīng)常需要根據(jù)范圍進(jìn)行搜索的列上創(chuàng)立索引，因?yàn)樗饕呀?jīng)排序，其指定的范圍是連續(xù)的；(5)在經(jīng)常需要排序的列上創(chuàng)立索引，因?yàn)樗饕呀?jīng)排序，這樣查詢可以利用索引的排序，加快排序查詢時(shí)間；(6)在經(jīng)常使用在WHERE子句中的列上面創(chuàng)立索引，加快條件的判斷速度。對(duì)于有些列不應(yīng)該創(chuàng)立索引：(1)對(duì)于那些在查詢中很少使用或者參考的列不應(yīng)該創(chuàng)立索引。這是因?yàn)椋热贿@些列很少使用到，因此有索引或者無(wú)索引，并不能提高查詢速度。相反，由于增加了索引，反而降低了系統(tǒng)的維護(hù)速度和增大了空間需求。(2)對(duì)于那些只有很少數(shù)據(jù)值的列也不應(yīng)該增加索引。這是因?yàn)?，由于這些列的取值很少，例如人事表的性別列，在查詢的結(jié)果中，結(jié)果集的數(shù)據(jù)行占了表中數(shù)據(jù)行的很大比例，即需要在表中搜索的數(shù)據(jù)行的比例很大。增加索引，并不能明顯加快檢索速度。(3)對(duì)于那些定義為text,image和bit數(shù)據(jù)類型的列不應(yīng)該增加索引。這是因?yàn)?，這些列的數(shù)據(jù)量要么相當(dāng)大，要么取值很少。(4)當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時(shí)，不應(yīng)該創(chuàng)立索引。這是因?yàn)?，修改性能和檢索性能是互相矛盾的。當(dāng)增加索引時(shí)，會(huì)提高檢索性能，但是會(huì)降低修改性能。當(dāng)減少索弓I時(shí)，會(huì)提高修改性能，降低檢索性能。因此，當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時(shí)，不應(yīng)該創(chuàng)立索引。.什么樣的字段適合建索引如果表使用自增主鍵，那么每次插入新的記錄，記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置，當(dāng)一頁(yè)寫(xiě)滿，就會(huì)自動(dòng)開(kāi)辟一個(gè)新的頁(yè)如果使用非自增主鍵（如果身份證號(hào)或?qū)W號(hào)等），由于每次插入主鍵的值近似于隨機(jī)，因此每次新紀(jì)錄都要被插到現(xiàn)有索引頁(yè)得中間某個(gè)位置，此時(shí)MySQL不得不為了將新記錄插到合適位置而移動(dòng)數(shù)據(jù)，甚至目標(biāo)頁(yè)面可能已經(jīng)被回寫(xiě)到磁盤上而從緩存中清掉，此時(shí)又要從磁盤上讀回來(lái)，這增加了很多開(kāi)銷，同時(shí)頻繁的移動(dòng)、分頁(yè)操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)，后續(xù)不得不通過(guò)OPTIMIZETABLE來(lái)重建表并優(yōu)化填充頁(yè)面。.觸發(fā)器的作用？觸發(fā)器是一種特殊的存儲(chǔ)過(guò)程，主要是通過(guò)事件來(lái)觸發(fā)而被執(zhí)行的。它可以強(qiáng)化約束，來(lái)維護(hù)數(shù)據(jù)的完整性和一致性，可以跟蹤數(shù)據(jù)庫(kù)內(nèi)的操作從而不允許未經(jīng)許可的更新和變化。可以聯(lián)級(jí)運(yùn)算。如，某表上的觸發(fā)器上包含對(duì)另一個(gè)表的數(shù)據(jù)操作，而該操作又會(huì)導(dǎo)致該表觸發(fā)器被觸發(fā)。.什么是存儲(chǔ)過(guò)程？用什么來(lái)調(diào)用？存儲(chǔ)過(guò)程是一個(gè)預(yù)編譯的SQL語(yǔ)句，優(yōu)點(diǎn)是允許模塊化的設(shè)計(jì)，就是說(shuō)只需創(chuàng)立一次，以后在該程序中就可以調(diào)用屢次。如果某次操作需要執(zhí)行屢次SQL,使用存儲(chǔ)過(guò)程比單純SQL語(yǔ)句執(zhí)行要快。調(diào)用：1）可以用一個(gè)命令對(duì)象來(lái)調(diào)用存儲(chǔ)過(guò)程。2）可以供外部程序調(diào)用，比方：java程序。5,存儲(chǔ)過(guò)程的優(yōu)缺點(diǎn)？?jī)?yōu)點(diǎn):唯一、不為空、經(jīng)常被查詢的字段6.MySQLB+Tree索引和Hash索引的區(qū)別？Hash索引和B+樹(shù)索引的特點(diǎn)：Hash索引結(jié)構(gòu)的特殊性，其檢索效率非常高，索引的檢索可以一次定位；B+樹(shù)索引需要從根節(jié)點(diǎn)到枝節(jié)點(diǎn)，最后才能訪問(wèn)到頁(yè)節(jié)點(diǎn)這樣屢次的10訪問(wèn)；為什么不都用Hash索引而使用B+樹(shù)索引？Hash索引僅僅能滿足”="，"IN"和""查詢，不能使用范圍查詢，因?yàn)榻?jīng)過(guò)相應(yīng)的Hash算法處理之后的Hash值的大小關(guān)系，并不能保證和Hash運(yùn)算前完全一樣；Hash索引無(wú)法被用來(lái)防止數(shù)據(jù)的排序操作，因?yàn)镠ash值的大小關(guān)系并不一定和Hash運(yùn)算前的鍵值完全一樣；Hash索引不能利用局部索引鍵查詢，對(duì)于組合索引，Hash索引在計(jì)算Hash值的時(shí)候是組合索引鍵合并后再一起計(jì)算Hash值，而不是單獨(dú)計(jì)算Hash值，所以通過(guò)組合索引的前面一^個(gè)或幾個(gè)索引鍵進(jìn)行查詢的時(shí)候，Hash索引也無(wú)法被利用；Hash索引在任何時(shí)候都不能防止表掃描，由于不同索引鍵存在相同Hash值，所以即使取滿足某個(gè)Hash鍵值的數(shù)據(jù)的記錄條數(shù)，也無(wú)法從Hash索引中直接完成查詢，還是要回表查詢數(shù)據(jù)；Hash索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B+樹(shù)索引高。補(bǔ)充：.MySQL中,只有HEAP/ME只RY引擎才顯示支持Hash索引。.常用的InnoDB引擎中默認(rèn)使用的是B+樹(shù)索引，它會(huì)實(shí)時(shí)監(jiān)控表上索引的使用情況，如果認(rèn)為建立哈希索引可以提高查詢效率，那么自動(dòng)在內(nèi)存中的“自適應(yīng)哈希索引緩沖區(qū)”建立哈希索引（在InnoDB中默認(rèn)開(kāi)啟自適應(yīng)哈希索引），通過(guò)觀察搜索模式，MySQL會(huì)利用indexkey的前綴建立哈希索引，如果一個(gè)表幾乎大局部都在緩沖池中，那么建立一個(gè)哈希索引能夠加快等值查詢。B+樹(shù)索引和哈希索引的明顯區(qū)別是：.如果是等值查詢，那么哈希索引明顯有絕對(duì)優(yōu)勢(shì)，因?yàn)橹恍枰?jīng)過(guò)一次算法即可找到相應(yīng)的鍵值；當(dāng)然了，這個(gè)前提是，鍵值都是唯一的。如果鍵值不是唯一的，就需要先找到該鍵所在位置，然后再根據(jù)鏈表往后掃描，直到找到相應(yīng)的數(shù)據(jù)；.如果是范圍查詢檢索，這時(shí)候哈希索引就毫無(wú)用武之地了，因?yàn)樵仁怯行虻逆I值，經(jīng)過(guò)哈希算法后，有可能變成不連續(xù)的了，就沒(méi)辦法再利用索引完成范圍查詢檢索；同理，哈希索引沒(méi)方法利用索引完成排序，以及l(fā)ike'xxx%'這樣的局部模糊查詢（這種局部模糊查詢，其實(shí)本質(zhì)上也是范圍查詢）；.哈希索引也不支持多列聯(lián)合索引的最左匹配規(guī)那么；B+樹(shù)索引的關(guān)鍵字檢索效率比擬平均，不像B樹(shù)那樣波動(dòng)幅度大，在有大量重復(fù)鍵值情況下，哈希索引的效率也是極低的，因?yàn)榇嬖谒^的哈希碰撞問(wèn)題。7.在大多數(shù)場(chǎng)景下，都會(huì)有范圍查詢、排序、分組等查詢特征，用B+樹(shù)索引就可以了。B樹(shù)和B+樹(shù)的區(qū)另UB樹(shù)，每個(gè)節(jié)點(diǎn)都存儲(chǔ)key和data,所有節(jié)點(diǎn)組成這棵樹(shù)，并且葉子節(jié)點(diǎn)指針為nul,葉子結(jié)點(diǎn)不包含任何關(guān)鍵字信息。B+樹(shù)，所有的葉子結(jié)點(diǎn)中包含了全部關(guān)鍵字的信息，及指向含有這些關(guān)鍵字記錄的指針，且葉子結(jié)點(diǎn)本身依關(guān)鍵字的大小自小而大的順序鏈接，所有的非終端結(jié)點(diǎn)可以看成是索引局部，結(jié)點(diǎn)中僅含有其子樹(shù)根結(jié)點(diǎn)中最大（或最?。╆P(guān)鍵字。（而B(niǎo)樹(shù)的非終節(jié)點(diǎn)也包含需要查找的有效信息）8.為什么說(shuō)B+比B樹(shù)更適合實(shí)際應(yīng)用中操作系統(tǒng)的文件索引和數(shù)據(jù)庫(kù)索引？1.B+的磁盤讀寫(xiě)代價(jià)更低B+的內(nèi)部結(jié)點(diǎn)并沒(méi)有指向關(guān)鍵字具體信息的指針。因此其內(nèi)部結(jié)點(diǎn)相對(duì)B樹(shù)更小。如果把所有同一內(nèi)部結(jié)點(diǎn)的關(guān)鍵字存放在同一盤塊中，那么盤塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多。一次性讀入內(nèi)存中的需要查找的關(guān)鍵字也就越多。相對(duì)來(lái)說(shuō)I0讀寫(xiě)次數(shù)也就降低了。2.B+tree的查詢效率更加穩(wěn)定由于非終結(jié)點(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)。9.聚集索引和非聚集索引區(qū)別？聚合索引（cIusteredindex）:聚集索引表記錄的排列順序和索引的排列順序一致，所以查詢效率快，只要找到第一個(gè)索引值記錄，其余就連續(xù)性的記錄在物理也一樣連續(xù)存放。聚集索引對(duì)應(yīng)的缺點(diǎn)就是修改慢，因?yàn)闉榱吮ＷC表中記錄的物理和索引順序一致，在記錄插入的時(shí)候，會(huì)對(duì)數(shù)據(jù)頁(yè)重新排序。聚集索引類似于新華字典中用拼音去查找漢字，拼音檢索表于書(shū)記順序都是按照a~z排列的，就像相同的邏輯順序于物理順序一樣，當(dāng)你需要查找a,ai兩個(gè)讀音的字，或是想一次尋找多個(gè)傻(sha)的同音字時(shí)，也許向后翻幾頁(yè)，或緊接著下一行就得到結(jié)果了。非聚合索引(noneIusteredindex):非聚集索引指定了表中記錄的邏輯順序，但是記錄的物理和索引不一定一致，兩種索引都采用B+樹(shù)結(jié)構(gòu)，非聚集索引的葉子層并不和實(shí)際數(shù)據(jù)頁(yè)相重疊，而采用葉子層包含一個(gè)指向表中的記錄在數(shù)據(jù)頁(yè)中的指針?lè)绞?。非聚集索引層次多，不?huì)造成數(shù)據(jù)重排。非聚集索引類似在新華字典上通過(guò)偏旁部首來(lái)查詢漢字，檢索表也許是按照橫、豎、撇來(lái)排列的，但是由于正文中是a~z的拼音順序，所以就類似于邏輯地址于物理地址的不對(duì)應(yīng)。同時(shí)適用的情況就在于分組,大數(shù)目的不同值，頻繁更新的列中，這些情況即不適合聚集索引。根本區(qū)別：聚集索引和非聚集索引的根本區(qū)別是表記錄的排列順序和與索引的排列順序是否一致。.什么是事務(wù)？事務(wù)是對(duì)數(shù)據(jù)庫(kù)中一系列操作進(jìn)行統(tǒng)一的回滾或者提交的操作，主要用來(lái)保證數(shù)據(jù)的完整性和一致性。.事務(wù)四大特性(ACID)原子性、一致性、隔離性、持久性？原子性(Atomicity)：原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫(kù)，如果操作失敗那么不能對(duì)數(shù)據(jù)庫(kù)有任何影響。^性(Consistency):事務(wù)開(kāi)始前和結(jié)束后，數(shù)據(jù)庫(kù)的完整性約束沒(méi)有被破壞。比方A向B轉(zhuǎn)賬，不可能A扣了錢，B卻沒(méi)收到。隔離性(Isolation):隔離性是當(dāng)多個(gè)用戶并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，比方操作同一張表時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開(kāi)啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。同一時(shí)間，只允許一個(gè)事務(wù)請(qǐng)求同一數(shù)據(jù)，不同的事務(wù)之間彼此沒(méi)有任何干擾。比方A正在從一張銀行卡中取錢，在A取錢的過(guò)程結(jié)束前，B不能向這張卡轉(zhuǎn)賬。持久性(DurabiIity):持久性是指一個(gè)事務(wù)一旦被提交了，那么對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫(kù)系統(tǒng)遇到故障的情況下也不會(huì)喪失提交事務(wù)的操作。.事務(wù)的并發(fā)？事務(wù)隔離級(jí)別，每個(gè)級(jí)別會(huì)引發(fā)什么問(wèn)題，MySQL默認(rèn)是哪個(gè)級(jí)別？從理論上來(lái)說(shuō)，事務(wù)應(yīng)該彼此完全隔離，以防止并發(fā)事務(wù)所導(dǎo)致的問(wèn)題,然而，那樣會(huì)對(duì)性能產(chǎn)生極大的影響，因?yàn)槭聞?wù)必須按順序運(yùn)行，在實(shí)際開(kāi)發(fā)中，為了提升性能，事務(wù)會(huì)以較低的隔離級(jí)別運(yùn)行，事務(wù)的隔離級(jí)別可以通過(guò)隔離事務(wù)屬性指定。事務(wù)的并發(fā)問(wèn)題1、臟讀：事務(wù)A讀取了事務(wù)B更新的數(shù)據(jù)，然后B回滾操作，那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)2、不可重復(fù)讀：事務(wù)A屢次讀取同一數(shù)據(jù)，事務(wù)B在事務(wù)A多次讀取的過(guò)程中，對(duì)數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A屢次讀取同一數(shù)據(jù)時(shí)，結(jié)果因此本領(lǐng)務(wù)先后兩次讀到的數(shù)據(jù)結(jié)果會(huì)不一致。3、幻讀：幻讀解決了不重復(fù)讀，保證了同一個(gè)事務(wù)里，查詢的結(jié)果都是事務(wù)開(kāi)始時(shí)的狀態(tài)（一致性）。例如：事務(wù)T1對(duì)一個(gè)表中所有的行的某個(gè)數(shù)據(jù)項(xiàng)做了從“1”修改為“2”的操作這時(shí)事務(wù)T2又對(duì)這個(gè)表中插入了一行數(shù)據(jù)項(xiàng)，而這個(gè)數(shù)據(jù)項(xiàng)的數(shù)值還是為“1”并且提交給數(shù)據(jù)庫(kù)。而操作事務(wù)T1的用戶如果再查看剛剛修改的數(shù)據(jù)，會(huì)發(fā)現(xiàn)還有跟沒(méi)有修改一樣，其實(shí)這行是從事務(wù)T2中添加的，就好像產(chǎn)生幻覺(jué)一樣，這就是發(fā)生了幻讀。小結(jié)：不可重復(fù)讀的和幻讀很容易混淆，不可重復(fù)讀側(cè)重于修改，幻讀側(cè)重于新增或刪除。解決不可重復(fù)讀的問(wèn)題只需鎖住滿足條件的行,解決幻讀需要鎖表。事務(wù)的隔離級(jí)別讀未提交：另一個(gè)事務(wù)修改了數(shù)據(jù)，但尚未提交，而本領(lǐng)務(wù)中的SELECT會(huì)讀到這些未被提交的數(shù)據(jù)臟讀不可重復(fù)讀：事務(wù)A屢次讀取同一數(shù)據(jù)，事務(wù)B在事務(wù)A屢次讀取的過(guò)程中，對(duì)數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A屢次讀取同一數(shù)據(jù)時(shí)，結(jié)果因此本領(lǐng)務(wù)先后兩次讀到的數(shù)據(jù)結(jié)果會(huì)不一致?？芍貜?fù)讀：在同一個(gè)事務(wù)里，SELECT的結(jié)果是事務(wù)開(kāi)始時(shí)時(shí)間點(diǎn)的狀態(tài)，因此，同樣的SELECT操作讀到的結(jié)果會(huì)是一致的。但是，會(huì)有幻讀現(xiàn)象串行化：最高的隔離級(jí)別，在這個(gè)隔離級(jí)別下，不會(huì)產(chǎn)生任何異常。并發(fā)的事務(wù)，就像事務(wù)是在一個(gè)個(gè)按照順序執(zhí)行一樣特別注意：MySQL默認(rèn)的事務(wù)隔離級(jí)別為repeatabIe-readMySQL支持4中事務(wù)隔離級(jí)別.事務(wù)的隔離級(jí)別要得到底層數(shù)據(jù)庫(kù)引擎的支持，而不是應(yīng)用程序或者框架的支持.Oracle支持的2種事務(wù)隔離級(jí)別：READ_COMMITED,SERIALIZABLESQL規(guī)范所規(guī)定的標(biāo)準(zhǔn)，不同的數(shù)據(jù)庫(kù)具體的實(shí)現(xiàn)可能會(huì)有些差異MySQL中默認(rèn)事務(wù)隔離級(jí)別是“可重復(fù)讀”時(shí)并不會(huì)鎖住讀取到的行事務(wù)隔離級(jí)別：未提交讀時(shí)，寫(xiě)數(shù)據(jù)只會(huì)鎖住相應(yīng)的行。事務(wù)隔離級(jí)別為：可重復(fù)讀時(shí)，寫(xiě)數(shù)據(jù)會(huì)鎖住整張表。事務(wù)隔離級(jí)別為：串行化時(shí)，讀寫(xiě)數(shù)據(jù)都會(huì)鎖住整張表。隔離級(jí)別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對(duì)并發(fā)性能的影響也越大，魚(yú)和熊掌不可兼得啊。對(duì)于多數(shù)應(yīng)用程序，可以優(yōu)先考慮把數(shù)據(jù)庫(kù)系統(tǒng)的隔離級(jí)別設(shè)為ReadCommitted,它能夠防止臟讀取,而且具有較好的并發(fā)性能。盡管它會(huì)導(dǎo)致不可重復(fù)讀、幻讀這些并發(fā)問(wèn)題，在可能出現(xiàn)這類問(wèn)題的個(gè)別場(chǎng)合，可以由應(yīng)用程序采用悲觀鎖或樂(lè)觀鎖來(lái)控制。.事務(wù)傳播行為PROPAGATION_REQUIRED：如果當(dāng)前沒(méi)有事務(wù)，就創(chuàng)立一個(gè)新事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，該設(shè)置是最常用的設(shè)置。PROPAGATION_SUPPORTS:支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就以非事務(wù)執(zhí)行。PROPAGATION_MANDATORY：支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就拋出異常。PROPAGATION_REQUIRES_NEW:創(chuàng)立新事務(wù)，無(wú)論當(dāng)前存不存在事務(wù)，都創(chuàng)立新事務(wù)。PROPAGATION_NOT_SUPPORTED:以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。PROPAGATION_NEVER：以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，那么拋出異常。PROPAGATION_NESTED：如果當(dāng)前存在事務(wù)，那么在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒(méi)有事務(wù)，那么執(zhí)行與PROPAGATION_REQUIRED類似的操作。5.嵌套事務(wù)什么是嵌套事務(wù)？嵌套是子事務(wù)套在父事務(wù)中執(zhí)行，子事務(wù)是父事務(wù)的一局部，在進(jìn)入子事務(wù)之前，父事務(wù)建立一個(gè)回滾點(diǎn)，叫savepoint,然后執(zhí)行子事務(wù)，這個(gè)子事務(wù)的執(zhí)行也算是父事務(wù)的一局部，然后子事務(wù)執(zhí)行結(jié)束,父事務(wù)繼續(xù)執(zhí)行。重點(diǎn)就在于那個(gè)savepointo看幾個(gè)問(wèn)題就明了了：如果子事務(wù)回滾，會(huì)發(fā)生什么？父事務(wù)會(huì)回滾到進(jìn)入子事務(wù)前建立的savepoint,然后嘗試其他的事務(wù)或者其他的業(yè)務(wù)邏輯，父事務(wù)之前的操作不會(huì)受到影響，更不會(huì)自動(dòng)回滾。如果父事務(wù)回滾，會(huì)發(fā)生什么？父事務(wù)回滾，子事務(wù)也會(huì)跟著回滾！為什么呢，因?yàn)楦甘聞?wù)結(jié)束之前，子事務(wù)是不會(huì)提交的，我們說(shuō)子事務(wù)是父事務(wù)的一局部，正是這個(gè)道理。那么：事務(wù)的提交，是什么情況？是父事務(wù)先提交，然后子事務(wù)提交，還是子事務(wù)先提交，父事務(wù)再提交？答案是第二種情況，還是那句話，子事務(wù)是父事務(wù)的一局部，由父事務(wù)統(tǒng)一提交。參考文章：angxwl/article/detaiIs/511975601.MySQL常見(jiàn)的三種存儲(chǔ)引擎(InnoDB、MyISAM.MEMORY)的區(qū)別？?jī)煞N存儲(chǔ)引擎的大致區(qū)別表現(xiàn)在：InnoDB支持事務(wù)，MylSAM不支持，這一點(diǎn)是非常之重要。事務(wù)是一種高級(jí)的處理方式，如在一些列增刪改中只要哪個(gè)出錯(cuò)還可以回滾還原，而MylSAM就不可以了。MyISAM適合查詢以及插入為主的應(yīng)用。InnoDB適合頻繁修改以及涉及到平安性較高的應(yīng)用。InnoDB支持外鍵，MyISAM不支持。從MySQL5.5.5以后，InnoDB是默認(rèn)引擎。InnoDB不支持FULLTEXT類型的索引。InnoDB中不保存表的行數(shù)，如seIectcount()fromtabIe時(shí)，InnoDB需要掃描一遍整個(gè)表來(lái)計(jì)算有多少行，但是MyISAM只要簡(jiǎn)單的讀出保存好的行數(shù)即可。注意的是，當(dāng)count()語(yǔ)句包含where條件時(shí)MyISAM也需要掃描整個(gè)表。對(duì)于自增長(zhǎng)的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中可以和其他字段一起建立聯(lián)合索引。DELETEFROMtable時(shí)，InnoDB不會(huì)重新建立表，而是一行一行的刪除，效率非常慢。MylSAM那么會(huì)重建表。InnoDB支持行鎖(某些情況下還是鎖整表，如updatetabIeseta=1whereuserIike'%Iee%'oMySQL存儲(chǔ)引擎MyISAM與InnoDB如何選擇MySQL有多種存儲(chǔ)引擎，每種存儲(chǔ)引擎有各自的優(yōu)缺點(diǎn)，可以擇優(yōu)選擇使用：MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeIeyDB)、EXAMPLE>FEDERATED,ARCHIVE,CSV、BLACKHOLEo雖然MySQL里的存儲(chǔ)引擎不只是MyISAM與InnoDB這兩個(gè)，但常用的就是兩個(gè)。關(guān)于MySQL數(shù)據(jù)庫(kù)提供的兩種存儲(chǔ)引擎，MylSAM與InnoDB選擇使用：INNODB會(huì)支持一些關(guān)系數(shù)據(jù)庫(kù)的高級(jí)功能，如事務(wù)功能和行級(jí)鎖，MyISAM不支持。MylSAM的性能更優(yōu)，占用的存儲(chǔ)空間少，所以，選擇何種存儲(chǔ)引擎，視具體應(yīng)用而定。如果你的應(yīng)用程序一定要使用事務(wù)，毫無(wú)疑問(wèn)你要選擇INNODB引擎。但要注意，INNODB的行級(jí)鎖是有條件的。在where條件沒(méi)有使用主鍵時(shí)，照樣會(huì)鎖全表。比方DELETEFROMmytabIe這樣的刪除語(yǔ)句。如果你的應(yīng)用程序?qū)Σ樵冃阅芤筝^高，就要使用MylSAM了。MyISAM索引和數(shù)據(jù)是分開(kāi)的，而且其索引是壓縮的，可以更好地利用內(nèi)存。所以它的查詢性能明顯優(yōu)于INNODB。壓縮后的索引也能節(jié)約一些磁盤空間。MyISAM擁有全文索引的功能，這可以極大地優(yōu)化UKE查詢的效率。有人說(shuō)MylSAM只能用于小型應(yīng)用，其實(shí)這只是一種偏見(jiàn)。如果數(shù)據(jù)量比擬大，這是需要通過(guò)升級(jí)架構(gòu)來(lái)解決，比方分表分庫(kù)，而不是單純地依賴存儲(chǔ)引擎。現(xiàn)在一般都是選用innodb了，主要是MyISAM的全表鎖，讀寫(xiě)串行1）存儲(chǔ)過(guò)程是預(yù)編譯過(guò)的，執(zhí)行效率高。2）存儲(chǔ)過(guò)程的代碼直接存放于數(shù)據(jù)庫(kù)中，通過(guò)存儲(chǔ)過(guò)程名直接調(diào)用，減少網(wǎng)絡(luò)通訊。3）平安性高，執(zhí)行存儲(chǔ)過(guò)程需要有一定權(quán)限的用戶。4）存儲(chǔ)過(guò)程可以重復(fù)使用，可減少數(shù)據(jù)庫(kù)開(kāi)發(fā)人員的工作量。缺點(diǎn)：移植性差.存儲(chǔ)過(guò)程與函數(shù)的區(qū)別.什么叫視圖？游標(biāo)是什么？視圖：是一種虛擬的表，具有和物理表相同的功能?？梢詫?duì)視圖進(jìn)行增,改，查，操作，試圖通常是有一個(gè)表或者多個(gè)表的行或列的子集。對(duì)視圖的修改會(huì)影響基本表。它使得我們獲取數(shù)據(jù)更容易，相比多表查詢。游標(biāo)：是對(duì)查詢出來(lái)的結(jié)果集作為一個(gè)單元來(lái)有效的處理。游標(biāo)可以定在該單元中的特定行，從結(jié)果集的當(dāng)前行檢索一行或多行?？梢詫?duì)結(jié)果集當(dāng)前行做修改。一般不使用游標(biāo)，但是需要逐條處理數(shù)據(jù)的時(shí)候，游標(biāo)顯得十分重要。.視圖的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：1對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)，因?yàn)橐晥D可以有選擇性的選取數(shù)據(jù)庫(kù)里的一局部。問(wèn)題，并發(fā)效率鎖表，效率低，MylSAM對(duì)于讀寫(xiě)密集型應(yīng)用一般是不會(huì)去選用的。MEMORY存儲(chǔ)引擎MEMORY是MySQL中一類特殊的存儲(chǔ)引擎。它使用存儲(chǔ)在內(nèi)存中的內(nèi)容來(lái)創(chuàng)立表，而且數(shù)據(jù)全部放在內(nèi)存中。這些特性與前面的兩個(gè)很不同。每個(gè)基于MEMORY存儲(chǔ)引擎的表實(shí)際對(duì)應(yīng)一個(gè)磁盤文件。該文件的文件名與表名相同，類型為frm類型。該文件中只存儲(chǔ)表的結(jié)構(gòu)。而其數(shù)據(jù)文件，都是存儲(chǔ)在內(nèi)存中，這樣有利于數(shù)據(jù)的快速處理，提高整個(gè)表的效率。值得注意的是，服務(wù)器需要有足夠的內(nèi)存來(lái)維持MEMORY存儲(chǔ)引擎的表的使用。如果不需要了，可以釋放內(nèi)存，甚至刪除不需要的表。MEMORY默認(rèn)使用哈希索引。速度比使用B型樹(shù)索引快。當(dāng)然如果你想用B型樹(shù)索引，可以在創(chuàng)立索引時(shí)指定。注意，MEMORY用到的很少，因?yàn)樗前褦?shù)據(jù)存到內(nèi)存中，如果內(nèi)存出現(xiàn)異常就會(huì)影響數(shù)據(jù)。如果重啟或者關(guān)機(jī)，所有數(shù)據(jù)都會(huì)消失。因此，基于MEMORY的表的生命周期很短，一般是一次性的。3.MySQL的MylSAM與InnoDB兩種存儲(chǔ)引擎在，事務(wù)、鎖級(jí)別，各自的適用場(chǎng)景？事務(wù)處理上方面MyISAM:強(qiáng)調(diào)的是性能，每次查詢具有原子性，其執(zhí)行數(shù)度比InnoDB類型更快，但是不提供事務(wù)支持。InnoDB：提供事務(wù)支持事務(wù)，外部鍵等高級(jí)數(shù)據(jù)庫(kù)功能。具有事務(wù)(commit)>回滾(roIIback)和崩潰修復(fù)能力(crashrecoverycapabiIities)的事務(wù)平安(transaction-safe(ACIDcompIiant))型表。鎖級(jí)別MyISAM:只支持表級(jí)鎖，用戶在操作MyISAM表時(shí)，seIect,update,deIete,insert語(yǔ)句都會(huì)給表自動(dòng)加鎖，如果加鎖以后的表滿足insert并發(fā)的情況下，可以在表的尾部插入新的數(shù)據(jù)。InnoDB：支持事務(wù)和行級(jí)鎖，是innodb的最大特色。行鎖大幅度提高了多用戶并發(fā)操作的新能。但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會(huì)鎖全表的。關(guān)于存儲(chǔ)引擎MyISAM和InnoDB的其他參考資料如下：MySQL存儲(chǔ)引擎中的MyISAM和InnoDB區(qū)別詳解MySQL存儲(chǔ)引擎之MyISAM和Innodb總結(jié)性梳理1.查詢語(yǔ)句不同元素（where、jion、limit、groupbyhaving等等）執(zhí)行先后順序？1.查詢中用到的關(guān)鍵詞主要包含六個(gè)，并且他們的順序依次為seIect-from-where-groupby-having-orderby其中seIect和from是必須的，其他關(guān)鍵詞是可選的，這六個(gè)關(guān)鍵詞的執(zhí)行順序與sql語(yǔ)句的書(shū)寫(xiě)順序并不是一樣的，而是按照下面的順序來(lái)執(zhí)行from:需要從哪個(gè)數(shù)據(jù)表檢索數(shù)據(jù)where:過(guò)濾表中數(shù)據(jù)的條件groupby:如何將上面過(guò)濾出的數(shù)據(jù)分組having:對(duì)上面已經(jīng)分組的數(shù)據(jù)進(jìn)行過(guò)濾的條件seIect:查看結(jié)果集中的哪個(gè)列，或列的計(jì)算結(jié)果orderby:按照什么樣的順序來(lái)查看返回的數(shù)據(jù)from后面的表關(guān)聯(lián)，是自右向左解析而where條件的解析順序是自下而上的。也就是說(shuō)，在寫(xiě)SQL語(yǔ)句的時(shí)候，盡量把數(shù)據(jù)量小的表放在最右邊來(lái)進(jìn)行關(guān)聯(lián)（用小表去匹配大表），而把能篩選出小量數(shù)據(jù)的條件放在where語(yǔ)句的最左邊（用小表去匹配大表）其他參考資源：://cnbI/huminxxI/p/3149097.html使用explain優(yōu)化sqI和索引？對(duì)于復(fù)雜、效率低的sqI語(yǔ)句，我們通常是使用explainsqI來(lái)分析sql語(yǔ)句，這個(gè)語(yǔ)句可以打印出，語(yǔ)句的執(zhí)行。這樣方便我們分析，進(jìn)行優(yōu)化table:顯示這一行的數(shù)據(jù)是關(guān)于哪張表的type：這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref>range、index*口ALLaII:fuIItabIescan;MySQL將遍歷全表以找到匹配的行；index:indexscan;index和aII的區(qū)別在于index類型只遍歷索引；range:索引范圍掃描，對(duì)索引的掃描開(kāi)始于某一點(diǎn)，返回匹配值的行，常見(jiàn)與between,等查詢；ref:非唯一性索引掃描，返回匹配某個(gè)單獨(dú)值的所有行，常見(jiàn)于使用非唯一索引即唯一索引的非唯一前綴進(jìn)行查找；eq_ref:唯一性索引掃描，對(duì)于每個(gè)索引鍵，表中只有一條記錄與之匹配，常用于主鍵或者唯一索引掃描；const,system:當(dāng)MySQL對(duì)某查詢某局部進(jìn)行優(yōu)化，并轉(zhuǎn)為一個(gè)常量時(shí)，使用這些訪問(wèn)類型。如果將主鍵置于where列表中，MySQL就能將該查詢轉(zhuǎn)化為一個(gè)常量。possible_keys:顯示可能應(yīng)用在這張表中的索引。如果為空，沒(méi)有可能的索引?？梢詾橄嚓P(guān)的域從WHERE語(yǔ)句中選擇一個(gè)合適的語(yǔ)句key:實(shí)際使用的索引。如果為NULL,那么沒(méi)有使用索引。很少的情況下，MySQL會(huì)選擇優(yōu)化缺乏的索引。這種情況下，可以在SELECT語(yǔ)句中使用USEINDEX(indexname)來(lái)強(qiáng)制使用一個(gè)索引或者用IGNOREINDEX(indexname)來(lái)強(qiáng)制MySQL忽略索引key_len：使用的索引的長(zhǎng)度。在不損失精確性的情況下，長(zhǎng)度越短越好ref:顯示索引的哪一列被使用了，如果可能的話，是一個(gè)常數(shù)rows:MySQL認(rèn)為必須檢查的用來(lái)返回請(qǐng)求數(shù)據(jù)的行數(shù)Extra:關(guān)于MySQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Usingtemporary和UsingfiIesort,意思MySQL根本不能使用索引，結(jié)果是檢索會(huì)很慢。MySQL慢查詢?cè)趺唇鉀Q？sIow_query_log慢查詢開(kāi)啟狀態(tài)。sIow_query_log_fiIe慢查詢?nèi)罩敬娣诺奈恢?這個(gè)目錄需要MySQL的運(yùn)行帳號(hào)的可寫(xiě)權(quán)限，一般設(shè)置為MySQL的數(shù)據(jù)存放目錄）。Iong_query_time查詢超過(guò)多少秒才記錄。Lmysql都有什么鎖，死鎖判定原理和具體場(chǎng)景，死鎖怎么解決？MySQL有三種鎖的級(jí)別：頁(yè)級(jí)、表級(jí)、行級(jí)。表級(jí)鎖：開(kāi)銷小，加鎖快；不會(huì)出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。行級(jí)鎖：開(kāi)銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。頁(yè)面鎖：開(kāi)銷和加鎖時(shí)間界于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般什么情況下會(huì)造成死鎖？什么是死鎖？死鎖：是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過(guò)程中。因爭(zhēng)奪資源而造成的一種互相等待的現(xiàn)象，假設(shè)無(wú)外力作用，它們都將無(wú)法推進(jìn)下去。此時(shí)稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖，這些永遠(yuǎn)在互相等竺的進(jìn)程稱為死鎖進(jìn)程。表級(jí)鎖不會(huì)產(chǎn)生死鎖.所以解決死鎖主要還是針對(duì)于最常用的InnoDB。死鎖的關(guān)鍵在于：兩個(gè)（或以上）的Session加鎖的順序不一^致。那么對(duì)應(yīng)的解決死鎖問(wèn)題的關(guān)鍵就是：讓不同的session加鎖有次序。死鎖的解決方法？.查出的線程殺死kiIISELECTtrx_MySQL_thread_idFROMinformationschema.INNODBTRX；.設(shè)置鎖的超時(shí)時(shí)間Innodb行鎖的等待時(shí)間，單位秒?？稍跁?huì)話級(jí)別設(shè)置，RDS實(shí)例該參數(shù)的默認(rèn)值為50（秒）。生產(chǎn)環(huán)境不推薦使用過(guò)大的innodb_Iockwait_timeout參數(shù)值該參數(shù)支持在會(huì)話級(jí)別修改，方便應(yīng)用在會(huì)話級(jí)別單獨(dú)設(shè)置某些特殊操作的行鎖等待超時(shí)時(shí)間，如下：setinnodb_Iockwait_timeout=1000;一設(shè)置當(dāng)前會(huì)話Innodb行鎖等待超時(shí)時(shí)間，單位秒。.指定獲取鎖的順序.有哪些鎖（樂(lè)觀鎖悲觀鎖），select時(shí)怎么加排它鎖？悲觀鎖（PessimisticLock）:悲觀鎖特點(diǎn)：先獲取鎖，再進(jìn)行業(yè)務(wù)操作。即“悲觀”的認(rèn)為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進(jìn)行業(yè)務(wù)操作。通常所說(shuō)的“一鎖二查三更新”即指的是使用悲觀鎖。通常來(lái)講在數(shù)據(jù)庫(kù)上的悲觀鎖需要數(shù)據(jù)庫(kù)本身提供支持，即通過(guò)常用的seIectforupdate操作來(lái)實(shí)現(xiàn)悲觀鎖。當(dāng)數(shù)據(jù)庫(kù)執(zhí)行seIectforupdate時(shí)會(huì)獲取被seIect中的數(shù)據(jù)行的行鎖，因此其他并發(fā)執(zhí)行的selectforupdate如果試圖選中同一行那么會(huì)發(fā)生排斥（需要等待行鎖被釋放），因此到達(dá)鎖的效果。seIectforupdate獲取的行鎖會(huì)在當(dāng)前事務(wù)結(jié)束時(shí)自動(dòng)釋放，因此必須在事務(wù)中使用。補(bǔ)充：不同的數(shù)據(jù)庫(kù)對(duì)seIectforupdate的實(shí)現(xiàn)和支持都是有所區(qū)別的,oracIe支持seIectforupdatenowait,表示如果拿不到鎖立刻報(bào)錯(cuò)，而不是等待，MySQL就沒(méi)有nowait這個(gè)選項(xiàng)。MySQL還有個(gè)問(wèn)題是seIectforupdate語(yǔ)句執(zhí)行中所有掃描過(guò)的行都會(huì)被鎖上，這一點(diǎn)很容易造成問(wèn)題。因此如果在MySQL中用悲觀鎖務(wù)必要確定走了索引，而不是全表掃描。樂(lè)觀鎖(OptimisticLock)：.樂(lè)觀鎖，也叫樂(lè)觀并發(fā)控制，它假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會(huì)彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那局部數(shù)據(jù)。在提交數(shù)據(jù)更新之前，每個(gè)事務(wù)會(huì)先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒(méi)有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，那么當(dāng)前正在提交的事務(wù)會(huì)進(jìn)行回滾。.****樂(lè)觀鎖的特點(diǎn)先進(jìn)行業(yè)務(wù)操作，不到萬(wàn)不得已不去拿鎖。即“樂(lè)觀”的認(rèn)為拿鎖多半是會(huì)成功的，因此在進(jìn)行完業(yè)務(wù)操作需要實(shí)際更新數(shù)據(jù)的最后一步再去拿一下鎖就好。樂(lè)觀鎖在數(shù)據(jù)庫(kù)上的實(shí)現(xiàn)完全是邏輯的，不需要數(shù)據(jù)庫(kù)提供特殊的支持。.一般的做法是在需要鎖的數(shù)據(jù)上增加一個(gè)版本號(hào)，或者時(shí)間戳,實(shí)現(xiàn)方式舉例如下：樂(lè)觀鎖(給表加一個(gè)版本號(hào)字段)這個(gè)并不是樂(lè)觀鎖的定義，給表加版本號(hào)，是數(shù)據(jù)庫(kù)實(shí)現(xiàn)樂(lè)觀鎖的一種方式。SELECTdataASoId_data,versionASoIdversionFROM…；根據(jù)獲取的數(shù)據(jù)進(jìn)行業(yè)務(wù)操作，得到new_data和new_versionUPDATESETdata=new_data,version=new_versionWHEREversion=oId_versionif(updatedrow>0){//樂(lè)觀鎖獲取成功，操作完成}eIse{//樂(lè)觀鎖獲取失敗，回滾并重試1注意：樂(lè)觀鎖在不發(fā)生取鎖失敗的情況下開(kāi)銷比悲觀鎖小，但是一旦發(fā)生失敗回滾開(kāi)銷那么比擬大，因此適合用在取鎖失敗概率比擬小的場(chǎng)景，可以提升系統(tǒng)并發(fā)性能樂(lè)觀鎖還適用于一些比擬特殊的場(chǎng)景，例如在業(yè)務(wù)操作過(guò)程中無(wú)法和數(shù)據(jù)庫(kù)保持連接等悲觀鎖無(wú)法適用的地方?？偨Y(jié)：悲觀鎖和樂(lè)觀鎖是數(shù)據(jù)庫(kù)用來(lái)保證數(shù)據(jù)并發(fā)平安防止更新喪失的兩種方法，例子在select...forupdate前加個(gè)事務(wù)就可以防止更新丟失。悲觀鎖和樂(lè)觀鎖大局部場(chǎng)景下差異不大，一些獨(dú)特場(chǎng)景下有一些差別，一般我們可以從如下幾個(gè)方面來(lái)判斷。響應(yīng)速度：如果需要非常高的響應(yīng)速度，建議采用樂(lè)觀鎖方案，成功就執(zhí)行，不成功就失敗，不需要等待其他并發(fā)去釋放鎖?！瘺_突頻率：如果沖突頻率非常高，建議采用悲觀鎖，保證成功率，如果沖突頻率大，樂(lè)觀鎖會(huì)需要屢次重試才能成功，代價(jià)比擬大。重試代價(jià)：如果重試代價(jià)大，建議采用悲觀鎖。.數(shù)據(jù)庫(kù)的主從復(fù)制主從復(fù)制的幾種方式:同步復(fù)制:所謂的同步復(fù)制，意思是master的變化，必須等待sIaveT,sIave-2,...,sIave-n完成后才能返回。這樣，顯然不可取，也不是MySQL復(fù)制的默認(rèn)設(shè)置。比方，在WEB前端頁(yè)面上，用戶增加了條記錄，需要等待很長(zhǎng)時(shí)間。異步復(fù)制：如同AJAX請(qǐng)求一樣。master只需要完成自己的數(shù)據(jù)庫(kù)操作即可。至于slaves是否收到二進(jìn)制日志，是否完成操作，不用關(guān)心，MySQL的默認(rèn)設(shè)置。半同步復(fù)制：master只保證sIaves中的一個(gè)操作成功，就返回，其他slave不管。這個(gè)功能，是由google為MySQL引入的。.數(shù)據(jù)庫(kù)主從復(fù)制分析的7個(gè)問(wèn)題？問(wèn)題1:master的寫(xiě)操作，slaves被動(dòng)的進(jìn)行一■樣的操作，保持?jǐn)?shù)據(jù)一■致性，那么slave是否可以主動(dòng)的進(jìn)行寫(xiě)操作？假設(shè)sIave可以主動(dòng)的進(jìn)行寫(xiě)操作，sIave又無(wú)法通知master,這樣就導(dǎo)致了master和sIave數(shù)據(jù)不一致了。因此sIave不應(yīng)該進(jìn)行寫(xiě)操作，至少是slave上涉及到復(fù)制的數(shù)據(jù)庫(kù)不可以寫(xiě)。實(shí)際上，這里已經(jīng)揭示了讀寫(xiě)別離的概念。問(wèn)題2:主從復(fù)制中，可以有N個(gè)slave,可是這些slave又不能進(jìn)行寫(xiě)操作，要他們干嘛？實(shí)現(xiàn)數(shù)據(jù)備份：類似于高可用的功能，一■旦master掛了，可以讓slave頂上去，同時(shí)sIave提升為master。異地容災(zāi)：比方master在北京，地震掛了，那么在上海的slave還可以繼續(xù)。主要用于實(shí)現(xiàn)scaleout,分擔(dān)負(fù)載，可以將讀的任務(wù)分散到sIaves上?！竞芸赡艿那闆r是，一個(gè)系統(tǒng)的讀操作遠(yuǎn)遠(yuǎn)多于寫(xiě)操作，因此寫(xiě)操作發(fā)向master,讀操作發(fā)向sIaves進(jìn)行操作】問(wèn)題3:主從復(fù)制中有master,sIave1,sIave2,...等等這么多MySQL數(shù)據(jù)庫(kù)，那比方一個(gè)JAVAWEB應(yīng)用到底應(yīng)該連接哪個(gè)數(shù)據(jù)庫(kù)？我們?cè)趹?yīng)用程序中可以這樣，insert/deIete/update這些更新數(shù)據(jù)庫(kù)的操作，用connection(formaster)進(jìn)行操作，seIect用connection(forsiaves)進(jìn)行操作。那我們的應(yīng)用程序還要完成怎么從sIaves選擇一■個(gè)來(lái)執(zhí)行select,例如使用簡(jiǎn)單的輪循算法。這樣的話，相當(dāng)于應(yīng)用程序完成了SQL語(yǔ)句的路由，而且與MySQL的主從復(fù)制架構(gòu)非常關(guān)聯(lián)，一旦master掛了，某些slave掛了，那么應(yīng)用程序就要修改了。能不能讓?xiě)?yīng)用程序與MySQL的主從復(fù)制架構(gòu)沒(méi)有什么太多關(guān)系呢？找一個(gè)組件，applicationprogram只需要與它打交道，用它來(lái)完成MySQL的代理，實(shí)現(xiàn)SQL語(yǔ)句的路由。MySQLproxy并不負(fù)責(zé)，怎么從眾多的sIaves挑一^個(gè)？可以交給另一個(gè)組件(比方haproxy)來(lái)完成。這就是所謂的MySQLREADWRITESPLITE,MySQL的讀寫(xiě)別離。問(wèn)題4：如果MySQLproxy,direct,master?他們中的某些掛了怎么辦？2)用戶通過(guò)簡(jiǎn)單的查詢可以從復(fù)雜查詢中得到結(jié)果。3)維護(hù)數(shù)據(jù)的獨(dú)立性，試圖可從多個(gè)表檢索數(shù)據(jù)。4)對(duì)于相同的數(shù)據(jù)可產(chǎn)生不同的視圖。缺點(diǎn)：性能：查詢視圖時(shí)，必須把視圖的查詢轉(zhuǎn)化成對(duì)基本表的查詢，如果這個(gè)視圖是由一個(gè)復(fù)雜的多表查詢所定義，那么，那么就無(wú)法更改數(shù)據(jù)9.drop、truncate、delete區(qū)另最基本：drop直接刪掉表。truncate刪除表中數(shù)據(jù)，再插入時(shí)自增長(zhǎng)id又從1開(kāi)始。deIete刪除表中數(shù)據(jù)，可以加where字句。(1)DELETE語(yǔ)句執(zhí)行刪除的過(guò)程是每次從表中刪除一行，并且同時(shí)將該行的刪除操作作為事務(wù)記錄在日志中保存以便進(jìn)行進(jìn)行回滾操作。TRUNCATETABLE那么一次性地從表中刪除所有的數(shù)據(jù)并不把單獨(dú)的刪除操作記錄記入日志保存，刪除行是不能恢復(fù)的。并且在刪除的過(guò)程中不會(huì)激活與表有關(guān)的刪除觸發(fā)器。執(zhí)行速度快。(2)表和索引所占空間。當(dāng)表被TRUNCATE后，這個(gè)表和索引所占用的空間會(huì)恢復(fù)到初始大小，而DELETE操作不會(huì)減少表或索引所占用的空間。drop語(yǔ)句將表所占用的空間全釋放掉。一^殳而言，drop>truncate>deIete應(yīng)用范圍。TRUNCATE只能對(duì)TABLE；DELETE可以是table和view總統(tǒng)一般都會(huì)弄個(gè)副總統(tǒng)，以防不測(cè)。同樣的，可以給這些關(guān)鍵的節(jié)點(diǎn)來(lái)個(gè)備份。問(wèn)題5:當(dāng)master的二進(jìn)制日志每產(chǎn)生一^個(gè)事件，都需要發(fā)往slave,如果我們有N個(gè)slave,那是發(fā)N次，還是只發(fā)一次？如果只發(fā)一次，發(fā)給了sIave-1,那slave-2,slave-3,...它們?cè)趺崔k？顯然，應(yīng)該發(fā)N次。實(shí)際上，在MySQLmaster內(nèi)部，維護(hù)N個(gè)線程，每一個(gè)線程負(fù)責(zé)將二進(jìn)制日志文件發(fā)往對(duì)應(yīng)的sIave。master?既要負(fù)責(zé)寫(xiě)操作，還的維護(hù)N個(gè)線程，負(fù)擔(dān)會(huì)很重。可以這樣，slave-1是master的從，slave-1又是sIave-2,sIave-3,...的主，同時(shí)sIave-1不再負(fù)責(zé)select。sIave-1將master的復(fù)制線程的負(fù)擔(dān)，轉(zhuǎn)移到自己的身上。這就是所謂的多級(jí)復(fù)制的概念。問(wèn)題6:當(dāng)一個(gè)seIect發(fā)往MySQLproxy,可能這次由sIave-2響應(yīng)，下次由slave-3響應(yīng)，這樣的話，就無(wú)法利用查詢緩存了。應(yīng)該找一個(gè)共享式的緩存，比方memcache來(lái)解決。將sIave-2,sIave_3,...這些查詢的結(jié)果都緩存至mamcache中。問(wèn)題7:隨著應(yīng)用的日益增長(zhǎng)，讀操作很多，我們可以擴(kuò)展slave,但是如果master■滿足不了寫(xiě)操作了，怎么辦呢？scaleon?更好的服務(wù)器？沒(méi)有最好的，只有更好的，太貴了。。。scaleout?主從復(fù)制架構(gòu)已經(jīng)滿足不了。可以分庫(kù)【垂直拆分】，分表【水平拆分】。.mysql高并發(fā)環(huán)境解決方案？MySQL高并發(fā)環(huán)境解決方案：分庫(kù)分表分布式增加二級(jí)緩存。。。。。需求分析：互聯(lián)網(wǎng)單位每天大量數(shù)據(jù)讀取，寫(xiě)入，并發(fā)性高?，F(xiàn)有解決方式：水平分庫(kù)分表，由單點(diǎn)分布到多點(diǎn)數(shù)據(jù)庫(kù)中，從而降低單點(diǎn)數(shù)據(jù)庫(kù)壓力。集群方案：解決DB宕機(jī)帶來(lái)的單點(diǎn)DB不能訪問(wèn)問(wèn)題。讀寫(xiě)別離策略：極大限度提高了應(yīng)用中Read數(shù)據(jù)的速度和并發(fā)量。無(wú)法解決高寫(xiě)入壓力。.數(shù)據(jù)庫(kù)崩潰時(shí)事務(wù)的恢復(fù)機(jī)制（REDO日志和UNDO日志）？轉(zhuǎn)載：MySQLREDO日志和UNDO日志UndoLog:UndoLog是為了實(shí)現(xiàn)事務(wù)的原子性，在MySQL數(shù)據(jù)庫(kù)InnoDB存儲(chǔ)引擎中，還用了UndoLog來(lái)實(shí)現(xiàn)多版本并發(fā)控制（簡(jiǎn)稱：MVCC）。事務(wù)的原子性（Atomicity）事務(wù)中的所有操作，要么全部完成，要么不做任何操作，不能只做局部操作。如果在執(zhí)行的過(guò)程中發(fā)生了錯(cuò)誤，要回滾（RolIback）到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)。原理UndoLog的原理很簡(jiǎn)單，為了滿足事務(wù)的原子性，在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到一個(gè)地方（這個(gè)存儲(chǔ)數(shù)據(jù)備份的地方稱為UndoLog）o然后進(jìn)行數(shù)據(jù)的修改。如果出現(xiàn)了錯(cuò)誤或者用戶執(zhí)行了ROLLBACK語(yǔ)句，系統(tǒng)可以利用UndoLog中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開(kāi)始之前的狀態(tài)。之所以能同時(shí)保證原子性和持久化，是因?yàn)橐韵绿攸c(diǎn)：更新數(shù)據(jù)前記錄UndoIogo為了保證持久性，必須將數(shù)據(jù)在事務(wù)提交前寫(xiě)到磁盤。只要事務(wù)成功提交，數(shù)據(jù)必然已經(jīng)持久化。Undolog必須先于數(shù)據(jù)持久化到磁盤。如果在G,H之間系統(tǒng)崩潰,undolog是完整的，可以用來(lái)回滾事務(wù)。如果在A-F之間系統(tǒng)崩潰，因?yàn)閿?shù)據(jù)沒(méi)有持久化到磁盤。所以磁盤上的數(shù)據(jù)還是保持在事務(wù)開(kāi)始前的狀態(tài)。缺陷：每個(gè)事務(wù)提交前將數(shù)據(jù)和UndoLog寫(xiě)入磁盤，這樣會(huì)導(dǎo)致大量的磁盤10,因此性能很低。如果能夠?qū)?shù)據(jù)緩存一段時(shí)間，就能減少10提高性能。但是這樣就會(huì)喪失事務(wù)的持久性。因此引入了另外一種機(jī)制來(lái)實(shí)現(xiàn)持久化，即RedoLogoRedoLog:原理和UndoLog相反，RedoLog記錄的是新數(shù)據(jù)的備份。在事務(wù)提交前，只要將RedoLog持久化即可，不需要將數(shù)據(jù)持久化。當(dāng)系統(tǒng)崩潰時(shí)，雖然數(shù)據(jù)沒(méi)有持久化，但是RedoLog已經(jīng)持久化。系統(tǒng)可以根據(jù)RedoLog的內(nèi)容，將所有數(shù)據(jù)恢復(fù)到最新的狀態(tài)。TRUNCATE和DELETE只刪除數(shù)據(jù)，而DROP那么刪除整個(gè)表(結(jié)構(gòu)和數(shù)據(jù))。truncate與不帶where的deIete:只刪除數(shù)據(jù)，而不刪除表的結(jié)構(gòu)(定義)drop語(yǔ)句將刪除表的結(jié)構(gòu)被依賴的約束(constrain),觸發(fā)器(trigger)索引(index);依賴于該表的存儲(chǔ)過(guò)程/函數(shù)將被保存，但其狀態(tài)會(huì)變?yōu)椋篿nvaIidodeIete語(yǔ)句為DML(datamaintainLanguage),這個(gè)操作會(huì)被放至UrolIbacksegment中，事務(wù)提交后才生效。如果有相應(yīng)的tigger,執(zhí)行的時(shí)候?qū)⒈挥|發(fā)。truncate、drop是DLL(datadefineIanguage),操作立即生效，原數(shù)據(jù)不放到rolIbacksegment中，不能回滾。在沒(méi)有備份情況下，謹(jǐn)慎使用drop與truncate。要?jiǎng)h除局部數(shù)據(jù)行采用delete且注意結(jié)合where來(lái)約束影響范圍。回滾段要足夠大。要?jiǎng)h除表用drop；假設(shè)想保存表而將表中數(shù)據(jù)刪除，如果于事務(wù)無(wú)關(guān)，用truncate即可實(shí)現(xiàn)。如果和事務(wù)有關(guān)，或老師想觸發(fā)trigger,還是用deIete。TruncatetabIe表名速度快，而且效率高，因?yàn)椋?？truncatetable在功能上與不帶WHERE子句的DELETE語(yǔ)句相同：二者均刪除表中的全部行。但TRUNCATETABLE比DELETE速度快，且使用的系統(tǒng)和事務(wù)日志資源少。DELETE語(yǔ)句每次刪除一行，并在事務(wù)日志中為