資料庫問題

A. 關於資料庫的幾個問題

1.C
2.A
3.A
4.錯誤
5.錯誤
6.正確
7.
外模式
-模式，模式-內模式
8.
數據結構化
，（
數據共享
性高、
冗餘度
低、易擴充）
9.
關系模型
，
面向對象模型
12.數據的安全性保護，數據的完整性保護
15.
實體完整性
，
參照完整性
16.外模式，模式

B. 當資料庫出現問題怎麼辦

資料庫出現問題，首要的是盡快備份資料庫，如果資料庫損壞的話，找出最近日期的數據備份。
確認有資料庫備份後，根據資料庫錯誤的提示，一步一步地解決的，如果不是資料庫損壞，問題解決都不是很大的，如果是資料庫損壞的話，麻煩可就大了，只能考慮利用以前的資料庫備份了的

C. 關於資料庫的問題

下列軟體不屬於資料庫管理系統的是(UNIX )。
UNIX
ORACLE
FOXPRO
SQL SERVER
DBS是採用了資料庫技術的計算機系統。DBS是一個集合體，包含資料庫、計算機硬體、軟體和(資料庫管理員) 。
系統分析員
程序員
資料庫管理員
操作員
對某個具體的資料庫應用來說，下列說法中正確的是(以上三個都不是唯一的) 。
E-R 圖是唯一的
數據模型是唯一的
資料庫文件是唯一的
以上三個都不是唯一的
以下不屬於資料庫系統組成的是(文件系統 )。
硬體系統
資料庫管理系統及相關軟體
資料庫管理員(DBA)
文件系統
下列四項中說法不正確的是(資料庫避免了一切數據的重復)。
資料庫減少了數據冗餘
資料庫中的數據可以共享
資料庫避免了一切數據的重復
資料庫具有較高的數據獨立性
與文件管理系統相比，(訪問速度快)不是資料庫系統的優點。
數據結構化 (數據結構化是資料庫與文件系統的根本區別。)
訪問速度快 (文件管理系統速度要比把文件內容放在資料庫中快)
數據獨立性
冗餘度可控
下列四項中，不屬於關系資料庫特點的是(數據冗餘小)。
數據冗餘小
數據獨立性高
數據共享性好
多用戶訪問
根據關系數據基於的數據模型-關系模型的特徵判斷下列正確的一項: ( 以二維表格結構來保存數據，在關系表中不允許有重復行存在) 。
只存在一對多的實體關系，以圖形方式來表示
以二維表格結構來保存數據，在關系表中不允許有重復行存在
能體現一對多、多對多的關系，但不能體現一對一的關系
關系模型資料庫是資料庫發展的最初階段
用樹型結構表示實體間聯系的模型是(層次模型)。
關系模型
網狀模型
層次模型
以上三個都是
(層次模型:用樹型結構表示實體間聯系的數據模型)
關系資料庫用(二維表)來表示實體之間的聯系。
樹結構
網結構
二維表
線性表
(關系模型：使用最廣泛的一種資料庫模型。方法：用若干個二維表來表示實體以及實體之間的聯系。)

D. 資料庫老師會問哪些問題

1.MySQL 主鍵與索引的聯系與區別

主鍵是為了標識資料庫記錄唯一性，不允許記錄重復，且鍵值不能為空，主鍵也是一個特殊索引。

數據表中只允許有一個主鍵，但是可以有多個索引。

使用主鍵會資料庫會自動創建主索引，也可以在非主鍵上創建索引，方便查詢效率。

索引可以提高查詢速度，它就相當於字典的目錄，可以通過它很快查詢到想要的結果，而不需要進行全表掃描。

主鍵索引外索引的值可以為空。

主鍵也可以由多個欄位組成，組成復合主鍵，同時主鍵肯定也是唯一索引。

唯一索引則表示該索引值唯一，可以由一個或幾個欄位組成，一個表可以有多個唯一索引。

2.資料庫索引是怎麼回事？用的啥數據結構 為什麼B+樹比B樹更合適

一個索引是存儲的表中一個特定列的值數據結構（最常見的是B-Tree）。索引是在表的列上創建。所以，要記住的關鍵點是索引包含一個表中列的值，並且這些值存儲在一個數據結構中。請記住記住這一點：索引是一種數據結構 。

什麼樣的數據結構可以作為索引？

B-Tree 是最常用的用於索引的數據結構。因為它們是時間復雜度低， 查找、刪除、插入操作都可以可以在對數時間內完成。另外一個重要原因存儲在B-Tree中的數據是有序的。資料庫管理系統（RDBMS）通常決定索引應該用哪些數據結構。但是，在某些情況下，你在創建索引時可以指定索引要使用的數據結構。

當我們利用索引查詢的時候，不可能把整個索引全部載入到內存，只能逐一載入每個磁碟頁，磁碟頁對應索引樹的節點。那麼Mysql衡量查詢效率的標准就是磁碟IO次數。如果我們利用二叉樹作為索引結構，那麼磁碟的IO次數和索引樹的高度是相關的。

那麼為了提高查詢效率，就需要減少磁碟IO數。為了減少磁碟IO的次數，就需要盡量降低樹的高度，需要把原來「瘦高」的樹結構變的「矮胖」，樹的每層的分叉越多越好，因此B樹正好符合我們的要求，這也是B-樹的特徵之一。

B樹 B樹的節點為關鍵字和相應的數據（索引等）

B+樹 B+樹是B樹的一個變形，非葉子節點只保存索引，不保存實際的數據，數據都保存在葉子節點中，B+樹的葉子節點為鏈表，鏈表放數據，非葉子節點是索引。

對比：

• B樹和B+樹同樣適用於高度越低，查詢越快。

• B樹查找節點，B+樹只需要查詢所有節點（索引），B樹查詢索引和數據。雖然可能第一個就找到，但在極端情況下，需要全查詢索引和數據，不如B+樹穩定。

• B+樹和B樹比，B+樹的硬碟空間更少，io的讀寫代價更低。因為B+樹節點只有索引，佔位更少。在查詢的情況下硬碟指針移動更低

哈希表索引是怎麼工作的？

哈希表是另外一種你可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字元串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(SELECT * FROM Employee WHERE Employee_Name = 『Jesus』) 就可以受益於創建在Employee_Name 列上的哈希索引。哈系索引的工作方式是將列的值作為索引的鍵值（key），和鍵值相對應實際的值（value）是指向該表中相應行的指針。因為哈希表基本上可以看作是關聯數組，一個典型的數據項就像「Jesus => 0x28939″，而0x28939是對內存中表中包含Jesus這一行的引用。在哈系索引的中查詢一個像「Jesus」這樣的值，並得到對應行的在內存中的引用，明顯要比掃描全表獲得值為「Jesus」的行的方式快很多。

哈希索引的缺點

哈希表是無順的數據結構，對於很多類型的查詢語句哈希索引都無能為力。舉例來說，假如你想要找出所有小於40歲的員工。你怎麼使用使用哈希索引進行查詢？這不可行，因為哈希表只適合查詢鍵值對-也就是說查詢相等的查詢（例：like 「WHERE name = 『Jesus』）。哈希表的鍵值映射也暗示其鍵的存儲是無序的。這就是為什麼哈希索引通常不是資料庫索引的默認數據結構-因為在作為索引的數據結構時，其不像B-Tree那麼靈活

3.創建索引的注意事項

索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的欄位建立索引。索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。

創建規則：

• 表的主鍵、外鍵必須有索引；

• 數據量超過300的表應該有索引；

• 經常與其他表進行連接的表，在連接欄位上應該建立索引；

• 經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；

• 索引應該建在選擇性高的欄位上；

• 索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；

• 復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替

• 頻繁進行數據操作的表，不要建立太多的索引；

• 刪除無用的索引，避免對執行計劃造成負面影響；

創建索引需要注意的地方：

• 限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。

• 避免在取值朝一個方向增長的欄位（例如：日期類型的欄位）上，建立索引；對復合索引，避免將這種類型的欄位放置在最前面

• 對復合索引，按照欄位在查詢條件中出現的頻度建立索引

• 刪除不再使用，或者很少被使用的索引。

4.MYSQL事務特性和實現原理

ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（rability）。一個很好的事務處理系統，必須具備這些標准特性：

原子性（atomicity）

一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性

是利用Innodb的undo log。undo log名為回滾日誌，是實現原子性的關鍵，當事務回滾時能夠撤銷所有已經成功執行的sql語句，他需要記錄你要回滾的相應日誌信息。

一致性（consistency）

資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。（在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會保存到資料庫中。）

資料庫通過原子性、隔離性、持久性來保證一致性

隔離性（isolation）

通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶匯總程序開始運行，則其看到支票帳戶的余額並沒有被減去200美元。）

利用的是鎖和MVCC機制。MVCC,即多版本並發控制(Multi Version Concurrency Control),一個行記錄數據有多個版本對快照數據，這些快照數據在undo log中。如果一個事務讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。

持久性（rability）

一旦事務提交，則其所做的修改會永久保存到資料庫。（此時即使系統崩潰，修改的數據也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的持久性保證的策略。）

是利用Innodb的redo log。當做數據修改的時候，不僅在內存中操作，還會在redo log中記錄這次操作。當事務提交的時候，會將redo log日誌進行刷盤(redo log一部分在內存中，一部分在磁碟上)。當資料庫宕機重啟的時候，會將redo log中的內容恢復到資料庫中，再根據undo log和binlog內容決定回滾數據還是提交數據。redo log體積小，刷盤快。redo log是一直往末尾進行追加，屬於順序IO。效率顯然比隨機IO來的快

5.redis的原理和優點

redis是一個key-value存儲系統.和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希類型）

這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的.

在此基礎上，redis支持各種不同方式的排序.與memcached一樣，為了保證效率，數據都是緩存在內存中.區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步.

Redis的優點:

• 性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。

• 豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。

• 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。

• 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。

6.Mysql中的鎖機制

Mysql用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。這些鎖統稱為悲觀鎖

MySQL的鎖機制比較簡單，其最 顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎採用的是表級鎖（table-level locking）；BDB存儲引擎採用的是頁面鎖（page-level locking），但也支持表級鎖；InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認情況下是採用行級鎖。

• 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。

• 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。

• 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般

從上述特點可見，很難籠統地說哪種鎖更好，只能就具體應用的特點來說哪種鎖更合適！僅從鎖的角度 來說：表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並發更新少量不同數據，同時又有 並發查詢的應用，如一些在線事務處理（OLTP）系統。

7.ABC聯合索引生效問題

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

E. 資料庫面試常問問題有哪些

1、什麼是資料庫事務

資料庫事務是構成單一邏輯工作單元的操作集合。資料庫事務可以包括一個或多個資料庫操作，但是這些操作構成一個邏輯上的整體。

2、資料庫事務的四個特性（ACID）

A：原子性，事務中的所有操作作為一個整體不可分割，要麼全部操作要麼全部不操作。

C：一致性，事務的執行結果必須使資料庫從一個一致性狀態轉為另一個一致性狀態。一致性狀態：1.系統狀態滿足資料庫的完整性約束，2.系統的狀態反映資料庫所描述的現實世界的真實狀態。

I：隔離性：並發執行的事務不會相互影響，其對資料庫的影響和他們串列執行時一樣。

D：持久性：事務一旦提交，對資料庫的影響就是持久的。任何事務或系統故障都不會導致數據丟失。

3、什麼是資料庫連接泄露

資料庫連接泄露指的是如果在某次使用或者某段程序中沒有正確地關閉Connection、Statement和ResultSet資源，那麼每次執行都會留下一些沒有關閉的連接，這些連接失去了引用而不能得到重新使用，因此就造成了資料庫連接的泄漏。資料庫連接的資源是寶貴而且是有限的，如果在某段使用頻率很高的代碼中出現這種泄漏，那麼資料庫連接資源將被耗盡，影響系統的正常運轉。

4、聚集索引

數據行的物理順序與列值的順序相同，如果我們查詢id比較靠後的數據，那麼這行數據的地址在磁碟中的物理地址也會比較靠後。而且由於物理排列方式與聚集索引的順序相同，所以也就只能建立一個聚集索引了。

5、主鍵與外鍵

關系型資料庫中的一條記錄中有若干個屬性，若其中某一個屬性組（注意是組）能唯一標識一條記錄，該屬性組就可以成為一個主鍵。

外鍵用於與另一張表的關聯。是能確定另一張表記錄的欄位，用於保持數據的一致性。比如，A表中的一個欄位，是B表的主鍵，那他就可以是A表的外鍵。

F. 如何處理資料庫並發問題

想要知道如何處理數據並發，自然需要先了解數據並發。

什麼是數據並發操作呢？
就是同一時間內，不同的線程同時對一條數據進行讀寫操作。

在互聯網時代，一個系統常常有很多人在使用，因此就可能出現高並發的現象，也就是不同的用戶同時對一條數據進行操作，如果沒有有效的處理，自然就會出現數據的異常。而最常見的一種數據並發的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數據，而多個用戶對在同一時間對庫存進行重寫，一個不小心就可能出現超賣的情況。

針對這種情況，我們如何有效的處理數據並發呢？

第一種方案、資料庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在MySQL的資料庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數據出現混亂。

這四種隔離級別分別是：

讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復讀（Repeated Read）
串列化（Serializable）
當然，不同的隔離級別，效率也是不同的，對於數據的一致性保證也就有不同的結果。而這些可能出現的又有哪些呢？

臟讀（dirty read）

當事務與事務之間沒有任何隔離的時候，就可能會出現臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務還沒提交，商家卻看到了這個訂單。而這時就會出現一種問題，當商家去操作這個訂單時，可能用戶A的訂單由於部分問題，導致數據回滾，事務沒有提交，這時商家的操作就會失去目標。

不可重復讀（unrepeatable read）

一個事務中，兩次讀操作出來的同一條數據值不同，就是不可重復讀。

例如：我們有一個事務A，需要去查詢一下商品庫存，然後做扣減，這時，事務B操作了這個商品，扣減了一部分庫存，當事務A再次去查詢商品庫存的時候，發現這一次的結果和上次不同了，這就是不可重復讀。

幻讀（phantom problem）

一個事務中，兩次讀操作出來的結果集不同，就是幻讀。

例如：一個事務A，去查詢現在已經支付的訂單有哪些，得到了一個結果集。這時，事務B新提交了一個訂單，當事務A再次去查詢時，就會出現，兩次得到的結果集不同的情況，也就是幻讀了。

那針對這些結果，不同的隔離級別可以干什麼呢？

「讀未提（Read Uncommitted）」能預防啥？啥都預防不了。

「讀提交（Read Committed）」能預防啥？使用「快照讀（Snapshot Read）」方式，避免「臟讀」，但是可能出現「不可重復讀」和「幻讀」。

「可重復讀（Repeated Red）」能預防啥？使用「快照讀（Snapshot Read）」方式，鎖住被讀取記錄，避免出現「臟讀」、「不可重復讀」，但是可能出現「幻讀」。

「串列化（Serializable）」能預防啥？有效避免「臟讀」、「不可重復讀」、「幻讀」，不過運行效率奇差。

好了，鎖說完了，但是，我們的資料庫鎖，並不能有效的解決並發的問題，只是盡可能保證數據的一致性，當並發量特別大時，資料庫還是容易扛不住。那解決數據並發的另一個手段就是，盡可能的提高處理的速度。

因為數據的IO要提升難度比較大，那麼通過其他的方式，對數據進行處理，減少資料庫的IO，就是提高並發能力的有效手段了。

最有效的一種方式就是：緩存
想要減少並發出現的概率，那麼讀寫的效率越高，讀寫的執行時間越短，自然數據並發的可能性就變小了，並發性能也有提高了。

還是用剛才的秒殺舉例，我們為的就是保證庫存的數據不出錯，賣出一個商品，減一個庫存，那麼，我們就可以將庫存放在內存中進行處理。這樣，就能夠保證庫存有序的及時扣減，並且不出現問題。這樣，我們的資料庫的寫操作也變少了，執行效率也就大大提高了。

當然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬碟，而Memcache不行，應該怎麼選擇，就看具體的使用場景了。

當然，緩存畢竟使用的范圍有限，很多的數據我們還是必須持久化到硬碟中，那我們就需要提高資料庫的IO能力，這樣避免一個線程執行時間太長，造成線程的阻塞。

那麼，讀寫分離就是另一種有效的方式了
當我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。

我們的讀庫就只需要執行讀，寫庫就只需要執行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。

G. 一般資料庫中容易存在哪些問題可以通過什麼途徑來解決這些問題

一般資料庫中容易存在四種問題，分別是：語句錯誤；用戶進程錯誤；網路故障；用戶錯誤。
語句錯誤：單個資料庫操作（選擇、插入、更新或刪除）失敗。可以嘗試在表中輸入無效的數據，與用戶合作來驗證並更改數據。
用戶進程錯誤：用戶非登出的異常退出用戶會話異常終止程序錯誤導致會話結束，對於上述錯誤，實例後台進程 PMON 會自動回滾未提交的事務，並釋放相關鎖資源。
網路故障：與資料庫的連接斷開。通過備份監聽程序、網路連接和網路介面卡可降低出現網路故障時影響系統可用性的可能性。
用戶錯誤：用戶成功完成了操作，但是操作不正確（刪除了表，或輸入了錯誤數據）。用戶可能會無意刪除或修改數據。如果發生這種情況， DBA 可能需要幫助用戶從錯誤中恢，如果用戶尚未提交或退出程序，則只可以回退操作。