第一范式（1NF）無重復的列
第二范式（2NF）屬性完全依賴于主鍵
第三范式（3NF）屬性不依賴于其它非主屬性

第一范式
   1、每一列屬性都是不可再分的屬性值，確保每一列的原子性
   2、兩列的屬性相近或相似或一樣，盡量合并屬性一樣的列，確保不產生冗余數據。

第二范式
    每一行的數據只能與其中一列相關，即一行數據只做一件事。只要數據列中出現數據重復，就要把表拆分開來。

第三范式
 數據不能存在傳遞關系，即沒個屬性都跟主鍵有直接關系而不是間接關系。
像：a-->b-->c  屬性之間含有這樣的關系，是不符合第三范式的。
比如Student表（學號，姓名，年齡，性別，所在院校，院校地址，院校電話）
這樣一個表結構，就存在上述關系。 學號--> 所在院校 --> (院校地址，院校電話)
這樣的表結構，我們應該拆開來，如下。
（學號，姓名，年齡，性別，所在院校）--（所在院校，院校地址，院校電話）

事務由一個或多個sql語句組成一個整體，如果所有的語句執行成功那么修改將會全部生效，如一條sql語句將銷量+1，下一條再+1，倘若第二條失敗，那么銷量將撤銷第一條sql語句的+1操作，只有在該事務中所有的語句都執行成功才會將修改加入到數據庫中。

事務的特性

事務具體四大特性，也就是經常說的ACID 
1. 原子性（Atomicity） 
　　原子性是指事務包含的所有操作要么全部成功，要么全部失敗回滾，因此事務的操作如果成功就必須要完全應用到數據庫，如果操作失敗則不能對數據庫有任何影響。 
　　 
2. 一致性（Consistency） 
　　一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之后都必須處于一致性狀態。

　　拿轉賬來說，假設用戶A和用戶B兩者的錢加起來一共是5000，那么不管A和B之間如何轉賬，轉幾次賬，事務結束后兩個用戶的錢相加起來應該還得是5000，這就是事務的一致性。

3.隔離性（Isolation） 
　　隔離性是當多個用戶并發訪問數據庫時，比如操作同一張表時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個并發事務之間要相互隔離。

　　即要達到這么一種效果：對于任意兩個并發的事務T1和T2，在事務T1看來，T2要么在T1開始之前就已經結束，要么在T1結束之后才開始，這樣每個事務都感覺不到有其他事務在并發地執行。

4.持久性（Durability） 
　　持久性是指一個事務一旦被提交了，那么對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。Mysql中會保存有相應的操作日志，即使遭遇故障依然能夠通過日志恢復最后一次更新。

　　例如我們在使用JDBC操作數據庫時，在提交事務方法后，提示用戶事務操作完成，當我們程序執行完成直到看到提示后，就可以認定事務以及正確提交，即使這時候數據庫出現了問題，也必須要將我們的事務完全執行完成，否則就會造成我們看到提示事務處理完畢，但是數據庫因為故障而沒有執行事務的重大錯誤。

MySql中支持事務的引擎

在mysql中用的最多的存儲引擎有：innodb，bdb，myisam ,memory 等。其中innodb和bdb支持事務而myisam等不支持事務。

 如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：
1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。
2 Redis支持數據的備份，即master-slave模式的數據備份。
3 Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。

在Redis中，并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別（我個人是這么認為的）。

同時由于Redis將內存中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作后才可以進行修改。

可以參考使用Redis特有內存模型前后的情況對比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used 

當 從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數據，然后再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小，進行 批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程 池的大小，對需要從swap文件中加載相應數據的讀取請求進行并發操作，減少阻塞的時間。

redis、memcache、mongoDB 對比
從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚

1、性能
都比較高，性能對我們來說應該都不是瓶頸
總體來講，TPS方面redis和memcache差不多，要大于mongodb


2、操作的便利性
memcache數據結構單一
redis豐富一些，數據操作方面，redis更好一些，較少的網絡IO次數
mongodb支持豐富的數據表達，索引，最類似關系型數據庫，支持的查詢語言非常豐富


3、內存空間的大小和數據量的大小
redis在2.0版本后增加了自己的VM特性，突破物理內存的限制；可以對key value設置過期時間（類似memcache）
memcache可以修改最大可用內存,采用LRU算法
mongoDB適合大數據量的存儲，依賴操作系統VM做內存管理，吃內存也比較厲害，服務不要和別的服務在一起

4、可用性（單點問題）

對于單點問題，
redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整個快照,無增量復制，因性能和效率問題，
所以單點問題比較復雜；不支持自動sharding,需要依賴程序設定一致hash 機制。
一種替代方案是，不用redis本身的復制機制，采用自己做主動復制（多份存儲），或者改成增量復制的方式（需要自己實現），一致性問題和性能的權衡

Memcache本身沒有數據冗余機制，也沒必要；對于故障預防，采用依賴成熟的hash或者環狀的算法，解決單點故障引起的抖動問題。

mongoDB支持master-slave,replicaset（內部采用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制。


5、可靠性（持久化）

對于數據持久化和數據恢復，

redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響

memcache不支持，通常用在做緩存,提升性能；

MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性


6、數據一致性（事務支持）

Memcache 在并發場景下，用cas保證一致性

redis事務支持比較弱，只能保證事務中的每個操作連續執行

mongoDB不支持事務


7、數據分析

mongoDB內置了數據分析的功能(mapreduce),其他不支持


8、應用場景
redis：數據量較小的更性能操作和運算上

memcache：用于在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫少，對于數據量比較大，可以采用sharding）

MongoDB:主要解決海量數據的訪問效率問題   

Redis 集群中內置了 16384 個哈希槽，當需要在 Redis 集群中放置一個 key-value時，redis 先對 key 使用 crc16 算法算出一個結果，然后把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點。

Redis 集群沒有使用一致性hash, 而是引入了哈希槽的概念。

Redis 集群有16384個哈希槽,每個key通過CRC16校驗后對16384取模來決定放置哪個槽.集群的每個節點負責一部分hash槽。這種結構很容易添加或者刪除節點，并且無論是添加刪除或者修改某一個節點，都不會造成集群不可用的狀態。

使用哈希槽的好處就在于可以方便的添加或移除節點。

當需要增加節點時，只需要把其他節點的某些哈希槽挪到新節點就可以了；

當需要移除節點時，只需要把移除節點上的哈希槽挪到其他節點就行了；

在這一點上，我們以后新增或移除節點的時候不用先停掉所有的 redis 服務。

 

"用了哈希槽的概念，而沒有用一致性哈希算法，不都是哈希么？這樣做的原因是為什么呢？"
Redis Cluster是自己做的crc16的簡單hash算法，沒有用一致性hash。Redis的作者認為它的crc16(key) mod 16384的效果已經不錯了，雖然沒有一致性hash靈活，但實現很簡單，節點增刪時處理起來也很方便。

"為了動態增刪節點的時候，不至于丟失數據么？"
節點增刪時不丟失數據和hash算法沒什么關系，不丟失數據要求的是一份數據有多個副本。

“還有集群總共有2的14次方，16384個哈希槽，那么每一個哈希槽中存的key 和 value是什么？”
當你往Redis Cluster中加入一個Key時，會根據crc16(key) mod 16384計算這個key應該分布到哪個hash slot中，一個hash slot中會有很多key和value。你可以理解成表的分區，使用單節點時的redis時只有一個表，所有的key都放在這個表里；改用Redis Cluster以后會自動為你生成16384個分區表，你insert數據時會根據上面的簡單算法來決定你的key應該存在哪個分區，每個分區里有很多key。