提示肯定是能覆盖查询优化器自动选择的执行计划的

sqlserver之所以不太建议手工指定,是考虑到查询分析器对表的动态统计数据掌握的信息,比当时指定提示的那个人要多,而且持久.
表的数据可能变化的比较快,最初人手工指定的符合当时那个情景的提示不一定适用于今后的表的状况

1 如何锁一个表的某一行



A 连接中执行



SET TRANSACTION ISOLATION LEVEL REPEATABLE READ



begin tran



select * from tablename with (rowlock) where id=3



waitfor delay '00:00:05'



commit tran



B连接中如果执行



update tablename set colname='10' where id=3 --则要等待5秒



update tablename set colname='10' where id<>3 --可立即执行



2 锁定数据库的一个表



SELECT * FROM table WITH (HOLDLOCK) 





注意: 锁定数据库的一个表的区别



SELECT * FROM table WITH (HOLDLOCK) 

其他事务可以读取表，但不能更新删除



SELECT * FROM table WITH (TABLOCKX) 

其他事务不能读取表,更新和删除

引用 1 楼 ohfox 的回复:

提示肯定是能覆盖查询优化器自动选择的执行计划的

sqlserver之所以不太建议手工指定,是考虑到查询分析器对表的动态统计数据掌握的信息,比当时指定提示的那个人要多,而且持久.
表的数据可能变化的比较快,最初人手工指定的符合当时那个情景的提示不一定适用于今后的表的状况

提示肯定是能覆盖查询优化器自动选择的执行计划的
？
如果我用隔离级别，那么查询优化器是按他自己的方式制定表提示，我的隔离级别还有用没？
你平时都用什么？

查询提示是最后的最细的控制
假如你强制使用一个表的索引,哪怕是用索引会导致比全表扫瞄更多的IO和时间,数据库也会去使用这个索引的

sqlserver2005默认的隔离级别是悲观锁定下的read committed,写会阻塞读,读也会阻塞写.
我刚从oracle转过来写TSQL的时候就郁闷了较长时间,因为不知道sqlserver是这种机制的.我的查询常常被组塞住.
其实默认的隔离级别处理大部分的事情就足够了,它没法避免不可重复读和幻想读的情况.你想想你有没有这样的事物要求

如果不是人工指定锁，查询优化器是不可能更改查询，而破坏指定的隔离级别的。
编程的规则已定，MS爱如何优化是他的事，优化只会加快程序执行速度，不会破坏到规则层面的东东。否则就是BUG！

引用 4 楼 ohfox 的回复:

查询提示是最后的最细的控制
假如你强制使用一个表的索引,哪怕是用索引会导致比全表扫瞄更多的IO和时间,数据库也会去使用这个索引的

sqlserver2005默认的隔离级别是悲观锁定下的read committed,写会阻塞读,读也会阻塞写.
我刚从oracle转过来写TSQL的时候就郁闷了较长时间,因为不知道sqlserver是这种机制的.我的查询常常被组塞住.
其实默认的隔离级别处理……

谢谢...