我有一个大约15-20（可选）参数传递的搜索过程，搜索过程调用它们各自的函数来检查参数中传递的值是否存在于数据库中。因此，它基本上是基于许多参数的Search结构。
现在，由于数据库将拥有数百万条记录，我希望简单的普通搜索程序能够立即失败。有哪些方法可以提高查询性能？
到目前为止我尝试过：
数据库FirstName列上的聚簇索引（因为我希望它经常使用）
Non Clustered index用于基于用户搜索的其他列以及include关键字。
注意：
我正在寻找更多优化查询的方法。
大多数查询只是针对条件检查的select语句。
其中一个查询使用GroupBy子句。
我还创建了一个temporary table，我在其中插入所有匹配的条目。
答案 0 :(得分：2)
首先Run来自query的{{1}}并查看查询计划以查看瓶颈的位置。你看到＆＃34;表扫描的任何地方＆＃34;或＆＃34;索引扫描＆＃34;它必须通过所有数据来查找它正在寻找的东西。如果您创建可用于这些操作的适当索引，则应该提高性能。
下面列出了一些提高sql查询性能的技巧。
在单个查询中避免多个联接
尽量避免使用包含外连接，交叉应用，外部应用和其他复杂子查询的多个连接来编写SQL查询。它减少了Optimizer决定连接顺序和连接类型的选择。有时，优化器被迫使用嵌套循环连接，而不管具有过于复杂的交叉应用或子查询的查询的性能影响。
从查询中删除游标 尝试从查询中删除游标并使用基于集的查询;基于集合的查询比基于游标的查询更有效。如果需要使用游标而不是避免使用动态游标，因为它往往会限制查询优化器可用的计划选择。例如，动态游标将优化器限制为使用嵌套循环连接。
避免使用非相关标量子查询 您可以重新编写查询以将非相关标量子查询作为单独的查询而不是主查询的一部分进行删除，并将输出存储在变量中，该变量可在主查询或批处理的后续部分中引用。这将为优化器提供更好的选项，这可能有助于返回准确的基数估计值以及更好的计划。
避免使用多语句表值函数（TVF） 多语句TVF比内联TFV更昂贵。 SQL Server将内联TFV扩展为主查询，就像扩展视图一样，但在与主查询不同的上下文中评估多语句TVF，并将多语句的结果具体化为临时工作表。单独的上下文和工作表使得多语句TVF成本高昂。
创建高度选择性指数 选择性定义表中符合条件的行的百分比（限定行数/总行数）。如果符合条件的行数与总行数的比率较低，则索引具有高选择性并且最有用。如果比率大约为5％或更小，则非聚集索引最有用，这意味着如果索引可以从考虑中消除95％的行。如果索引返回表中超过5％的行，则可能不会使用它;要么选择或创建不同的索引，要么扫描表格。
在索引中放置列 索引中列的顺序或位置对于提高SQL查询性能也起着至关重要的作用。如果查询条件与索引键中最左侧的列匹配，则索引可以帮助提高SQL查询性能。作为最佳实践，大多数选择性列应位于非聚集索引的键的最左侧。
删除未使用的索引 删除未使用的索引有助于加速数据修改，而不会影响数据检索。此外，您需要为不经常运行并使用某些索引的批处理定义策略。在这种情况下，在批处理之前创建索引，然后在批处理完成时删除它们有助于减少数据库的开销。
统计信息创建和更新 您需要处理查询中引用的计算列和多列的统计信息创建和定期更新;查询优化器使用有关表统计信息的一列或多列中的值分布的信息来估计查询结果中的基数或行数。这些基数估计使查询优化器能够创建高质量的查询计划。
重温您的架构定义 最后但同样重要的是，重新访问您的架构定义;请注意适当的FORIGEN KEY，NOT NULL和CEHCK约束是否到位。正确约束在正确位置的可用性总是有助于提高查询性能，例如FORIGEN KEY约束有助于通过将一些外连接或半连接转换为内连接来简化连接，而CHECK约束也通过删除不必要或冗余谓词来帮助实现。