sql查询，nolock写还是不写，这是一个问题
在做过的很多项目中，发现大家不管对什么表，逢select必定加上nolock（或者with（nolock）），好像已经是制度化的一种东西。有领导高人解释说加上nolock可以提高查询速度，不影响对数据表的其他并发操作。
但是真有必要每个查询都加nolock吗？个人认为加不加nolock还是值得我们根据实际情况斟酌一番的（至少需要知其然然后知其所以然吧）。下面就来简单分析一下加不加nolock以及加了nolock对实际查询的一些影响。
一、重要概念
(此处沉思5秒，安静回想经典数据库教科书里的一些重用概念。嗯......什么，你也想不全了？那好吧，别闲烦，道理是要讲的，书是不得不参考的（bs直接抄书的）)
并发访问：同一时间有多个用户访问同一资源。如果并发用户中有其他用户同时对资源进行了修改，这样对同一数据的访问就会出现“所见不是所得”的情况，从而对其它用户产生某些不利的影响，包括：
1：脏读：有一个用户对某一个资源做了修改，此时另外一个用户正好读取了这条被修改的记录，然后第一个用户又放弃了修改，数据还原到修改之前，这两个不同的结果就是脏读。
2：幻读：特指用户读取一批记录的情况。用户两次查询同一条件的一批记录，第一次查询后，有其它用户对这批数据做了修改，方法可能是insert,update或delete，第二次查询时，用户会发现第一次查询的记录条目有的不在第二次查询结果中，或者是第二次查询的条目不在第一次查询的内容中，造成前后查询结果的不一致。
3：不可重复读：系统中某一个用户的一个操作是一个事务，这个事务分两次读取同一条记录。如果第一次读取后，正好有另外一个用户修改了这条记录，然后第二次读取的正好是之前进行修改记录的那位用户的数据，这样就有可能造成两次读取的数据不同。当然如果我们在事务中锁定这条记录就可以避免。
二、如何消除并发访问的不利影响
如前所述，既然并发访问会造成这么多不利影响，我们又该如何解决呢？估计一般程序员的下意识反应就是像我们在控制多线程并发编程的时候一样，加锁，lock一下，over。没错，还真不能说你说的不对！真是聪明又幸福的程序员啊！
其实在ms的Sql Server中，有两种并发访问的控制机制：锁和行版本控制,关于并发控制，ms的阐述和解决方案真是详细而周到。你不得不pf我们的ms是多么的亲妈啊，真的什么都帮我们想好并且做好了。
先分析一下数据库的锁。
小抄一段参考书上的：
1、锁：“每个事务对所依赖的资源会请求
相关文档：
SQL 教程
1）SQL 简介
SQL(Structured Query Language，结构查询语言)是一个功能强大的数据库语言。SQL通常使用于数据库的通讯。ANSI（美国国家标准学会）声称，SQL是关系数据库管理系统的标准语言。SQL语句通常用于完成一些数据库的操作任务，比如在数据库中更新数据，或者从数据库中检索数据。使用SQL的常见关系数据库� ......
SQL版：
alter proc testguo
(
@cityid int,
@cityname nvarchar(100) output
)
as
select @cityname = city_name from BA_Hot_City where cityid = @cityid
select @cityname
go
declare @cityname nvarchar(100)
exec testguo 1,@cityname output
另一版：
ht ......
ASP.NET Excel导入到SQL Server数据库
提供把Excel里的数据导入到SQL Server 数据库，前提是Excel里的字段在Sql Server表里都有，不然会出现错误。注释很详细哦！要引用的命名空间是：
using System.Data.OleDb;
using System.Data.SqlClient;
//操作类
public class ExcelToSQL
{
& ......
SQL 中的存储过程：
1.在建立存储过程之前检查所命名的存储过程是否应经存在。（因为如果同名存储过程已经存在，新的存储过程将不被建立）
if exists(select * from sysobject where name='proc name' and type='p')
drop proc proc name
go
2.定义存储过程
create proc test
@gradel int, --定义变� ......
1:replace 函数
第一个参数你的字符串，第二个参数你想替换的部分，第三个参数你要替换成什么
select replace('lihan','a','b')
&nb ......
