1.mySQL和Oracle的區(qū)別

????對事務(wù)的提交，MySQL自動(dòng)提交，Oralce手動(dòng)提交舟误；分頁查詢，Oracle需要用到偽列ROWNUM和嵌套查詢姻乓；自動(dòng)增長數(shù)據(jù)類型的處理嵌溢；日期字段的處理眯牧，MYSQL日期字段分DATE和TIME兩種，ORACLE日期字段只有DATE赖草；Oracle是大型數(shù)據(jù)庫学少，mySQL是中小型數(shù)據(jù)庫；單引號的處理秧骑，Oracle只能用單引號包起字符串版确；MySQL的分區(qū)表還不太成熟穩(wěn)定，Oracle的分區(qū)表和分區(qū)索引功能很成熟乎折；事務(wù)的隔離級別绒疗，? ?MySQL是read commited（可重復(fù)讀）的隔離級別，而Oracle是repeatable read（讀已提交）的隔離級別骂澄。

Oralce特有的函數(shù)：length吓蘑、lengthb、INSTR(源字符串, 目標(biāo)字符串, 起始位置)坟冲、substr( string, start_position, [ length ] )磨镶、trim(LTRIM/RTRIM)函數(shù)、lower/upper函數(shù)健提、nvl函數(shù)

2.數(shù)據(jù)庫事務(wù)的隔離級別

讀未提交(read uncommitted)--臟讀琳猫、讀已提交(read committed)--不可重復(fù)讀、可重復(fù)讀(Repeatable read)--幻讀私痹、可串行化(Serializable)脐嫂。oracle默認(rèn)的隔離級別為讀已提交，mysql的默認(rèn)隔離級別為可重復(fù)讀侄榴。

臟讀：讀取未提交數(shù)據(jù)雹锣。指當(dāng)一個(gè)事務(wù)正在訪問數(shù)據(jù)网沾，并且對數(shù)據(jù)進(jìn)行了修改癞蚕，而這種修改還沒有提交到數(shù)據(jù)庫中，這時(shí)辉哥，另外一個(gè)事務(wù)也訪問這個(gè)數(shù)據(jù)桦山，然后使用了這個(gè)數(shù)據(jù)

不可重復(fù)讀：前后多次讀取，數(shù)據(jù)內(nèi)容不一致醋旦。是指在一個(gè)事務(wù)內(nèi)恒水，多次讀同一數(shù)據(jù)。在這個(gè)事務(wù)還沒有結(jié)束時(shí)饲齐，另外一個(gè)事務(wù)也訪問該同一數(shù)據(jù)钉凌。那么，在第一個(gè)事務(wù)中的兩次讀數(shù)據(jù)之間捂人，由于第二個(gè)事務(wù)的修改御雕，那么第一個(gè)事務(wù)兩次讀到的的數(shù)據(jù)可能是不一樣的矢沿。這樣在一個(gè)事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的，因此稱為是不可重復(fù)讀酸纲。

幻讀：前后多次讀取捣鲸，數(shù)據(jù)總量不一致。是指當(dāng)事務(wù)不是獨(dú)立執(zhí)行時(shí)發(fā)生的一種現(xiàn)象闽坡，例如第一個(gè)事務(wù)對一個(gè)表中的數(shù)據(jù)進(jìn)行了修改栽惶，這種修改涉及到表中的全部數(shù)據(jù)行。同時(shí)疾嗅，第二個(gè)事務(wù)也修改這個(gè)表中的數(shù)據(jù)外厂，這種修改是向表中插入一行新數(shù)據(jù)。那么代承，以后就會(huì)發(fā)生操作第一個(gè)事務(wù)的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行酣衷，就好象發(fā)生了幻覺一樣。

3.mySQL引擎

????Innodb引擎提供了對數(shù)據(jù)庫ACID事務(wù)的支持次泽，并且實(shí)現(xiàn)了SQL標(biāo)準(zhǔn)的四種隔離級別穿仪。該引擎還提供了行級鎖和外鍵約束，MySQL運(yùn)行時(shí)Innodb會(huì)在內(nèi)存中建立緩沖池意荤，用于緩沖數(shù)據(jù)和索引啊片，5.5之后默認(rèn)Innodb。myISAM沒有提供對數(shù)據(jù)庫事務(wù)的支持玖像，也不支持行級鎖和外鍵紫谷，因此當(dāng)INSERT(插入)或UPDATE(更新)數(shù)據(jù)時(shí)即寫操作需要鎖定整個(gè)表，效率便會(huì)低一些捐寥。

1) InnoDB支持事務(wù)和外鍵笤昨，myISAM不支持；

2) InnoDB支持行鎖握恳，MyISAM不支持瞒窒；

3) InnoDB是聚集索引，使用B+Tree作為索引結(jié)構(gòu)乡洼，必須要有主鍵崇裁，MyISAM是非聚集索引，也是使用B+Tree作為索引結(jié)構(gòu)束昵；

4)?InnoDB不保存表的具體行數(shù)拔稳，執(zhí)行select count(*) from table時(shí)需要全表掃描，而MyISAM用一個(gè)變量保存了整個(gè)表的行數(shù)锹雏，執(zhí)行上述語句時(shí)只需要讀出該變量即可巴比，速度很快（注意不能加有任何WHERE條件）；

5)?Innodb不支持全文索引，而MyISAM支持全文索引轻绞，在涉及全文索引領(lǐng)域的查詢效率上MyISAM速度更快高腰耙；

6)?Innodb存儲(chǔ)文件有frm、ibd铲球，frm是表定義文件挺庞，ibd是數(shù)據(jù)文件；而Myisam是frm稼病、MYD选侨、MYI，frm是表定義文件然走，myd是數(shù)據(jù)文件援制，myi是索引文件

7)?InnoDB不支持FULLTEXT類型的索引；

8) InnoDB適用insert和update的操作比較多的應(yīng)用芍瑞，myISAM查詢速度很快晨仑，適合頻繁查詢及涉及安全性較高的應(yīng)用；

9) 刪除表時(shí)拆檬，InnoDB逐行刪除洪己，myISAM重建表；

4.char竟贯、varchar 答捕、nchar和nvarchar的區(qū)別

? ? char長度固定，存儲(chǔ)ANSI字符屑那，長度0~255拱镐，自動(dòng)用空格填充到設(shè)定長度；varchar存儲(chǔ)長數(shù)據(jù)持际，存儲(chǔ)ANSI字符沃琅，存儲(chǔ)效率沒有char高，必須在括號里定義長度蜘欲，可以有默認(rèn)值益眉。保存數(shù)據(jù)的時(shí)候，不進(jìn)行空格自動(dòng)填充芒填，而且如果數(shù)據(jù)存在空格時(shí)呜叫，當(dāng)值保存和檢索時(shí)尾部的空格仍會(huì)保留，varchar類型的實(shí)際長度是它的值的實(shí)際長度+1殿衰，這一個(gè)字節(jié)用于保存實(shí)際使用了多大的長度。

varchar 長度可變盛泡，存儲(chǔ)ANSI字符闷祥，根據(jù)數(shù)據(jù)長度自動(dòng)變化。存儲(chǔ)變長數(shù)據(jù)，但存儲(chǔ)效率沒有CHAR高凯砍；nvarchar長度可變箱硕，存儲(chǔ)Unicode字符，根據(jù)數(shù)據(jù)長度自動(dòng)變化

5.mySQl索引及優(yōu)化

????索引是關(guān)系型數(shù)據(jù)庫中給數(shù)據(jù)庫表中一列或者多列的值排序后的儲(chǔ)存結(jié)構(gòu),SQL的主流索引結(jié)構(gòu)有B+樹以及Hash結(jié)構(gòu),聚集索引以及非聚集索引用的是B+樹索引悟衩。創(chuàng)建索引時(shí)剧罩，你需要確保該索引是應(yīng)用在 SQL 查詢語句的條件(一般作為 WHERE 子句的條件)，實(shí)際上座泳，索引也是一張表惠昔，該表保存了主鍵與索引字段，并指向?qū)嶓w表的記錄挑势。更新表時(shí)镇防，MySQL不僅要保存數(shù)據(jù)，還要保存一下索引文件潮饱。?MySql索引類型有:唯一索引来氧、主鍵(聚集)索引、非聚集索引香拉、全文索引啦扬。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CREATE INDEX indexName ON table(username(length))? ????? ?ALTER table tableName ADD INDEX indexName(columnName)

使用：?建立索引的目的就是幫助查詢,如果查尋用不到則索引就沒有必要建立；如果表是經(jīng)常需要更新的也不適合做索引 凫碌。頻繁更新會(huì)導(dǎo)致索引也會(huì)頻繁更新考传，降低寫的效率；? ?給一個(gè)字段創(chuàng)建了索引的話证鸥，而這個(gè)字段要進(jìn)行l(wèi)ike模糊查詢的話僚楞，那么這個(gè)值左邊不可以有%；如果數(shù)據(jù)表過大(5w以上)則有些字段(字符型長度超過(40))不適合作為索引枉层，使用索引時(shí)會(huì)先過一遍索引泉褐，再過一遍數(shù)據(jù)。

索引失效：

1.如果條件中有or鸟蜡，即使其中有條件帶索引也不會(huì)使用(這也是為什么盡量少用or的原因)

注意：要想使用or膜赃，又想讓索引生效，只能將or條件中的每個(gè)列都加上索引

2.對于多列索引揉忘，不是使用的第一部分跳座，則不會(huì)使用索引

3.like查詢已 '%...'開頭，以'xxx%'結(jié)尾會(huì)繼續(xù)使用索引

4.如果列類型是字符串泣矛，那一定要在條件中將數(shù)據(jù)使用引號引用起來,否則不使用索引

5.where語句中使用 <>和 != 疲眷，where語句中使用Not In ，where語句中對字段表達(dá)式操作

6.如果mysql估計(jì)使用全表掃描要比使用索引快,則不使用索引

查看索引的使用情況：

show status like ‘Handler_read%’;

索引分類

1.普通索引????????index :加速查找? ? ? ?

2.唯一索引? ? ? ? 主鍵索引：primary key ：加速查找+約束（不為空且唯一）? ? ? 唯一索引：unique：加速查找+約束 （唯一）

3.聯(lián)合索引? ? ? ? ?primary key(id,name):聯(lián)合主鍵索引? ? ? ? unique(id,name):聯(lián)合唯一索引? ? ? ? ? index(id,name):聯(lián)合普通索引?

?4.全文索引? ? ? ? ?fulltext :用于搜索很長一篇文章的時(shí)候您朽，效果最好狂丝。

前綴索引：使用字符串的前幾個(gè)字符作為索引，選擇足夠長的前綴以保證較高的選擇性，同時(shí)又不能太長几颜，前綴索引進(jìn)行ORDER BY和GROUP BY倍试，也無法用來進(jìn)行覆蓋掃描。

全列選擇性? ? SELECTCOUNT(DISTINCTcolumn_name)/COUNT(*) FROM table_name;?

測試某一長度前綴的選擇性? ? SELECT COUNT(DISTINCT LEFT(column_name, prefix_length)) / COUNT(*)FROMtable_name;

索引覆蓋：如果一個(gè)索引覆蓋（包含）了所有需要查詢的字段的值蛋哭，這個(gè)索引就是覆蓋索引县习。因?yàn)樗饕幸呀?jīng)包含了要查詢的字段的值，因此查詢的時(shí)候直接返回索引中的字段值就可以了谆趾，不需要再到表中查詢躁愿，避免了對主鍵索引的二次查詢，也就提高了查詢的效率棺妓。

回表：索引執(zhí)行順序攘已，先搜索普通索引樹，找到符合條件的葉子節(jié)點(diǎn)（主鍵）怜跑，然后去聚簇索引拿到對應(yīng)的行數(shù)據(jù)样勃。

6.聚集索引和非聚集索引

聚集索引：數(shù)據(jù)行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個(gè)表中只能擁有一個(gè)聚集索引性芬。? 數(shù)據(jù)庫在創(chuàng)建主鍵同時(shí)峡眶，會(huì)自動(dòng)建立一個(gè)唯一索引。如果這個(gè)表之前沒有聚集索引植锉，同時(shí)建立主鍵時(shí)候沒有強(qiáng)制指定使用非聚集索引辫樱，則建立主鍵時(shí)候，同時(shí)建立一個(gè)唯一的聚集索引俊庇。

非聚合索引 ：該索引中索引的邏輯順序與磁盤上行的物理存儲(chǔ)順序不同狮暑，一個(gè)表中可以擁有多個(gè)非聚集索引。

7.慢查詢

MySQL會(huì)記錄下查詢超過指定時(shí)間的語句辉饱，我們將超過指定時(shí)間的SQL語句查詢稱為慢查詢搬男，都記在慢查詢?nèi)罩纠铩? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

查看慢查詢配置??show variables like “%slow%”?；? ? ?

查看慢查詢??show status like 'slow_queries';? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

查詢慢查詢時(shí)間? ?show variables like 'long_query_time';??

設(shè)置慢查詢時(shí)間彭沼，當(dāng)SQL語句執(zhí)行時(shí)間超過此數(shù)值時(shí)缔逛，就會(huì)被記錄到日志中? ? ?set long_query_time = 0.5;

8.悲觀鎖/樂觀鎖

樂觀鎖：總是假設(shè)最好的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改姓惑，所以不會(huì)上鎖褐奴，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)，可以使用版本號機(jī)制和CAS算法實(shí)現(xiàn)于毙。樂觀鎖適用于多讀的應(yīng)用類型敦冬，這樣可以提高吞吐量。

樂觀鎖每次在執(zhí)行數(shù)據(jù)的修改操作時(shí)望众，都會(huì)帶上一個(gè)版本號匪补，一旦版本號和數(shù)據(jù)的版本號一致就可以執(zhí)行修改操作并對版本號執(zhí)行+1操作伞辛，否則就執(zhí)行失敗烂翰。因?yàn)槊看尾僮鞯陌姹咎柖紩?huì)隨之增加夯缺，所以不會(huì)出現(xiàn)ABA問題，因?yàn)榘姹咎栔粫?huì)增加不會(huì)減少甘耿。

悲觀鎖：總是假設(shè)最壞的情況踊兜，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖佳恬，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)阻塞直到它拿到鎖（共享資源每次只給一個(gè)線程使用捏境，其它線程阻塞，用完后再把資源轉(zhuǎn)讓給其它線程）毁葱。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制垫言，比如行鎖，表鎖等倾剿，讀鎖筷频，寫鎖等，都是在做操作之前先上鎖前痘。

要使用悲觀鎖凛捏，我們必須關(guān)閉MySQL數(shù)據(jù)庫的自動(dòng)提交屬性。因?yàn)镸ySQL默認(rèn)使用autocommit模式芹缔，也就是說坯癣，當(dāng)我們執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交最欠。（sql語句：set autocommit=0）

在樂觀鎖與悲觀鎖的選擇上面示罗，主要看下兩者的區(qū)別以及適用場景

樂觀鎖并未真正加鎖，效率高芝硬。一旦鎖的粒度掌握不好蚜点，更新失敗的概率就會(huì)比較高，容易發(fā)生業(yè)務(wù)失敗吵取。

悲觀鎖依賴數(shù)據(jù)庫鎖禽额，效率低。更新失敗的概率比較低皮官。

9.數(shù)據(jù)庫分表 / 分庫

垂直（縱向）切分：垂直切分常見有垂直分庫和垂直分表兩種脯倒，垂直分庫就是根據(jù)業(yè)務(wù)耦合性，將關(guān)聯(lián)度低的不同表存儲(chǔ)在不同的數(shù)據(jù)庫捺氢。做法與大系統(tǒng)拆分為多個(gè)小系統(tǒng)類似藻丢，按業(yè)務(wù)分類進(jìn)行獨(dú)立劃分。與"微服務(wù)治理"的做法相似摄乒，每個(gè)微服務(wù)使用單獨(dú)的一個(gè)數(shù)據(jù)庫悠反。垂直分表是基于數(shù)據(jù)庫中的"列"進(jìn)行残黑，某個(gè)表字段較多，可以新建一張擴(kuò)展表斋否，將不經(jīng)常用或字段長度較大的字段拆分出去到擴(kuò)展表中梨水。在字段很多的情況下（例如一個(gè)大表有100多個(gè)字段），通過"大表拆小表"茵臭，更便于開發(fā)與維護(hù)疫诽，也能避免跨頁問題，MySQL底層是通過數(shù)據(jù)頁存儲(chǔ)的旦委，一條記錄占用空間過大會(huì)導(dǎo)致跨頁奇徒，造成額外的性能開銷。另外數(shù)據(jù)庫以行為單位將數(shù)據(jù)加載到內(nèi)存中缨硝，這樣表中字段長度較短且訪問頻率較高摩钙，內(nèi)存能加載更多的數(shù)據(jù)，命中率更高查辩，減少了磁盤IO胖笛，從而提升了數(shù)據(jù)庫性能。缺點(diǎn)：部分表無法join宜肉，只能通過接口聚合方式解決匀钧，提升了開發(fā)的復(fù)雜度；分布式事務(wù)處理復(fù)雜谬返。

水平（橫向）切分：水平切分分為庫內(nèi)分表和分庫分表之斯，是根據(jù)表內(nèi)數(shù)據(jù)內(nèi)在的邏輯關(guān)系，將同一個(gè)表按不同的條件分散到多個(gè)數(shù)據(jù)庫或多個(gè)表中遣铝，每個(gè)表中只包含一部分?jǐn)?shù)據(jù)佑刷，從而使得單個(gè)表的數(shù)據(jù)量變小，達(dá)到分布式的效果酿炸。庫內(nèi)分表只解決了單一表數(shù)據(jù)量過大的問題瘫絮，但沒有將表分布到不同機(jī)器的庫上，因此對于減輕MySQL數(shù)據(jù)庫的壓力來說填硕，幫助不是很大麦萤，大家還是競爭同一個(gè)物理機(jī)的CPU、內(nèi)存扁眯、網(wǎng)絡(luò)IO壮莹，最好通過分庫分表來解決。缺點(diǎn)：跨分片的事務(wù)一致性難以保證姻檀；部分表無法join命满，只能通過接口聚合方式解決，提升了開發(fā)的復(fù)雜度绣版。

常用的支持分庫分表中間件：sharding-jdbc（當(dāng)當(dāng)）胶台、TSharding（蘑菇街）歼疮、Atlas（奇虎360）、Cobar（阿里巴巴）诈唬、MyCAT（基于Cobar）韩脏、Vitess（谷歌）

10.MySQL索引為什么用B+樹

B+樹的磁盤讀寫代價(jià)更低，因?yàn)锽+樹的所有非葉子節(jié)點(diǎn)只會(huì)存放索引信息讯榕，而真正的數(shù)據(jù)信息都只存放在葉子節(jié)點(diǎn)中骤素，這樣一來匙睹，每個(gè)非葉子節(jié)點(diǎn)存放的索引信息就更多愚屁，一次磁盤IO就可以讀取更多的索引信息到內(nèi)存中，可以減少磁盤IO的次數(shù)痕檬。

B+樹的查詢效率更加穩(wěn)定霎槐，由于非葉子節(jié)點(diǎn)只存索引信息，而沒有真正的數(shù)據(jù)信息梦谜，所以任何關(guān)鍵字的查找必須走一條從根結(jié)點(diǎn)到葉子結(jié)點(diǎn)的路丘跌。所有關(guān)鍵字查詢的路徑長度相同，導(dǎo)致每一個(gè)數(shù)據(jù)的查詢效率相當(dāng)唁桩。

B+樹更加適合在區(qū)間查詢的情況闭树，由于B+樹的數(shù)據(jù)都存儲(chǔ)在葉子結(jié)點(diǎn)中，非葉子結(jié)點(diǎn)均為索引荒澡，只需要掃一遍葉子結(jié)點(diǎn)即可得到所有數(shù)據(jù)信息报辱，但是B樹因?yàn)槠浞侨~子結(jié)點(diǎn)同樣存儲(chǔ)著數(shù)據(jù)，我們要找到具體的數(shù)據(jù)单山，需要進(jìn)行一次中序遍歷按序來掃碍现，所以B+樹更加適合在區(qū)間查詢的情況，所以通常B+樹用于數(shù)據(jù)庫索引米奸。

11.復(fù)合索引

兩個(gè)或更多個(gè)列上的索引被稱作復(fù)合索引昼接。利用索引中的附加列，縮小搜索的范圍悴晰，但使用一個(gè)具有兩列的索引 不同于使用兩個(gè)單獨(dú)的索引慢睡。? ? 實(shí)現(xiàn)：采用B+樹實(shí)現(xiàn)，每個(gè)節(jié)點(diǎn)含有多個(gè)關(guān)鍵字铡溪，排序時(shí)按照多個(gè)關(guān)鍵字來排序漂辐。

12.主鍵和唯一索引的區(qū)別

主鍵是一種約束，唯一索引是一種索引佃却，兩者在本質(zhì)上是不同的者吁；主鍵創(chuàng)建后一定包含一個(gè)唯一性索引，唯一性索引并不一定就是主鍵饲帅；?唯一性索引列允許空值复凳，而主鍵列不允許為空值瘤泪；一個(gè)表最多只能創(chuàng)建一個(gè)主鍵，但可以創(chuàng)建多個(gè)唯一索引育八；主鍵可以被其他表引用為外鍵对途，而唯一索引不能。

13. Varchar（2000）創(chuàng)建索引會(huì)怎樣

使用InnoDB引擎創(chuàng)建組合索引(index)時(shí)髓棋，如果某個(gè)索引列的長度超過767 -> 給出warning实檀，索引創(chuàng)建成功，超過767字節(jié)的列自動(dòng)取前綴索引按声。 我們知道utf-8一般使用3個(gè)字節(jié)存儲(chǔ)一個(gè)字膳犹，它是按照最大存儲(chǔ)空間計(jì)算可以存儲(chǔ)的字符數(shù)。767最大長度的限制對于utf-8編碼的字段來說签则，最多能存放767 / 3 = 255.3個(gè)字须床。也就是說，如果創(chuàng)建的索引中包含一個(gè)varchar(256)會(huì)報(bào)warning渐裂，而把它改為varchar(255)就沒有warning豺旬。

14.數(shù)據(jù)庫事務(wù)

數(shù)據(jù)庫事務(wù)(Database Transaction) ，是指作為單個(gè)邏輯工作單元執(zhí)行的一系列操作（對數(shù)據(jù)庫的相關(guān)增刪改查的操作）柒凉，要么完全地執(zhí)行族阅，要么完全地不執(zhí)行。?數(shù)據(jù)庫的四大特性ACID膝捞，原子性坦刀、一致性、隔離性绑警、持久性求泰。每個(gè)特性都有其特定的職責(zé)腾节。

原子性：一個(gè)事務(wù)中的所有操作武通，要不 操作全部成功，要不全部失敗将塑，不能存在中間態(tài)北启。

一致性：事務(wù)必須使得數(shù)據(jù)庫從一個(gè)一致性狀態(tài)轉(zhuǎn)變到另一個(gè)一致性狀態(tài)卜朗。比如銀行轉(zhuǎn)賬，A賬戶轉(zhuǎn)到B賬戶咕村，不管轉(zhuǎn)幾次场钉，A和B賬戶的總額不變。

隔離性：是指多個(gè)用戶同時(shí)請求數(shù)據(jù)庫懈涛，開啟多個(gè)事務(wù)同時(shí)處理某個(gè)數(shù)據(jù)庫逛万，隔離性保證了各個(gè)事務(wù)之間均不受干擾，每個(gè)事務(wù)都感覺不到其他事務(wù)的存在批钠。

持久性：對數(shù)據(jù)庫的修改是持久性的宇植，一旦修改得封，就算數(shù)據(jù)庫系統(tǒng)出現(xiàn)故障，這種修改也不會(huì)丟失指郁。

15.MySQL B+Tree索引和Hash索引的區(qū)別忙上？

如果是等值查詢，那么哈希索引明顯有絕對優(yōu)勢闲坎，因?yàn)橹恍枰?jīng)過一次算法即可找到相應(yīng)的鍵值疫粥；當(dāng)然了，這個(gè)前提是腰懂，鍵值都是唯一的梗逮。如果鍵值不是唯一的，就需要先找到該鍵所在位置悯恍，然后再根據(jù)鏈表往后掃描库糠，直到找到相應(yīng)的數(shù)據(jù)；

如果是范圍查詢檢索涮毫，這時(shí)候哈希索引就毫無用武之地了，因?yàn)樵仁怯行虻逆I值贷屎，經(jīng)過哈希算法后罢防，有可能變成不連續(xù)的了，就沒辦法再利用索引完成范圍查詢檢索唉侄；同理，哈希索引也沒辦法利用索引完成排序属划，以及l(fā)ike ‘xxx%’ 這樣的部分模糊查詢（這種部分模糊查詢恬叹，其實(shí)本質(zhì)上也是范圍查詢）；哈希索引也不支持多列聯(lián)合索引的最左匹配規(guī)則同眯；

B+樹索引的關(guān)鍵字檢索效率比較平均绽昼，不像B樹那樣波動(dòng)幅度大，在有大量重復(fù)鍵值情況下须蜗，哈希索引的效率也是極低的硅确，因?yàn)榇嬖谒^的哈希碰撞問題。

16.mysql都有什么鎖,死鎖判定原理和具體場景,死鎖怎么解決

表級鎖：myISAM 開銷小明肮，加鎖快菱农，不會(huì)出現(xiàn)死鎖，鎖定粒度大柿估，并發(fā)量低循未，發(fā)生鎖沖突概率大

行級鎖：InnoDB 開銷大，加鎖慢秫舌，會(huì)出現(xiàn)死鎖的妖，鎖定粒度小烙丛，并發(fā)量高，發(fā)生鎖沖突概率小

頁面鎖：開銷和加鎖時(shí)間界于表鎖和行鎖之間羔味；會(huì)出現(xiàn)死鎖河咽；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般

死鎖: 是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過程中赋元。因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進(jìn)下去忘蟹。此時(shí)稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖,這些永遠(yuǎn)在互相等待的進(jìn)程稱為死鎖進(jìn)程。

死鎖的解決辦法

1.查出的線程殺死 kill? ? ? ? SELECT trx_MySQL_thread_id FROM information_schema.INNODB_TRX;

2.設(shè)置鎖的超時(shí)時(shí)間? ? ? ? Innodb 行鎖的等待時(shí)間搁凸，單位秒媚值。可在會(huì)話級別設(shè)置护糖，RDS 實(shí)例該參數(shù)的默認(rèn)值為 50（秒）褥芒。

生產(chǎn)環(huán)境不推薦使用過大的 innodb_lock_wait_timeout參數(shù)值

該參數(shù)支持在會(huì)話級別修改，方便應(yīng)用在會(huì)話級別單獨(dú)設(shè)置某些特殊操作的行鎖等待超時(shí)時(shí)間嫡良，如下：

set innodb_lock_wait_timeout=1000; —設(shè)置當(dāng)前會(huì)話 Innodb 行鎖等待超時(shí)時(shí)間锰扶，單位秒。

3.指定獲取鎖的順序

17.排它鎖

?select … for update??排他鎖的申請前提：沒有線程對該結(jié)果集中的任何行數(shù)據(jù)使用排他鎖或共享鎖寝受，否則申請會(huì)阻塞坷牛。for update僅適用于InnoDB，且必須在事務(wù)塊(BEGIN/COMMIT)中才能生效很澄。在進(jìn)行事務(wù)操作時(shí)京闰，通過“for update”語句，MySQL會(huì)對查詢結(jié)果集中每行數(shù)據(jù)都添加排他鎖甩苛，其他線程對該記錄的更新與刪除操作都會(huì)阻塞蹂楣。排他鎖包含行鎖、表鎖讯蒲。

18.非關(guān)系型數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫最典型的數(shù)據(jù)結(jié)構(gòu)是表痊土，由二維表及其之間的聯(lián)系所組成的一個(gè)數(shù)據(jù)組織

優(yōu)點(diǎn)：1、易于維護(hù)：都是使用表結(jié)構(gòu)爱葵，格式一致施戴；2、使用方便：SQL語言通用萌丈，可用于復(fù)雜查詢赞哗；3、復(fù)雜操作：支持SQL辆雾，可用于一個(gè)表以及多個(gè)表之間非常復(fù)雜的查詢肪笋。

缺點(diǎn)：1、讀寫性能比較差，尤其是海量數(shù)據(jù)的高效率讀寫藤乙；2猜揪、固定的表結(jié)構(gòu)，靈活度稍欠坛梁；3而姐、高并發(fā)讀寫需求，傳統(tǒng)關(guān)系型數(shù)據(jù)庫來說划咐，硬盤I/O是一個(gè)很大的瓶頸

非關(guān)系型數(shù)據(jù)庫嚴(yán)格上不是一種數(shù)據(jù)庫拴念，應(yīng)該是一種數(shù)據(jù)結(jié)構(gòu)化存儲(chǔ)方法的集合，可以是文檔或者鍵值對等褐缠。

優(yōu)點(diǎn)：1政鼠、格式靈活：存儲(chǔ)數(shù)據(jù)的格式可以是key,value形式、文檔形式队魏、圖片形式等等公般，使用靈活，應(yīng)用場景廣泛胡桨，而關(guān)系型數(shù)據(jù)庫則只支持基礎(chǔ)類型官帘。2、速度快：nosql可以使用硬盤或者隨機(jī)存儲(chǔ)器作為載體登失，而關(guān)系型數(shù)據(jù)庫只能使用硬盤遏佣；3、高擴(kuò)展性揽浙；4、成本低：nosql數(shù)據(jù)庫部署簡單意敛，基本都是開源軟件馅巷。

缺點(diǎn)：1、不提供sql支持草姻，學(xué)習(xí)和使用成本較高钓猬；2、無事務(wù)處理撩独；3敞曹、數(shù)據(jù)結(jié)構(gòu)相對復(fù)雜，復(fù)雜查詢方面稍欠综膀。

19.mySQL日志

1.錯(cuò)誤日志(error log)：記錄mysql服務(wù)的啟停時(shí)正確和錯(cuò)誤的信息澳迫，還記錄啟動(dòng)、停止剧劝、運(yùn)行過程中的錯(cuò)誤信息橄登。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

2.查詢?nèi)罩?general log)：記錄建立的客戶端連接和執(zhí)行的語句。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?3.二進(jìn)制日志(bin log)：記錄所有更改數(shù)據(jù)的語句，可用于數(shù)據(jù)復(fù)制拢锹。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

4.慢查詢?nèi)罩?slow log)：記錄所有執(zhí)行時(shí)間超過long_query_time的所有查詢或不使用索引的查詢谣妻。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

5.中繼日志(relay log)：主從復(fù)制時(shí)使用的日志。

20.什么是內(nèi)連接卒稳、外連接蹋半、交叉連接（笛卡爾積）？

內(nèi)連接（inner join）：取得兩張表中滿足存在連接匹配關(guān)系的記錄充坑。? ??

外連接（outer join）：取得兩張表中滿足存在連接匹配關(guān)系的記錄减江，以及某張表（或兩張表）中不滿足匹配關(guān)系的記錄。具體又分為：左外鏈接匪傍、右外連接您市、全外鏈接。? ? ? ?

交叉連接（cross join）：顯示兩張表所有記錄一一對應(yīng)役衡，沒有匹配關(guān)系進(jìn)行篩選茵休，也被稱之為：笛卡爾積

21.索引的最左前綴原則

在Mysql建立多列索引（聯(lián)合索引）有最左前綴的原則，即最左優(yōu)先手蝎。

如果我們建立了一個(gè)2列的聯(lián)合索引(col1,col2),實(shí)際上已經(jīng)建立了兩個(gè)聯(lián)合索引(col1)榕莺、(col1,col2）;如果有一個(gè)3列索引(col1,col2,col3)，實(shí)際上已經(jīng)建立了三個(gè)聯(lián)合索引(col1)棵介、(col1,col2)钉鸯、(col1,col2,col3)。

22.數(shù)據(jù)庫的三大范式

第一范式(確保每列保持原子性)? ? ? ? ? ? ??列不可再分

第二范式(確保表中的每列都和主鍵相關(guān))? ? ? ? ?屬性完全依賴于主鍵

第三范式(確保每列都和主鍵列直接相關(guān),而不是間接相關(guān))? ? 屬性不依賴于其它非主屬性 屬性直接依賴于主鍵

23.SQL優(yōu)化

1邮辽、對查詢進(jìn)行優(yōu)化唠雕，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引吨述。

?2岩睁、應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描揣云。

?3捕儒、應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

4邓夕、應(yīng)盡量避免在 where 子句中使用 or 來連接條件刘莹，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

5、下面的查詢也將導(dǎo)致全表掃描：select id from t where name like '%abc%'? ?若要提高效率焚刚，可以考慮全文檢索

6点弯、應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描

7汪榔、不要在 where 子句中的“=”左邊進(jìn)行函數(shù)蒲拉、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算肃拜，否則系統(tǒng)將可能無法正確使用索引