有时会遇到令人费解的情况，平时一分钟可以完成的查询语句，某一天突然发生意外，运行了2-3个小时还在运行，这就是失控查询的行为表现，失控的查询（Runaway Query）是指实际执行时间比预计的时间要长的多，并且消耗大量的系统资源的查询。通常情况下，失控的查询是由关联表没有索引、关联表使用错误的索引、或者选择的join算法不恰当导致的。
举个例子，把TableA 和 TableB进行连接（join）操作，这两个表各有100万行，如果使用Loop Join算法，那么有100万*100万次循环，时间复杂度是O(nm）。如果使用Merge Join，那么只需要对数据进行排序，执行归并排序就可以了，平均时间复杂度是O(n * log m)。从时间复杂度上，可以看出Merge Join的时间复杂度比Loop Join小很多，如果Join操作使用Merge Join，将是最优的选择。
但是，当统计信息不能准确描述数据整体时，可能误导查询优化器做出错误的决策，如果查询优化器选择Loop Join算法生成执行计划时，那么该query会在SQL Server 内部进行海量的循环操作，使得查询执行的时间暴增，CPU和IO资源的消耗也大幅增加。
为了避免在产品环境中出现失控查询，可以采用以下措施：
- 为表创建索引
- 保持统计信息及时更新
- 在脚本中使用可索引化条件
参考文档：