没有“技巧”。

鉴于数据库供应商之间的竞争是“更快”的，任何永远正确的“技巧”都将在数据库本身中实现。（这些技巧在数据库的“优化程序”部分中实现）。

只有要注意的事情，但通常不能简化为：

• 使用功能 X
• 避免特征 Y
• 像 这样的* 模型 *
• 永远不要像 那样* 建模 *

查看有关索引，索引类型，索引策略，群集，单列键，复合键，参照完整性，访问路径，联接，联接机制，存储引擎，优化器行为，数据类型，规范化，查询转换，反规范化，过程，缓冲区高速缓存，结果集高速缓存，应用程序高速缓存，建模，聚合，函数，视图，索引视图，集合处理，过程处理，并且列表继续存在。

所有这些都是为了攻击特定的问题区域而发明的。在该问题上的变化使“技巧”或多或少地适合。很多时候，这些技巧的效果为零，有时甚至变得可怕。为什么？因为当我们不了解某些事情为什么起作用时，我们基本上只是在向问题扔出一些功能，直到问题消失为止。

这里的关键点在于， 有一个原因使某事物使查询运行得更快 ，并且对事物的含义的 理解 对于
理解为什么一个不同的无关查询缓慢并对其进行处理的过程 至关重要 。这绝不是招数，也不是魔术。

我们（人类）很懒惰，当我们真正需要的是学习如何捕捉时，我们希望把那条鱼扔掉。

现在，您想抓什么具体的鱼？

编辑注释：
谓词在where子句中的放置没有区别，因为谓词的处理顺序由数据库确定。一些会影响该顺序的因素（例如，您的例子）是：

• 是否可以针对索引视图重写查询
• 有哪些可用的索引涵盖NUMBER和DATE列中的一者或两者，以及它们在该索引中的排列顺序
• 谓词的估计选择性，基本上是指谓词匹配的行的估计百分比。百分比越低，优化器就越有可能有效地使用索引。
• 如果SQL Server将群集因素（或SQL Server中的任何名称）作为查询成本的因素，则为群集因素。这与索引条目的顺序与表行的物理顺序如何对齐有关。更好的对齐方式=降低了通过该索引获取的更高百分比的行的成本。

现在，如果您在NUMBER列中仅有的值是156、646，并且它们几乎均匀分布，则索引将无用。全面扫描将是更好的选择。
另一方面，如果这些是唯一的订单号（由唯一索引支持），则优化器将选择该索引并从那里驱动查询。同样，如果在2011年1月1日到1月2日之间具有DATE的行占行的比例很小，则将考虑以DATE开头的索引。

或者，如果您order by NUMBER, DATE在方程式中包含另一个参数；分拣成本。现在，（NUMBER，DATE）上的索引似乎对优化器更具吸引力，因为即使它不是获取行的最有效方法，也可以跳过排序（这很昂贵）。

或者，如果您的查询包括对customer_id上的另一个表（例如customer）的联接，并且您还对进行了过滤customer.ssn，则方程式也会再次更改，因为（由于您对外键和后备索引所做的出色工作）您现在将拥有到第一个表的非常有效的访问路径，而无需使用NUMBER或DATE中的索引。除非您只有一个客户，并且他的1000万个订单中的所有客户都…