以前比较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 ) )