以前比較naive，有次同事一定要在表里建唯一約束的時候，我就很納悶為啥非要在db層面做限制，在自己的業務代碼里做啊，就是說入庫的時候先查一遍有沒有，沒有記錄的情況再准許入庫。
后來發現如果只是自己處理業務代碼時先查后入庫，並發高時會發生意想不到的后果。。
比如現在表tab里有兩個字段fa, fb。業務規定，fa和fb的值只能成對出現一次（好比1，2入庫一次，就不能再有一條1，2的記錄入庫）。
當在自己的業務代碼里處理避免再次入庫時，會這樣處理，
步驟一：select 1 from tab where fa = ? and fb = ?
步驟二：insert tab values (?, ?)
那么問題來了（挖掘機哪家強。。）：當第一條記錄來了，比如fa=1, fb=2。此時他通過了步驟一的檢測，沒有這條記錄，於是來到了步驟二。就在此時，第二條記錄又來了，而且又是一個fa=1, fb=2。好吧，第一條記錄可能還沒入庫完呢，那第二條記錄也可以通過了步驟一的檢測，也來到了步驟二。。而這時，意想不到的事發生了。。有兩條一樣的記錄了。
所以這種並發高了的情況發生就造成這樣滴局面。
而如果在數據庫層面進行限制就會完美解決這一個問題（當然業務上有上述需求的話，db做了限制外，最好自己的業務代碼也要先查一下，再入庫。發生了什么好做處理，比如查詢的時候發現已經入庫了，這時又什么業務策略。再有也可以通過數據庫返回碼，唯一約束時，db會拋出[Err] 1062的錯誤碼）。。
數據庫的約束用法來了。（以下就拿mysql舉例。）
w3c講這一節鏈接：http://www.w3school.com.cn/sql/sql_unique.asp
一個表可以有多個唯一約束，一個約束可以只有一列，當然也可以有多列。
此時執行這樣一條語句（some_name是這個約束名）：
ALTER TABLE tab ADD CONSTRAINT some_name UNIQUE (fa, fb)
如果在第一次建表時，加約束是這樣的：
CREATE TABLE tab ( fa int NOT NULL, fb int NOT NULL, CONSTRAINT some_name UNIQUE (fa ,fb ) )