每个 sql 语句都需要提示吗?我们有一个 dba,他对此非常了解,并要求我们在存储过程中的每个 select 和 update 语句上提供提示。这真的有必要吗?
5 回答
通常不会。把它们放在所有东西上听起来有点矫枉过正。
文件说_
因为 SQL Server 查询优化器通常会为查询选择最佳执行计划,所以我们建议只有经验丰富的开发人员和数据库管理员在不得已的情况下才使用 join_hint、query_hint 和 table_hint
你的 DBA 是错误的。
来自女士:
因为 SQL Server 查询优化器通常会为查询选择最佳执行计划,所以我们建议 只有经验丰富的开发人员和数据库管理员在不得已的情况下才使用连接提示、查询提示和 表提示。
提示只是提示。它们帮助优化器做最好的工作。但与任何优化一样,您应该关注实际存在问题的语句。
通常这只是倒退。但是,根据您的情况,这可能是可取的。
例如,我们有一个数据库(实际上是一台服务器上的一组数据库),其中的数据都是大型机系统的夜间快照转储,用于报告和其他目的。除了每晚重新创建数据库的批处理过程之外,没有任何东西写入这个系统。在这种情况下,默认锁定方案是不合适的,并且我们的团队和管理我们所有服务器的 IT 团队之间的政治使我们无法更改它。所以:几乎所有对这些数据库的查询都有with (nolock)
提示。
我想在其他情况下,您可能拥有没有写入的报告数据库,或者可能相反:很少读取的存档或日志数据库。关键是有时可能会在默认锁定方案不适合并且您无法更改它的情况下设置专门的数据库。那么你将需要大量的皮纳塔......我的意思是提示。
但这是证明规则的例外。一般来说,数据库优化器在锁定之类的事情上比你更聪明。
取决于 - 查询优化器做出了很好的意图选择。您的 DBA 需要哪些提示?@Ned 有点不对劲——一个提示明确告诉优化器不要找出路径——而是使用你的优化。
立法规定您应该始终或从不使用提示有点无知提示要解决的问题。提示至关重要的一些场合:
- NOLOCK 从事务中查询的域查找表中显式删除读锁。
- 由于在大量更新期间统计信息“漂移”而将查询计划固定到特定索引(在这种情况下,计划恢复为对 10m 行表进行表扫描,而不是使用聚集索引)
永远不必使用连接提示。