數(shù)據(jù)庫的問題，
- 資格考試
- 2023-02-11 07:56:21
數(shù)據(jù)庫老師會問哪些問題？
1.MySQL 主鍵與索引的聯(lián)系與區(qū)別
主鍵是為了標識數(shù)據(jù)庫記錄唯一性，不允許記錄重復(fù)，且鍵值不能為空，主鍵也是一個特殊索引。
數(shù)據(jù)表中只允許有一個主鍵，但是可以有多個索引。
使用主鍵會數(shù)據(jù)庫會自動創(chuàng)建主索引，也可以在非主鍵上創(chuàng)建索引，方便查詢效率。
索引可以提高查詢速度，它就相當(dāng)于字典的目錄，可以通過它很快查詢到想要的結(jié)果，而不需要進行全表掃描。
主鍵索引外索引的值可以為空。
主鍵也可以由多個字段組成，組成復(fù)合主鍵，同時主鍵肯定也是唯一索引。
唯一索引則表示該索引值唯一，可以由一個或幾個字段組成，一個表可以有多個唯一索引。
2.數(shù)據(jù)庫索引是怎么回事？用的啥數(shù)據(jù)結(jié)構(gòu) 為什么B+樹比B樹更合適
一個索引是存儲的表中一個特定列的值數(shù)據(jù)結(jié)構(gòu)（最常見的是B-Tree）。索引是在表的列上創(chuàng)建。所以，要記住的關(guān)鍵點是索引包含一個表中列的值，并且這些值存儲在一個數(shù)據(jù)結(jié)構(gòu)中。請記住記住這一點：索引是一種數(shù)據(jù)結(jié)構(gòu) 。
什么樣的數(shù)據(jù)結(jié)構(gòu)可以作為索引？
B-Tree 是最常用的用于索引的數(shù)據(jù)結(jié)構(gòu)。因為它們是時間復(fù)雜度低， 查找、刪除、插入操作都可以可以在對數(shù)時間內(nèi)完成。另外一個重要原因存儲在B-Tree中的數(shù)據(jù)是有序的。數(shù)據(jù)庫管理系統(tǒng)（RDBMS）通常決定索引應(yīng)該用哪些數(shù)據(jù)結(jié)構(gòu)。但是，在某些情況下，你在創(chuàng)建索引時可以指定索引要使用的數(shù)據(jù)結(jié)構(gòu)。
當(dāng)我們利用索引查詢的時候，不可能把整個索引全部加載到內(nèi)存，只能逐一加載每個磁盤頁，磁盤頁對應(yīng)索引樹的節(jié)點。那么Mysql衡量查詢效率的標準就是磁盤IO次數(shù)。如果我們利用二叉樹作為索引結(jié)構(gòu)，那么磁盤的IO次數(shù)和索引樹的高度是相關(guān)的。
那么為了提高查詢效率，就需要減少磁盤IO數(shù)。為了減少磁盤IO的次數(shù)，就需要盡量降低樹的高度，需要把原來“瘦高”的樹結(jié)構(gòu)變的“矮胖”，樹的每層的分叉越多越好，因此B樹正好符合我們的要求，這也是B-樹的特征之一。
B樹 B樹的節(jié)點為關(guān)鍵字和相應(yīng)的數(shù)據(jù)（索引等）
B+樹 B+樹是B樹的一個變形，非葉子節(jié)點只保存索引，不保存實際的數(shù)據(jù)，數(shù)據(jù)都保存在葉子節(jié)點中，B+樹的葉子節(jié)點為鏈表，鏈表放數(shù)據(jù)，非葉子節(jié)點是索引。
對比：
B樹和B+樹同樣適用于高度越低，查詢越快。
B樹查找節(jié)點，B+樹只需要查詢所有節(jié)點（索引），B樹查詢索引和數(shù)據(jù)。雖然可能第一個就找到，但在極端情況下，需要全查詢索引和數(shù)據(jù)，不如B+樹穩(wěn)定。
B+樹和B樹比，B+樹的硬盤空間更少，io的讀寫代價更低。因為B+樹節(jié)點只有索引，占位更少。在查詢的情況下硬盤指針移動更低
表的主鍵、外鍵必須有索引；
數(shù)據(jù)量超過300的表應(yīng)該有索引；
經(jīng)常與其他表進行連接的表，在連接字段上應(yīng)該建立索引；
經(jīng)常出現(xiàn)在Where子句中的字段，特別是大表的字段，應(yīng)該建立索引；
索引應(yīng)該建在選擇性高的字段上；
索引應(yīng)該建在小字段上，對于大的文本字段甚至超長字段，不要建索引；
復(fù)合索引的建立需要進行仔細分析；盡量考慮用單字段索引代替
頻繁進行數(shù)據(jù)操作的表，不要建立太多的索引；
刪除無用的索引，避免對執(zhí)行計劃造成負面影響；
限制表上的索引數(shù)目。對一個存在大量更新操作的表，所建索引的數(shù)目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數(shù)據(jù)的更新操作。
避免在取值朝一個方向增長的字段（例如：日期類型的字段）上，建立索引；對復(fù)合索引，避免將這種類型的字段放置在最前面
對復(fù)合索引，按照字段在查詢條件中出現(xiàn)的頻度建立索引
刪除不再使用，或者很少被使用的索引。
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數(shù)據(jù)類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全并后的原子性執(zhí)行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
表級鎖：開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。
行級鎖：開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。
頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般
哈希表索引是怎么工作的？
哈希表是另外一種你可能看到用作索引的數(shù)據(jù)結(jié)構(gòu)-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對于比較字符串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(SELECT * FROM Employee WHERE Employee_Name = ‘Jesus’) 就可以受益于創(chuàng)建在Employee_Name 列上的哈希索引。哈系索引的工作方式是將列的值作為索引的鍵值（key），和鍵值相對應(yīng)實際的值（value）是指向該表中相應(yīng)行的指針。因為哈希表基本上可以看作是關(guān)聯(lián)數(shù)組，一個典型的數(shù)據(jù)項就像“Jesus => 0x28939″，而0x28939是對內(nèi)存中表中包含Jesus這一行的引用。在哈系索引的中查詢一個像“Jesus”這樣的值，并得到對應(yīng)行的在內(nèi)存中的引用，明顯要比掃描全表獲得值為“Jesus”的行的方式快很多。
哈希索引的缺點
哈希表是無順的數(shù)據(jù)結(jié)構(gòu)，對于很多類型的查詢語句哈希索引都無能為力。舉例來說，假如你想要找出所有小于40歲的員工。你怎么使用使用哈希索引進行查詢？這不可行，因為哈希表只適合查詢鍵值對-也就是說查詢相等的查詢（例：like “WHERE name = ‘Jesus’）。哈希表的鍵值映射也暗示其鍵的存儲是無序的。這就是為什么哈希索引通常不是數(shù)據(jù)庫索引的默認數(shù)據(jù)結(jié)構(gòu)-因為在作為索引的數(shù)據(jù)結(jié)構(gòu)時，其不像B-Tree那么靈活
3.創(chuàng)建索引的注意事項
索引可以提高數(shù)據(jù)的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應(yīng)用程序的業(yè)務(wù)處理、數(shù)據(jù)使用，為經(jīng)常被用作查詢條件、或者被要求排序的字段建立索引。索引是建立在數(shù)據(jù)庫表中的某些列的上面。因此，在創(chuàng)建索引的時候，應(yīng)該仔細考慮在哪些列上可以創(chuàng)建索引，在哪些列上不能創(chuàng)建索引。
創(chuàng)建規(guī)則：
創(chuàng)建索引需要注意的地方：
4.MYSQL事務(wù)特性和實現(xiàn)原理
ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（durability）。一個很好的事務(wù)處理系統(tǒng)，必須具備這些標準特性：
原子性（atomicity）
一個事務(wù)必須被視為一個不可分割的最小工作單元，整個事務(wù)中的所有操作要么全部提交成功，要么全部失敗回滾，對于一個事務(wù)來說，不可能只執(zhí)行其中的一部分操作，這就是事務(wù)的原子性
是利用Innodb的undo log。undo log名為回滾日志，是實現(xiàn)原子性的關(guān)鍵，當(dāng)事務(wù)回滾時能夠撤銷所有已經(jīng)成功執(zhí)行的sql語句，他需要記錄你要回滾的相應(yīng)日志信息。
一致性（consistency）
數(shù)據(jù)庫總是從一個一致性的狀態(tài)轉(zhuǎn)換到另一個一致性的狀態(tài)。（在前面的例子中，一致性確保了，即使在執(zhí)行第三、四條語句之間時系統(tǒng)崩潰，支票賬戶中也不會損失200美元，因為事務(wù)最終沒有提交，所以事務(wù)中所做的修改也不會保存到數(shù)據(jù)庫中。）
數(shù)據(jù)庫通過原子性、隔離性、持久性來保證一致性
隔離性（isolation）
通常來說，一個事務(wù)所做的修改在最終提交以前，對其他事務(wù)是不可見的。（在前面的例子中，當(dāng)執(zhí)行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶匯總程序開始運行，則其看到支票帳戶的余額并沒有被減去200美元。）
利用的是鎖和MVCC機制。MVCC,即多版本并發(fā)控制(Multi Version Concurrency Control),一個行記錄數(shù)據(jù)有多個版本對快照數(shù)據(jù)，這些快照數(shù)據(jù)在undo log中。如果一個事務(wù)讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。
持久性（durability）
一旦事務(wù)提交，則其所做的修改會永久保存到數(shù)據(jù)庫。（此時即使系統(tǒng)崩潰，修改的數(shù)據(jù)也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的持久性保證的策略。）
是利用Innodb的redo log。當(dāng)做數(shù)據(jù)修改的時候，不僅在內(nèi)存中操作，還會在redo log中記錄這次操作。當(dāng)事務(wù)提交的時候，會將redo log日志進行刷盤(redo log一部分在內(nèi)存中，一部分在磁盤上)。當(dāng)數(shù)據(jù)庫宕機重啟的時候，會將redo log中的內(nèi)容恢復(fù)到數(shù)據(jù)庫中，再根據(jù)undo log和binlog內(nèi)容決定回滾數(shù)據(jù)還是提交數(shù)據(jù)。redo log體積小，刷盤快。redo log是一直往末尾進行追加，屬于順序IO。效率顯然比隨機IO來的快
5.redis的原理和優(yōu)點
redis是一個key-value存儲系統(tǒng).和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希類型）
這些數(shù)據(jù)類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的.
在此基礎(chǔ)上，redis支持各種不同方式的排序.與memcached一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中.區(qū)別的是redis會周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實現(xiàn)了master-slave(主從)同步.
Redis的優(yōu)點:
6.Mysql中的鎖機制
Mysql用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。這些鎖統(tǒng)稱為悲觀鎖
MySQL的鎖機制比較簡單，其最 顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎采用的是表級鎖（table-level locking）；BDB存儲引擎采用的是頁面鎖（page-level locking），但也支持表級鎖；InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認情況下是采用行級鎖。
從上述特點可見，很難籠統(tǒng)地說哪種鎖更好，只能就具體應(yīng)用的特點來說哪種鎖更合適！僅從鎖的角度 來說：表級鎖更適合于以查詢?yōu)橹?，只有少量按索引條件更新數(shù)據(jù)的應(yīng)用，如Web應(yīng)用；而行級鎖則更適合于有大量按索引條件并發(fā)更新少量不同數(shù)據(jù)，同時又有 并發(fā)查詢的應(yīng)用，如一些在線事務(wù)處理（OLTP）系統(tǒng)。
7.ABC聯(lián)合索引生效問題
對于復(fù)合索引：Mysql從左到右的使用索引中的字段，一個查詢可以只使用索引中的一部份，但只能是最左側(cè)部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當(dāng)最左側(cè)字段是常量引用時，索引就十分有效。
對于復(fù)合索引：Mysql從左到右的使用索引中的字段，一個查詢可以只使用索引中的一部份，但只能是最左側(cè)部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當(dāng)最左側(cè)字段是常量引用時，索引就十分有效。
關(guān)于數(shù)據(jù)庫的問題？
下列軟件不屬于數(shù)據(jù)庫管理系統(tǒng)的是(UNIX )。 UNIX ORACLE FOXPRO SQL SERVER DBS是采用了數(shù)據(jù)庫技術(shù)的計算機系統(tǒng)。DBS是一個集合體，包含數(shù)據(jù)庫、計算機硬件、軟件和(數(shù)據(jù)庫管理員) 。 系統(tǒng)分析員 程序員 數(shù)據(jù)庫管理員 操作員 對某個具體的數(shù)據(jù)庫應(yīng)用來說，下列說法中正確的是(以上三個都不是唯一的) 。 E-R 圖是唯一的 數(shù)據(jù)模型是唯一的 數(shù)據(jù)庫文件是唯一的 以上三個都不是唯一的 以下不屬于數(shù)據(jù)庫系統(tǒng)組成的是(文件系統(tǒng) )。 硬件系統(tǒng) 數(shù)據(jù)庫管理系統(tǒng)及相關(guān)軟件 數(shù)據(jù)庫管理員(DBA) 文件系統(tǒng) 下列四項中說法不正確的是(數(shù)據(jù)庫避免了一切數(shù)據(jù)的重復(fù))。 數(shù)據(jù)庫減數(shù)據(jù)庫面試常問問題有哪些?
1、什么是數(shù)據(jù)庫事務(wù)
數(shù)據(jù)庫事務(wù)是構(gòu)成單一邏輯工作單元的操作集合。數(shù)據(jù)庫事務(wù)可以包括一個或多個數(shù)據(jù)庫操作，但是這些操作構(gòu)成一個邏輯上的整體。
2、數(shù)據(jù)庫事務(wù)的四個特性（ACID）
A：原子性，事務(wù)中的所有操作作為一個整體不可分割，要么全部操作要么全部不操作。
C：一致性，事務(wù)的執(zhí)行結(jié)果必須使數(shù)據(jù)庫從一個一致性狀態(tài)轉(zhuǎn)為另一個一致性狀態(tài)。一致性狀態(tài)：1.系統(tǒng)狀態(tài)滿足數(shù)據(jù)庫的完整性約束，2.系統(tǒng)的狀態(tài)反映數(shù)據(jù)庫所描述的現(xiàn)實世界的真實狀態(tài)。
I：隔離性：并發(fā)執(zhí)行的事務(wù)不會相互影響，其對數(shù)據(jù)庫的影響和他們串行執(zhí)行時一樣。
D：持久性：事務(wù)一旦提交，對數(shù)據(jù)庫的影響就是持久的。任何事務(wù)或系統(tǒng)故障都不會導(dǎo)致數(shù)據(jù)丟失。
3、什么是數(shù)據(jù)庫連接泄露
數(shù)據(jù)庫連接泄露指的是如果在某次使用或者某段程序中沒有正確地關(guān)閉Connection、Statement和ResultSet資源，那么每次執(zhí)行都會留下一些沒有關(guān)閉的連接，這些連接失去了引用而不能得到重新使用，因此就造成了數(shù)據(jù)庫連接的泄漏。數(shù)據(jù)庫連接的資源是寶貴而且是有限的，如果在某段使用頻率很高的代碼中出現(xiàn)這種泄漏，那么數(shù)據(jù)庫連接資源將被耗盡，影響系統(tǒng)的正常運轉(zhuǎn)。
4、聚集索引
數(shù)據(jù)行的物理順序與列值的順序相同，如果我們查詢id比較靠后的數(shù)據(jù)，那么這行數(shù)據(jù)的地址在磁盤中的物理地址也會比較靠后。而且由于物理排列方式與聚集索引的順序相同，所以也就只能建立一個聚集索引了。
5、主鍵與外鍵
關(guān)系型數(shù)據(jù)庫中的一條記錄中有若干個屬性，若其中某一個屬性組（注意是組）能唯一標識一條記錄，該屬性組就可以成為一個主鍵。
外鍵用于與另一張表的關(guān)聯(lián)。是能確定另一張表記錄的字段，用于保持數(shù)據(jù)的一致性。比如，A表中的一個字段，是B表的主鍵，那他就可以是A表的外鍵。
