事务隔离级别有4种，这4种级别只是对于读操作，也就是select有不同程度的支持，
读未提交：不会对事务里读出来的数据附加任何锁
读已提交：会对事务里读出来的数据附加共享锁，读完就释放共享锁，其他事务可以对这边已读的数据进行读和写，这是mssql默认的隔离级别。这种隔离级别也会发生死锁，例如你的程序中有个A事务是更新完表1，在更新表2，B事务是更新完表2在更新表1，当A和B被并发执行时，死锁就产生了，读未提交也会产生这种死锁。
不可重复读：会对事务里读出来的数据附加共享锁，但是不会读完就释放共享锁，共享锁会持续到事务结束，其他事务只能对这边已读的数据进行读操作，不能写。这种隔离级别就容易产生死锁，例如你的程序中有一个事务是读取一条数据并更新这条数据，这种业务一般很常用，当这个事务被A和B并发执行时，A读取操作读完会一直持有这条数据的共享锁，不会释放，B也同样，当A想要执行更新操作时，必须等待B释放共享锁，B也执行操作也必须等待A释放共享锁，这样死锁就产生了。
还有快照和串行化就不说了，很少用到。
不管哪种隔离级别，进行update、add和delete时都会锁住操作的记录，并持有锁，直到事务结束。一般情况下update、add和delete操作只会锁住要操作的记录，不会锁整个表。
需要注意的是TransactionScope默认的级别是串行化，我第一次用TransactionScope时就造成不小的困扰，数据库老出现死锁。查资料才发现是串行化级别，这不坑爹么，把TransactionScope的事务隔离级别设置成读已提交，死锁不在出现
另外事务隔离级别只对于当前连接有效，你在这个connect连接里设置了事务隔离级别，另一个connect里的事务还是默认的级别，默认级别是读已提交。目前没有可以全局设置事务隔离级别的地方。
以上结论只是针对mssql，其他数据库没做研究。
事务隔离级别在满足业务的情况下，尽量越低越好，能减少死锁概率和增加数据库并发性能