三大範式：
1、單個字段不能繼續拆分，（個人理解：列具有原子性）
2、在第一範式的基礎上，每個表只描述一件事情。可以理解爲第二範式就是要有主鍵，要求其他字段都依賴於主鍵。
爲什麼要有主鍵——沒有主鍵就沒有唯一性，沒有唯一性在集合中就定位不到這行記錄，所以要有主鍵。
其他字段爲什麼要依賴於主鍵——因爲不依賴於主鍵，就找不到他們。更重要的是，其他字段組成的這行記錄和主鍵表示的是同一個東西，而主鍵是唯一的，它們只需要依賴於主鍵，也就成了唯一的。
舉例：
學生信息組成學生表，姓名可以做主鍵麼？
不能！因爲同名的話，就不唯一了，所以需要學號這樣的唯一編碼才行。
那麼其他字段依賴於主鍵是什麼意思？
就是“張三”同學的年齡和性別等字段，不能存儲別人的年齡性別，必須是他自己的，因爲張三的學號信息就決定了，這行記錄歸張三所有，不能給無關人員使用。
3、在第二範式的基礎上，表中不能存在冗餘字段（字段與字段之間不能冗餘）
三範式就是要消除傳遞依賴，方便理解，可以看做是“消除冗餘”。
消除冗餘應該比較好理解一些，就是各種信息只在一個地方存儲，不出現在多張表中。
比如說大學分了很多系（中文系、英語系、計算機系……），這個系別管理表信息有以下字段組成：
系編號，系主任，系簡介，系架構。
那麼再回到學生信息表，張三同學的年齡、性別、學號都有了，我能不能把他的系編號，系主任、系簡介也一起存着？
如果你問三範式，當然不行，因爲三範式不同意。
因爲系編號，系主任、系簡介已經存在系別管理表中，你再存入學生信息表，就是冗餘了。
三範式中說的傳遞依賴，就出現了。
這個時候學生信息表中，系主任信息是不是依賴於系編號了？而這個表的主鍵可是學號啊！
所以按照三範式，處理這個問題的時候，學生表就只能增加一個系編號字段。
這樣既能根據系編號找到系別信息，又避免了冗餘存儲的問題。
三大範式只是一般設計數據庫的基本理念，可以建立冗餘較小、結構合理的數據庫。如果有特殊情況，當然要特殊對待，數據庫設計最重要的是看需求跟性能，需求>性能>表結構。所以不能一味的去追求範式建立數據庫。
關於三大範式通俗理解的參考：https://blog.csdn.net/q957967519/article/details/81910547
事物的四大特性ACID：
1. 原子性(Atomicity)
>一個事務必須被視爲一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性，原子性關注的是狀態。
2. 一致性(Consistency)
>數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。事務執行的前後都是合法的數據狀態，不會違背任何的數據完整性，這就是“一致”的意思。當然這個含義中也隱含着對開發者的要求，就是不能寫出錯誤的事務邏輯，比如銀行的轉賬不能只加錢不減錢，這是應用層面的一致性要求。一致性關注數據的可見性。
3. 隔離性(Isolation)
>通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認爲只有該事務在使用系統。這種屬性有時稱爲串行化，爲了防止事務操作間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用於同一數據。
4. 持久性(Durability)
>一旦事務提交，則其所做的修改會永久保存到數據庫。（此時即使系統崩潰，修改的數據也不會丟失。）當事務被提交後就無法再回滾，如果想要撤銷一個已經提交的事務，那就只能執行一個效果與其相反的事務，這也是持久性的一種體現。
注意：
原子性和一致性的的側重點不同：原子性關注狀態，要麼全部成功，要麼全部失敗，不存在部分成功的狀態。而一致性關注數據的可見性，中間狀態的數據對外部不可見，只有最初狀態和最終狀態的數據對外可見 。
視圖：
視圖是一種基於查詢結果產生的虛擬表，視圖是一個虛擬表，實際它就是一條被封裝起來的 SQL 查詢語句。
- 在使用視圖時，就相當執行了被封裝的複雜SQL查詢語句。
- 視圖不存儲具體的數據。
- 視圖的基本表發生變化，那麼視圖也隨之變化
- 通過視圖可以對用戶展示指定字段從而屏蔽其他字段數據，更加安全
索引：
什麼是索引：能夠快速查詢數據的線索就稱之爲索引，目的在於提高查詢效率。
索引的使用：
+ 查看錶中已有索引 ：`show index from 表名`
+ 創建索引
`create index 索引名稱 on 表名(字段名稱(長度))`
- 如果指定字段是字符串，需要指定長度，建議長度與定義字段時的長度一致
- 字段類型如果不是字符串，可以不填寫長度部分
+ 刪除索引：
`drop index 索引名稱 on 表名;`
索引的缺點：
第一， 創建索引和維護索引要耗費時間，這種時間隨着數據量的增加而增加。
第二， 索引需要佔物理空間，除了數據表佔數據空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
第三， 當對錶中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。
注意：
1. 索引可以明顯提高某些字段的查詢效率。
2. 但不是所有的表都需要建立索引
3. 如果表中數據很少，沒有必要建立索引
4. 如果一個表中的數據增刪很頻繁，不能建立索引 ，因爲只要數據發生增減，索引就要重新建立。增加了系統開銷，反而慢了
5. 索引只適合查詢操作頻繁的表