數(shù)據(jù)庫程序員面試分類真題26

數(shù)據(jù)庫程序員面試分類真題26簡答題1.

profile的意義以及使用場景有哪些?正確答案：MySQL可以使用profile分析SQL語句的性能消耗情況。例如，查詢到SQL會執(zhí)行多少時間，并看出CP（江南博哥）U、內(nèi)存使用量，執(zhí)行過程中系統(tǒng)鎖及表鎖的花費時間等信息。通過have_profiling參數(shù)可以查看MySQL是否支持profile，通過profiling參數(shù)可以查看當前系統(tǒng)profile是否開啟。

查看profile是否開啟：

以下是有關profile的一些常用命令：

1)setprofiling=1；#基于會話級別開啟，關閉則用setprofiling=off。

2)showprofilecpuforquery1；#查看CPU的消耗情況。

3)showprofilememoryforquery1；#查看內(nèi)存消耗情況。

4)showprofileblockio,cpuforquery1；#查看I/O及CPU的消耗情況。

可以使用如下的語句查詢SQL的整體消耗百分比：

SELECTSTATE,SUM(DURATION)ASTOTAL_R,

ROUND(100*SUM(DURATION)/(SELECTSUM(DURATION)FROMINFORMATION_SCHEMA.PROFILINGWHEREQUERY_ID=1),2)ASPCT_R,

COUNT(*)ASCALLS,SUM(DURATION)/COUNT(*)AS"R/Call"

FROMINFORMATION_SCHEMA.PROFILING

WHEREQUERY_ID=1GROUPBYSTATEORDERBYTOTAL_RDESC;

profile是一個非常量化的指標，可以根據(jù)這些量化指標來比較各項資源的消耗，有利于對SQL語句的整體把控。[考點]執(zhí)行計劃

2.

MySQL之CHECK、OPTIMIZE和ANALYZE的作用分別是什么?正確答案：分析表(ANALYZE)的主要作用是分析關鍵字的分布；檢查表(CHECK)的主要作用是檢查表是否存在錯誤；優(yōu)化表(OPTIMIZE)的主要作用是消除刪除或者更新造成的空間浪費。詳細信息見下表。

需要注意以下幾點：

1)對于InnoDB引擎的表來說，通過設置innodb_file_per_table參數(shù)，設置InnoDB為獨立表空間模式，這樣每個數(shù)據(jù)庫的每個表都會生成一個獨立的ibd文件，用于存儲表的數(shù)據(jù)和索引，這樣可以一定程度上減輕InnoDB表的空間回收問題。另外，在刪除大量數(shù)據(jù)后，InnoDB表可以通過altertable但是不修改引擎的方式來回收不用的空間，該操作會重建表：

2)ANALYZE、CHECK、OPTIMIZE、ALTERTABLE執(zhí)行期間將對表進行鎖定(數(shù)據(jù)庫系統(tǒng)會對表加一個只讀鎖，在分析期間，只能讀取表中的記錄，不能更新和插入記錄)，因此一定注意要在數(shù)據(jù)庫不繁忙的時候執(zhí)行相關的操作。[考點]執(zhí)行計劃

3.

MySQL中的索引有什么優(yōu)點?正確答案：索引(Index)是數(shù)據(jù)庫優(yōu)化中最常用也是最重要的手段之一，通過索引通?？梢詭椭脩艚鉀Q大多數(shù)的SQL性能問題。索引是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結構，它用于快速找出在某個列中含有某一特定值的行。如果不使用索引，那么MySQL必須從第1條記錄開始讀完整個表直到找出相關的行。表越大，花費的時間越多。如果表中查詢的列有一個索引，那么MySQL就能快速到達一個位置去搜尋數(shù)據(jù)文件的中間，沒有必要看所有數(shù)據(jù)。

索引在MySQL中也叫作“鍵(Key)”，是存儲引擎用于快速找到記錄的一種數(shù)據(jù)結構。總體來說，索引有如下幾個優(yōu)點：

1)索引大大減少了服務器需要掃描的數(shù)據(jù)量。

2)索引可以幫助服務器避免排序和臨時表。

3)索引可以將隨機I/O變?yōu)轫樞騃/O。[考點]索引

4.

MySQL有哪些索引種類?正確答案：MySQL的所有列類型都可以被索引。MyISASM和InnoDB類型的表默認創(chuàng)建的都是BTREE索引；MEMORY類型的表默認使用HASH索引，但是也支持BTREE索引；空間列類型的索引使用RTREE(空間索引)。

MvSQL中的索引是在存儲引擎層中實現(xiàn)的，而不是在服務器層實現(xiàn)的。所以每種存儲引擎的索引都不一定完全相同，也不是所有的存儲引擎都支持所有的索引類型。MySQL目前提供了以下幾種索引：

1)BTREE索引：最常見的索引類型，大部分引擎都支持BTREE索引，例如，MyISASM、InnoDB、MEMORY等。

2)HASH索引：只有MEMORY和NDB引擎支持，使用場景簡單。

3)RTREE索引(空間索引)：空間索引是MyISAM的一個特殊索引類型，主要用于地理空間數(shù)據(jù)類型，通常使用較少。

4)FULLTEXT(全文索引)：全文索引也是MyISAM的一個特殊索引類型，主要用于全文索引，InnoDB從MySQL5.6版本開始提供對全文索引的支持。

MySQL目前還不支持函數(shù)索引，但是支持前綴索引，即對索引字段的前N個字符創(chuàng)建索引，這個特性可以大大縮小索引文件的大小，從而提高性能。但是，前綴索引在排序ORDERBY和分組GROUPBY操作的時候無法使用，也無法使用前綴索引做覆蓋掃描。用戶在設計表結構的時候也可以對文本列根據(jù)此特性進行靈活設計。[考點]索引

5.

什么是覆蓋索引?正確答案：如果一個索引包含(或者說覆蓋了)所有滿足查詢所需要的數(shù)據(jù)，那么就稱這類索引為覆蓋索引(CoveringIndex)。索引覆蓋查詢不需要回表操作。在MySQL中，可以通過使用explain命令輸出的Extra列來判斷是否使用了索引覆蓋查詢。若使用了索引覆蓋查詢，則Extra列包含“Usingindex”字符串。MySQL查詢優(yōu)化器在執(zhí)行查詢前會判斷是否有一個索引能執(zhí)行覆蓋查詢。

覆蓋索引能有效地提高查詢性能，因為覆蓋索引只需要讀取索引而不用回表再讀取數(shù)據(jù)。覆蓋索引有以下一些優(yōu)點：

1)索引項通常比記錄要小，所以MySQL會訪問更少的數(shù)據(jù)。

2)索引都按值的大d,N序存儲，相對于隨機訪問記錄，需要更少的I/O。

3)大多數(shù)據(jù)引擎能更好地緩存索引，比如MyISAM只緩存索引。

4)覆蓋索引對于InnoDB表尤其有用，因為InnoDB使用聚集索引組織數(shù)據(jù)，如果二級索引中包含查詢所需的數(shù)據(jù)，那么就不再需要在聚集索引中查找了。

下面的SQL語句就使用了覆蓋索引：

[考點]索引

6.

什么是哈希索引?正確答案：哈希索引(ItashIndex)建立在哈希表的基礎上，它只對使用了索引中的每一列的精確查找有用。對于每一行，存儲引擎計算出了被索引的哈希碼(HashCode)，它是一個較小的值，并且有可能和其他行的哈希碼不同。它把哈希碼保存在索引中，并且保存了一個指向哈希表中的每一行的指針。如果多個值有相同的哈希碼，那么索引就會把行指針以鏈表的方式保存在哈希表的同一條記錄中。

哈希索引只有MEMORY和NDB兩種引擎支持，MEMORY引擎默認支持哈希索引，如果多個HASH值相同，出現(xiàn)哈希碰撞，那么索引以鏈表方式存儲。若要使InnoDB或MyISAM支持哈希索引，那么可以通過偽哈希索引來實現(xiàn)。主要通過增加一個字段，存儲HASH值，將HASH值建立索引，在插入和更新的時候，建立觸發(fā)器，自動添加計算后的HASH值到表里。在查詢的時候，在WHERE子句手動指定使用哈希函數(shù)。這樣做的缺陷是需要維護哈希值。

MySQL最常用存儲引擎InnoDB和MyISAM都不支持HASH索引，它們默認的索引都是BTREE。但是，如果在創(chuàng)建索引的時候定義其索引類型為HASH，那么MySQL并不會報錯，而且通過SHOWCREATETABLE查看該索引也是HASH，只不過該索引實際上還是BTREE。

HASH索引檢索效率非常高，索引的檢索可以一次定位，不像BTREE索引需要從根節(jié)點到枝節(jié)點，最后才能訪問到葉節(jié)點這樣多次的I/O訪問，所以HASH索引的查詢效率要遠高于BTREE索引。那么，既然HASH索引的效率要比BTREE高很多，為什么大家不都用HASH索引而還要使用BTREE索引呢?其實，任何事物都是有兩面性的，HASH索引也一樣，雖然HASH索引效率高，但是HASH索引本身由于其特殊性也帶來了很多限制和弊端，主要有以下這些：

1)HASH索引僅僅能滿足“=”“IN”和“＜=＞”查詢，不能使用范圍查詢。由于HASH索引比較的是進行HASH運算之后的HASH值，所以它只能用于等值的過濾，不能用于基于范圍的過濾，因為經(jīng)過相應的HASH算法處理之后的HASH值的大小關系，并不能保證和HASH運算前完全一樣。

2)優(yōu)化器不能使用HASH：索引來加速ORDERBY操作，即HASH索引無法被用來避免數(shù)據(jù)的排序操作。由于HASH索引中存放的是經(jīng)過HASH計算之后的HASH值，而且HASH值的大小關系并不一定和HASH運算前的鍵值完全一樣，所以數(shù)據(jù)庫無法利用索引的數(shù)據(jù)來避免任何排序運算。

3)MySQL不能確定在兩個值之間大約有多少行。如果將一個MyISAM表改為HASH索引的MEMORY表，會影響一些查詢的執(zhí)行效率。

4)只能使用整個關鍵字來搜索一行，即HASH索引不能利用部分索引鍵查詢。對于組合索引，HASH索引在計算HASH值的時候是組合索引鍵合并后再一起計算HASH值，而不是單獨計算HASH值，所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候，HASH索引也無法被利用。

5)HASH索引在任何時候都不能避免表掃描。HASH索引是將索引鍵通過HASH運算之后，將HASH運算結果的HASH值和所對應的行指針信息存放于一個HASH表中，由于不同索引鍵存在相同HASH值，所以即使取滿足某個HASH鍵值的數(shù)據(jù)的記錄條數(shù)，也無法從HASH索引中直接完成查詢，還是要通過訪問表中的實際數(shù)據(jù)進行相應的比較，并得到相應的結果。

6)HASH索引遇到大量HASH值相等的情況后，性能并不一定就會比BTREE索引高。對于選擇性比較低的索引鍵，如果創(chuàng)建HASH索引，那么將會存在大量記錄指針信息和同一個HASH值相關聯(lián)。這樣要定位某一條記錄時就會非常麻煩，會浪費多次表數(shù)據(jù)的訪問，而造成整體性能低下。[考點]索引

7.

什么是自適應哈希索引(AdaptiveHashIndex)?正確答案：InnoDB引擎有一個特殊的功能叫作自適應哈希索引(AdaptiveHashIndex)。當InnoDB注意到某些索引值被使用得非常頻繁時，它會在內(nèi)存中基于BTREE索引之上再創(chuàng)建一個哈希索引，這樣就讓BTREE索引也具有哈希索引的一些優(yōu)點。例如，快速的哈希查找，這是一個全自動的、內(nèi)部的行為，用戶無法控制或者配置，不過如果有必要，可以選擇關閉這個功能(innodb_adaptive_hash_index=OFF，默認為ON)。

通過“SHOWENGINEINNODBSTATUS;”可以看到當前自適應哈希索引的使用情況：

--------------------------------

INSERTBUFFERANDADAPTIVEHASHINDEX

--------------------------------

Ibuf:size1,freelistlen0,segsize2,94merges

mergedoperations:

insert280,deletemark0,delete0

discardedoperations:

insert0,deletemark0,delete0

Hashtablesize4425293,nodeheaphas1337buffer(s)

174.24hashsearches/s,169.49non-hashsearches/s

可以看到自適應哈希索引的使用信息，包括自適應哈希索引的大小、使用情況，每秒使用自適應哈希索引搜索的情況。[考點]索引

8.

什么是前綴索引?正確答案：有時候需要索引很長的字符列，這會讓索引變得大且慢，此時可以考慮前綴索引。MySQL目前還不支持函數(shù)索引，但是支持前綴索引，即對索引字段的前N個字符創(chuàng)建索引，這個特性可以大大縮小索引文件的大小，從而提高索引效率。用戶在設計表結構的時候也可以對文本列根據(jù)此特性進行靈活設計。前綴索引是一種能使索引更小、更快的有效辦法。

前綴索引的缺點：在排序ORDERBY和分組GROUPBY操作的時候無法使用，也無法使用前綴索引做覆蓋掃描，并且前綴索引降低了索引的選擇性。索引的選擇性是指不重復的索引值(也稱為基數(shù)，Cardinality)和數(shù)據(jù)表的記錄總數(shù)(COUNT(*))的比值，范圍為(0，1]。索引的選擇性越高則查詢效率越高，因為選擇性高的索引可以讓MySQL在查找時過濾掉更多的行。唯一索引的選擇性是1，這是最好的索引選擇性，性能也是最好的。

一般情況下某個前綴的選擇性也是足夠高的，足以滿足查詢性能。對于BLOB、TEXT或者很長的VARCHAR類型的列，必須使用前綴索引，因為MySQL不允許索引這些列的完整長度。

使用前綴索引的訣竅在于，要選擇足夠長的前綴以保證較高的選擇性，同時又不能太長(以便節(jié)約空間)。前綴應該足夠長，以使得前綴索引的選擇性接近于索引的整個列。換句話說，前綴的“基數(shù)”應該接近于完整的列的“基數(shù)”。[考點]索引

9.

簡單描述在MySQL中，索引、唯一索引、主鍵、聯(lián)合索引的區(qū)別，它們對數(shù)據(jù)庫的性能有什么影響?正確答案：索引、唯一索引、主鍵、聯(lián)合索引的區(qū)別如下：

1)索引：一種特殊的文件(InnoDB數(shù)據(jù)表上的索引是表空間的一個組成部分)，它們包含著對數(shù)據(jù)表里所有記錄的引用指針。普通索引(由關鍵字KEY或INDEX定義的索引)的唯一任務是加快對數(shù)據(jù)的訪問速度。

2)唯一索引：普通索引允許被索引的數(shù)據(jù)列包含重復的值，如果能確定某個數(shù)據(jù)列只包含彼此各不相同的值，在為這個數(shù)據(jù)索引創(chuàng)建索引的時候就應該用關鍵字UNIQE把它定義為一個唯一索引，唯一索引可以保證數(shù)據(jù)記錄的唯一性。

3)主鍵：一種特殊的唯一索引，在一張表中只能定義一個主鍵索引，逐漸用于唯一標識一條記錄，是用關鍵字PRIMARYKEY來創(chuàng)建。

4)聯(lián)合索引：索引可以覆蓋多個數(shù)據(jù)列，如INDEX索引就是聯(lián)合索引。

索引可以極大地提高數(shù)據(jù)的查詢速度，但是會降低插入、刪除、更新表的速度，因為在執(zhí)行這些寫操作時，還要操作索引文件。[考點]索引

10.

在表中建立了索引以后，導入大量數(shù)據(jù)為什么會很慢?正確答案：對已經(jīng)建立了索引的表中插入數(shù)據(jù)時，插入一條數(shù)據(jù)就要對該記錄按索引排序。因此，導入大量數(shù)據(jù)的時候速度會很慢。解決這種情況的辦法是，在沒有任何索引的情況插入數(shù)據(jù)，然后建立索引。[考點]索引

11.

MySQL原生支持的備份方式及種類有哪些?正確答案：MySQL原生支持的備份方式有如下幾種方式：

1)直接拷貝數(shù)據(jù)文件，必須是MyISAM表，且使用flushtableswithreadlock語句，優(yōu)點是簡單方便，缺點是必須要鎖定，且只能在同版本的MySQL上恢復使用。

2)mysqldump，由于導出的是SQL語句，所以，可以跨版本恢復，但是需要導入數(shù)據(jù)和重建索引，恢復用時會較長，如果是MyISAM表，那么同樣需要鎖表；如果是InnoDB表，那么可以使用--single-transaction參數(shù)避免此問題。[考點]備份恢復

12.

MySQL支持的備份類型包括哪些?正確答案：MySQL支持的備份類型如下圖所示。

1)根據(jù)備份方法，備份可以分為如下3種：

①熱備份(HotBackup)：熱備份也稱為在線備份(OnlineBackup)，是指在數(shù)據(jù)庫運行的過程中進行備份，對生產(chǎn)環(huán)境中的數(shù)據(jù)庫運行沒有任何影響。常見的熱備方案是利用mysqldump、XtraBackup等工具進行備份。

②冷備份(ColdBackup)：冷備份也稱為離線備份(OfflineBackup)，是指在數(shù)據(jù)庫關閉的情況下進行備份，這種備份非常簡單，只需要關閉數(shù)據(jù)庫，復制相關的物理文件即可。目前，線上數(shù)據(jù)庫一般很少能夠接受關閉數(shù)據(jù)庫，所以該備份方式很少使用。

③溫備份(WarmBackup)：溫備份也是在數(shù)據(jù)庫運行的過程中進行備份，但是備份會對數(shù)據(jù)庫操作有所影響。該備份利用鎖表的原理備份數(shù)據(jù)庫，由于影響了數(shù)據(jù)庫的操作，故該備份方式也很少使用。

2)根據(jù)備份文件的種類，備份可以分為如下兩種：

①物理備份(PhysicalBackup)：物理備份也稱為裸文件備份(RawBackup)，是指復制數(shù)據(jù)庫的物理文件。物理備份既可以在數(shù)據(jù)庫運行的情況下進行備份(常見備份工具：MySQLEnterpriseBackup(商業(yè))、XtraBackup等)，也可以在數(shù)據(jù)庫關閉的情況下進行備份。該備份方式不僅備份速度快，而且恢復速度也快，但是由于無法查看備份后的內(nèi)容，所以只能等到恢復之后，才能檢驗備份出來的數(shù)據(jù)是否是正確的。

②邏輯備份(LogicalBackup)：邏輯備份是指備份文件的內(nèi)容是可讀的，該文本一般是由一條條SQL語句或者表的實際數(shù)據(jù)組成。常見的邏輯備份方式有mysqldump、SELECT...INTOOUTFILE等。這類備份方法的好處是可以觀察備份后的文件內(nèi)容，缺點是恢復時間往往會很長。邏輯備份的最大優(yōu)點是對于各種存儲引擎都可以用同樣的方法來備份；而物理備份則不同，不同的存儲引擎有著不同的備份方法。因此，對于不同存儲引擎混合的數(shù)據(jù)庫，用邏輯備份會更簡單一些。

3)根據(jù)備份內(nèi)容，備份可以劃分為如下3種：

①全量備份(FullBackup)：全量備份(完全備份)是指對數(shù)據(jù)庫進行一次完整的備份，備份所有的數(shù)據(jù)，包含用戶表、系統(tǒng)表、索引、視圖和存儲過程等所有數(shù)據(jù)庫對象。這是一般常見的備份方式，可以使用該備份快速恢復數(shù)據(jù)庫，或者搭建從庫?；謴退俣纫彩亲羁斓?，但是每次備份會消耗較多的磁盤空間，并且備份時間較長。所以，一般推薦一周做一次全量備份。

②增量備份(IncrementalBackup)：增量備份也叫差異備份，是指基于上次完整備份或增量備份，對數(shù)據(jù)庫新增的修改進行備份。這種備份方式有利于減少備份時使用的磁盤空間，加快備份速度。但是恢復的時候速度較慢，并且操作相對復雜。推薦每天做一次增量備份。

③日志備份(BinaryLogBackup)：日志備份是指對數(shù)據(jù)庫二進制日志的備份。二進制日志是一個單獨的文件，它記錄數(shù)據(jù)庫的改變，備份的時候只需要復制自上次備份以來對數(shù)據(jù)庫所做的改變，所以只需要很少的時間。該備份方式一般與上面的全量備份或增量備份結合使用，可以使數(shù)據(jù)庫恢復到任意位置。所以，推薦每小時甚至更頻繁地備份二進制日志。

在生產(chǎn)環(huán)境上，一般都會選擇以物理備份為主，邏輯備份為輔，加上日志備份，來滿足線上使用數(shù)據(jù)庫的需求。[考點]備份恢復

13.

如何從mysqldump工具中備份的全庫備份文件中恢復某個庫和某張表?正確答案：恢復某個庫可以使用--one-database(簡寫-o)參數(shù)，如下：

全庫備份：

[root@rhe16lhr～]#mysqldump-uroot-p--single-transaction-A--master-data=2＞dump.sql

只還原erp庫的內(nèi)容：

[root@rhe16lhr～]#mysql-uroot-pMANAGERerp--one-database＜dump.sql

那么如何從全庫備份中抽取某張表呢?可以用全庫恢復，再恢復某張表即可。但是，對于小庫還可以，大庫就很麻煩了，所以，此時可以利用正則表達式來進行快速抽取，具體實現(xiàn)方法如下：

從全庫備份中抽取出t表的表結構：

[root@HE1～]#sed-e'/./{H;$!d;}'-e'x;/CREATETABLE't'/!d;q'dump.sql

DROPTABLEIFEXISTS't';

/*!40101SET@saved_cs_client

=@@character_set_client*/;

/*!40101SETcharacter_set_client=utf8*/;

CREATETABLE't'(

'id'int(10)NOTNULLAUTO_INCREMENT,

'age'tinyint(4)NOTNULLDEFAULT'0',

'name'varchar(30)NOTNULLDEFAULT",

PRIMARYKEY('id')

)ENGINE=InnoDBAUTO_INCREMENT=4DEFAULTCHARSET=utf8;

/*!40101SETcharacter_set_client=@saved_cs_client*/;

再從全庫備份中抽取出t表的內(nèi)容：

[root@HE1～]#grep'INSERTINTO't''dump.sql

INSERTINTO't'VALUES(0,0,"),(1,0,'aa'),(2,0,'bbb'),(3,25,'helei');[考點]備份恢復

14.

MySQL數(shù)據(jù)表在什么情況下容易損壞?正確答案：服務器突然斷電導致數(shù)據(jù)文件損壞；強制關機，沒有先關閉mysqld服務等。[考點]備份恢復

15.

數(shù)據(jù)表損壞后的主要現(xiàn)象是什么?正確答案：從表中選擇數(shù)據(jù)時，得到如下錯誤：

Incorrectkeyfilefortable:'…'.Trytorepairit

查詢不能在表中找到行或返回不完全的數(shù)據(jù)：

Error:Table'p'ismarkedascrashedandshouldberepaired

打開表失?。?/p>

Can'topenfile:'xxx.MYI'(ermo:145)[考點]備份恢復

16.

數(shù)據(jù)表損壞的修復方式有哪些?正確答案：可以使用myisamchk來修復，具體步驟如下：

1)修復前將mysqld服務停止。

2)打開命令行方式，然后進入mysql的/bin目錄。

3)執(zhí)行myisamchk-recover數(shù)據(jù)庫所在路徑/*.MYI。

使用repairtable或者OPTIMIZEtable命令來修復，REPAIRTABLEtable_name修復表，OPTIMIZETABLEtable_name優(yōu)化表，REPAIRTABLE用于修復被破壞的表。

OPTIMIZETABLE用于回收閑置的數(shù)據(jù)庫空間，當表上的數(shù)據(jù)行被刪除時，所占據(jù)的磁盤空間并沒有立即被回收，使用了OPTIMIZETABLE命令后這些空間將被回收，并且對磁盤上的數(shù)據(jù)行進行重排(注意：是磁盤上，而非數(shù)據(jù)庫)。[考點]備份恢復

17.

MySQL有哪幾個默認數(shù)據(jù)庫?正確答案：在MySQL中，數(shù)據(jù)庫也可以稱為Schema。在安裝MySQL后，默認有informationschema、mysql、performance_schema和sys這幾個數(shù)據(jù)庫，如下：

1.數(shù)據(jù)庫information_schema

information_schema是信息數(shù)據(jù)庫，是MySQL5.0新增的一個數(shù)據(jù)庫，其中保存著關于MySQL服務器所維護的所有其他數(shù)據(jù)庫的信息。information_schema提供了訪問數(shù)據(jù)庫元數(shù)據(jù)的方式。元數(shù)據(jù)是關于數(shù)據(jù)的數(shù)據(jù)，例如，數(shù)據(jù)庫名或表名、列的數(shù)據(jù)類型、訪問權限等。information_schema是一個虛擬數(shù)據(jù)庫，有數(shù)個只讀表，它們實際上是視圖，而不是基本表，因此，無法看到與之相關的任何文件。

2.數(shù)據(jù)庫mysql

這個是MySQL的核心數(shù)據(jù)庫，主要存儲著數(shù)據(jù)庫的用戶、權限設置、MySQL自己需要使用的控制和管理信息。它不可以被刪除，如果對MySQL不是很了解，那么也不要輕易修改這個數(shù)據(jù)庫里面的表信息。

3.數(shù)據(jù)庫performance_schema

這是從MySOL5.5版本開始新增的一個數(shù)據(jù)庫，主要用于收集數(shù)據(jù)庫服務器性能數(shù)據(jù)，需要設置參數(shù)performance_schema才可以啟動該功能。這個功能從MySQL5.6.6開始，默認是開啟的(在MySQL5.6.6版本以下默認是關閉的)，其值為1或ON表示啟用，為0或OFF表示關閉。需要注意的是，該參數(shù)是靜態(tài)參數(shù)，只能寫在f中，不能動態(tài)修改。

4.數(shù)據(jù)庫sys

MySOL5.7提供了sys系統(tǒng)數(shù)據(jù)庫。sys數(shù)據(jù)庫結合了information_schema和performance_schema的相關數(shù)據(jù)，里面包含了一系列的存儲過程、自定義函數(shù)以及視圖來幫助DBA快速地了解系統(tǒng)的元數(shù)據(jù)信息，為DBA解決性能瓶頸提供了巨大幫助。sys數(shù)據(jù)庫目前只包含一個表，表名為sys_config。

另外需要注意的一點是，在MySQL5.7以前還存在一個默認的test庫，用于測試，而在MySQL5.7及其之后的版本中去掉了該庫。

18.

MySQL區(qū)分大小寫嗎?正確答案：在MySQL中，一個數(shù)據(jù)庫會對應一個文件夾，數(shù)據(jù)庫里的表則以文件的方式存放在文件夾內(nèi)，所以，操作系統(tǒng)對大小寫的敏感性決定了數(shù)據(jù)庫和表的大小寫敏感。其實，在MySQL中，有一個只讀的系統(tǒng)變量“l(fā)ower_case_file_system”，其值反映的正是當前文件系統(tǒng)是否區(qū)分大小寫。所以，MySQL在Windows下是不區(qū)分大小寫的，而在Linux下數(shù)據(jù)庫名、表名、列名、別名大小寫規(guī)則是這樣的：

1)數(shù)據(jù)庫名與表名是嚴格區(qū)分大小寫的，但是，可以在/etc/f中添加lowerl_case_table_names=1，然后重啟MySQL服務，這樣就不區(qū)分表名的大小寫了。當lower_case_table_names為0時表示區(qū)分大小寫，為1時表示不區(qū)分大小寫。

2)表的別名是嚴格區(qū)分大小寫的。

3)列名與列的別名在所有的情況下均是忽略大小寫的。

4)變量名也是嚴格區(qū)分大小寫的。

另外需要說明的一點是，MySQL在查詢字符串時是大小寫不敏感的。如果想在查詢時區(qū)分字段值的大小寫，那么字段值需要設置BINARY屬性。

關鍵字、函數(shù)名、存儲過程和事件的名字不區(qū)分字母的大小寫。例如，abs、bin、now、version、floor等函數(shù)和SELECT、WHERE、ORDER、GROUPBY等關鍵字。觸發(fā)器的名字要區(qū)分字母的大小寫。

19.

什么是MySQL的復制(Replication)?正確答案：MySQL內(nèi)建的復制功能是構建大型、高