This article has been archived. It is offered "as is" and will no longer be updated.
If you have a set of predicates in the following form
(a = b) && (a = constant)
there is an implied redundant predicate (b = constant) that can be added. The absence of this implied predicate can make the query run slowly.
An enhancement has been made to SQL Server to add this redundant predicate for semi joins, anti-semi joins, inner joins, and outer joins.
Service pack information
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
290211 How to obtain the latest SQL Server 2000 service pack
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
Note Because of file dependencies, the most recent hotfix or feature that contains the files may also contain additional files.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.This problem was first corrected in Microsoft SQL Server 2000 Service Pack 4.
When you apply a hotfix or service pack that contains this fix, the SQL Server optimizer automatically introduces the implied predicate and may remove the corresponding join predicate.
The example that is mentioned in the "Symptoms" section shows a join between a and b. In this example, after optimization the predicate looks like the following:
(a = constant) and (b = constant)
When the original predicate is from a multicolumn key, the simplified expression may remove one of the original join keys. For example, the predicate t1.a = t2.a && t1.b = t2.b && t1.c = constant is changed to t1.b = t2.b && t1.a = constant && t2.a = constant. If column a is the leading column of a multicolumn index, you cannot use a multicolumn density match for cardinality estimation. Additionally, this may cause query plans where the query plan seeks on only the leading index column and applies the remaining filter criteria as residual filters in a WHERE clause on the index seek line or in a WHERE clause for the join operator. For example, the query plan seeks on t1.a = constant. In this scenario, there may be greater disk input/output load and increased CPU utilization. In SQL Server 2000 SP4, you can disable this optimization through trace flag 9061.