面試題一數據庫
-
事務四大特性(ACID)
- 原子性：不可分割的操作單元，事務中所以操作，要麼全部成功，要麼測回到執行事務之前的狀態
- 一致性：如果在執行事務之前數據庫是一致的，那麼執行事務之後數據庫也還是一致的。如：轉賬業務，無論事務執行成功與否，參與轉賬的兩個賬號餘額之和應該是不變的。
- 隔離性：事務操作之間彼此獨立和透明互不影響，不同事務之間應該隔離開來
- 持久性：一旦事務提交成功，事務中所有的數據操作都必須被持久化到數據庫中，即使提交事務後，數據庫馬上崩潰，在數據庫重啓時，也必須能保證通過某種機制恢復數據。
-
數據庫隔離級別
-
髒讀：未提交讀Read uncommited 不添加共享鎖
分爲兩種情況：
- 事務B可以在事務A對記錄的讀取過程中修改同一記錄，可能會導致事務A讀取的數據是一個被破壞的或者是不完整的數據。
- 在事務A中可以讀取到事務B中修改過的數據，但是事務B尚未提交，可能會發送的問題就是髒讀
-
不可重複讀：已提交讀Read commited
在事務A中讀取數據時對記錄添加共享鎖，待讀取結束後纔會立即釋放該鎖。那麼事務B對該數據的修改要一直等待，直到A中的讀取過程結束，但不是整個事務A的結束。所以，可能發生的問題就是事務A在不同階段對同一記錄的讀取結果可能是不同的。
-
幻讀：可重複讀Repeatable read
系統管理員A將數據庫中所有學生的成績從具體分數改爲ABCDE等級，但是系統管理員B就在這個時候插入了一條具體分數的記錄，當系統管理員A改結束後發現還有一條記錄沒有改過來，就好像發生了幻覺一樣，這就叫幻讀。InnoDB 默認的事務隔離級別就是可重複讀**。**可能發生的問題：當執行一個範圍查詢時，可能會發生幻讀（解決幻讀的方法：增加範圍鎖RangeS，鎖定檢索範圍爲只讀，這樣就避免了幻讀）。
-
-
數據庫三範式
-
第一範式(1NF):列不可拆分
只數據庫表的每一列都是不可分割的基本數據項，同一列中不可能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。
-
第二範式(2NF):不能部分依賴
滿足第二範式必須先滿足第一範式。實體的屬性完全依賴於主鍵。所謂完全依賴是指不存在僅依賴主鍵一部分的屬性。如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。
-
第三範式(3NF):外鍵約束
滿足第三範式必須先滿足第二範式。要求表中不能有其他表中存在的、存儲相同信息的字段，通常實現是在通過外鍵去建立關聯，因此第三範式只要記住外鍵約束就好了。
-
-
說一說你能想到的sql的優化？
避免select *，將需要查找的字段列出來
使用連接(join)來代替子查詢
用exists代替in
使用limit對查詢記錄進行限定
儘量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描
儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。儘量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描
-
什麼是數據庫索引？
數據庫索引，是數據庫管理系統中一個排序的數據結構，以協助快速查詢、更新數據庫表中數據。索引通常使用B_Tree。B_Tree索引加速了數據訪問，因爲存儲引擎不會再去掃描整張表得到數據；相反，它從根節點開始，根節點保存了子節點的指針，存儲引擎會根據指針快速尋找數據。
-
MySQL數據庫的四類索引
index --普通索引，數據可以重複，沒有任何限制
unique --唯一索引，要求索引列的值必須唯一，但允許有空值
primary key --主鍵索引，是一種特殊的唯一索引，一個表只能有一個主鍵，不允許空值，一般是在創建表的同時創建主鍵索引
組合索引 --多個字段上創建的索引，只有在查詢條件中使用了創建索引時的第一個字段，索引纔會被使用。
fulltext – 全文索引,是對於大表的文本域：char，varchar，text列才能創建全文索引，主要用於查找文本中的關鍵字，並不是直接與索引中的值進行比較。fulltext更像是一個搜索引擎，配合match against操作使用，而不是一般的where語句加like。
注:全文索引目前只有MyISAM存儲引擎支持全文索引，InnoDB引擎5.6以下版本還不支持全文索引
所有存儲引擎對每個表至少支持16個索引，總索引長度至少爲256字節，索引有兩種存儲類型，包括B型樹索引和哈希索引。
-
爲什麼使用B+樹做索引而不使用哈希表做索引？
- 哈希表是把索引字段映射成對應的哈希碼然後再存放在對應的位置，這樣的話，如果我們要進行模糊查找的話，顯然哈希表這種結構是不支持的，只能遍歷這個表。而B+樹則可以通過最左前綴原則快速找到對應的數據。
- 如果我們要進行範圍查找，例如查找ID爲100 ~ 400的人，哈希表同樣不支持，只能遍歷全表。
- 索引字段通過哈希映射成哈希碼，如果很多字段都剛好映射到相同值的哈希碼的話，那麼形成的索引結構將會是一條很長的鏈表，這樣的話，查找的時間就會大大增加。
-
聚簇索引和非聚簇索引，在查詢數據的時候有什麼區別？
聚簇索引查詢比較快
因爲主鍵索引樹的葉子節點直接就是我們要查詢的整行數據了。而非主鍵索引的葉子節點是主鍵的值，查到主鍵的值以後，還需要再通過主鍵的值再進行一次查詢
-
索引的優缺點，什麼時候使用索引，什麼時候不能使用索引？
優點：提高查詢效率
缺點：更新數據時效率低，因爲要同時更新索引
對數據庫進行頻繁查詢時要建立索引，如果要頻繁更改數據時不建議使用索引
-
存儲引擎MyISAM和InnoDB的區別？
1）InnoDB支持事務，MyISAM不支持。
2）MyISAM適合查詢以及插入爲主的應用，InnoDB適合頻繁修改以及涉及到安全性較高的應用。
3）InnoDB支持外鍵，MyISAM不支持。
4）從MySQL5.5.5以後，InnoDB是默認引擎。
5）MyISAM支持全文類型索引，而InnoDB不支持全文索引。
6）InnoDB中不保存表的總行數，select count() from table時，InnoDB需要掃描整個表計算有多少行，但MyISAM只需簡單讀出保存好的總行數即可。注：當count()語句包含where條件時MyISAM也需掃描整個表。
現在一般都選用InnoDB，主要是MyISAM的全表鎖，讀寫串行問題，併發效率鎖表，效率低，MyISAM對於讀寫密集型應用一般是不會去選用的。
應用場景：
- MyISAM不支持事務處理等高級功能，但它提供高速存儲和檢索，以及全文搜索能力。如果應用中需要執行大量的SELECT查詢，那麼MyISAM是更好的選擇。
- InnoDB用於需要事務處理的應用程序，包括ACID事務支持。如果應用中需要執行大量的INSERT或UPDATE操作，則應該使用InnoDB，這樣可以提高多用戶併發操作的性能。
-
char和varchar的區別？
- CHAR列長度固定爲創建表時聲明的長度，長度值範圍是1到255
- 當CHAR值被存儲時，它們被用空格填充到特定長度，檢索CHAR值時需刪除尾隨空格。
-
delete、drop、truncate區別？
- truncate 和 delete只刪除數據，不刪除表結構 ,drop刪除表結構，並且釋放所佔的空間。
- **刪除數據的速度，**drop> truncate > delete
- delete屬於DML語言，需要事務管理，commit之後才能生效。drop和truncate屬於DDL語言，操作立刻生效，不可回滾。
- 使用場合：
- 當你不再需要該表時， 用 drop;
- 當你仍要保留該表，但要刪除所有記錄時， 用 truncate;
- 當你要刪除部分記錄時（always with a where clause), 用 delete.