Sql 的巨大影响>；=where子句中的运算符

我已经提出了几乎相同的问题，但没有得到令人满意的答复，我只是遇到了类似的情况

select r.order_number, cl.COMMANDE, m.[order #]
from [Offline RN General] r 
left join mcdb_summary m ON r.order_number=m.[order #]
left join coclico cl ON cl.ORDER_ID=r.order_number
where r.[order_number] is not null and r.GroupID=358472  and converted='yes' and r.[Booking Date]>='20140401'

因此，最后一个条件（r.[Booking Date]='20140401'）会导致查询在没有该条件的情况下至少需要40秒才能完成，或者奇怪的是，如果是r.[Booking Date]，则首先要尝试：

UPDATE STATISTICS [Offline RN General];

统计信息提供有关数据分布的信息（例如，日期X有多少行，日期Y有多少行等），这有助于查询引擎做出“基于成本”的决策：执行索引搜索而不是索引扫描等

您可以通过运行一个简单的

DBCC显示统计数据（“”，）；

---

您可以阅读有关when统计信息的更多信息。

如果看不到索引，我将确保所有可能的键都处于良好状态，以便优化“R”表上的查询

---

此外，所有列（已转换）的确认应符合表中的要求。。。我只能猜测转换后的文件在脱机RN General表中。

能否共享XML执行计划？右键单击exec plan图形表示的背景，从弹出菜单中选择“将执行计划另存为…”，并将其保存到扩展名为sqlplan的文件中。它是一个普通的XML文件，您可以在记事本中打开它，sqlplan扩展只需将它与SSM关联即可。然后将其上传到dropbox、sky/onedrive或类似网站并共享。否则，我们只能猜测发生了什么。我的猜测是，减速来自嵌套循环。尝试更新统计信息，可能会强制进行一些哈希连接，看看是否有帮助。嗯，因为[Offline RN General]是一个视图，我在基础表上执行了命令（update statistics Offline_RN；），它成功了！我会做一些测试，然后标记你的答案。为什么一个表的统计数据对查询有如此大的影响？我觉得我的索引错了。无论如何谢谢你！好的，这是更新统计数据后的执行计划，我不明白为什么我必须手动执行更新，而sp_autostats显示表的autostats是ONCheck，请查看响应中的链接以了解详细信息。简单地说，表统计信息会发生变化：•当一个表的行数少于500行且增加了500行或更多行时•当一个表的行数超过500行且增加了500行时+20%的行数

UPDATE STATISTICS [Offline RN General];

DBCC SHOW_STATISTICS('<tablename>', '<indexname>');

table                 index
[Offline RN General]  ( groupID, converted, order_number, [booking date]  )
mcdb_summary          ( [order #] )
coclico               ( order_id, commande )