我在网上找过答案，但找不到确定的答案。例如你有 2 个连接子句:
1.
JOIN T2 ON T1.[ID] = T2.[ID]
2.
JOIN T2 ON T1.[ID] = REPLACE(T2.[ID],'A', '')
现在，由于 join 子句上的功能，第二个表现更差。具体原因是什么？
例如，如果此代码位于存储过程中，那么优化它的最佳方法是什么？要删除替换功能并将其添加到表级别以便所有这些都在任何连接之前完成？
任何建议或指向更多信息的链接都会很棒。谢谢
最佳答案
在您的第二个示例中，您正试图在 T2 中查找记录 - 但不是将值作为 T1.ID 值，而是将函数应用于 T2.ID - REPLACE(T2.[ID],'A', '')
如果您在 T2.ID 上有一个索引 - 充其量它会扫描索引而不是查找它 - 从而导致性能差异。
这是更难解释的地方 - 索引存储为表中 T2.ID 值的 b+ 树。索引理解该字段并可以根据它进行搜索/排序，但它不理解应用于它的任何逻辑。
它不知道是否 REPLACE('A123','A', '') = 123 - 无需对索引中的值执行函数并检查结果是否相等。
AAA123 也将是相等的，1A23、12A3、123A 等，实际上匹配的组合数量永无止境 - 但它可以确定单个索引条目是否匹配的唯一方法是运行通过函数的值，然后检查是否相等。
如果它只能在通过函数运行索引值时弄清楚 - 它只能正确地回答查询，如果它对索引中的每个条目都这样做 - 例如对每个条目进行索引扫描，传递给函数并检查输出。
正如 Jeroen 提到的术语是 SARGable 或 SARGability，S搜寻 ARG ument ABLE , 尽管我个人更喜欢将其解释为 S一周ARG ument ABLE因为这与查询计划运算符更匹配。
应该注意的是，这个概念与连接无关，SQL 中的任何谓词都有这个限制 - 带有 where 谓词的单个表查询可能有同样的问题。
这个问题可以避免吗？它可以，但仅在某些情况下，您可以逆转操作。
考虑一个带有 ID 列的表，我可以构造一个如下的谓词:
WHERE ID * 2 = @paramValue
SQL Server 知道 ID 条目乘以 2 是否是传入值的唯一方法是处理每个条目，将其加倍并检查。这又是索引扫描场景。
在这种情况下我们可以重写它:
WHERE ID = @paramValue / 2.0
现在 SQL Server 将执行一次数学运算，除以传入的值，然后它可以以可查找的方式根据索引检查该结果。编写的 SQL 中的差异看起来可能只是陈述问题的微不足道的差异，但对数据库如何解析谓词有很大的不同。
关于SQL Server 查询连接优化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51419362/