Sql Server中的提示

Question

每个sql语句是否真的需要提示？我们有一个dba是关于它的肛门，并要求我们在我们的存储过程中的每个选择和更新语句上添加提示。这真的有必要吗？

Answer 1

通常不会。把它们放在一切听起来有点矫枉过正。

documentation说

由于SQL Server查询优化器通常会为查询选择最佳执行计划，因此我们建议有经验的开发人员和数据库管理员仅将join_hint，query_hint和table_hint用作最后的手段

Answer 2

您的DBA 错误。

来自MS：

  

因为SQL Server查询优化器   通常选择最佳执行   计划查询，我们建议   加入提示，查询提示，以及   表提示仅用作最后一个   由经验丰富的开发商和   数据库管理员。

Answer 3

提示只是提示。它们可以帮助优化器尽可能做到最好。但是就像任何优化一样，你应该专注于实际问题的陈述。

Answer 4

通常这只是倒退。但是，根据您的情况，可能需要它。

例如，我们有一个数据库（实际上是一台服务器上的一组数据库），其中数据都是大型机系统的夜间快照转储，用于报告和其他目的。除了每晚重新创建数据库的批处理过程之外， nothing 对此系统进行任何写入操作。在这种情况下，默认锁定方案是不合适的，我们的组和管理我们所有服务器的IT组之间的政治阻止我们改变它。所以：几乎所有对这些dbs的查询都有with (nolock)提示。

我想在其他情况下，您可能会报告数据库没有写入，或者可能反过来：很少读取的归档或日志记录数据库。关键是有时可能会设置一个专门的数据库，其中默认锁定方案不适合，您无法更改它。然后你需要大量的pinatas ...我的意思是提示。

但这是证明规则的例外。通常，数据库优化器比锁定等事情更聪明。

Answer 5

取决于 - 查询优化器可以很好地选择意图。您的DBA要求有哪些提示？ @Ned有点不对 - 暗示明确告诉优化器不要弄清楚路径 - 而是使用你的优化。

立法规定你应该总是或永远不要使用提示，但是对于提示要解决的问题有点无知。有些提示至关重要的场合：

• NOLOCK从事务中查询的域查找表中显式删除读锁。
• 将查询计划固定到特定索引，因为在大量更新期间统计数据“漂移”（在此实例中，计划在10米行表上恢复为表扫描而不是使用聚集索引）

从未使用过联接提示。