<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SARGability on Rudi Bruchez</title><link>https://www.pachadata.com/en/tags/sargability/</link><description>Recent content in SARGability on Rudi Bruchez</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 28 Aug 2026 16:45:32 +0200</lastBuildDate><atom:link href="https://www.pachadata.com/en/tags/sargability/index.xml" rel="self" type="application/rss+xml"/><item><title>Do not break your indexes — SARGability and WHERE clause anti-patterns</title><link>https://www.pachadata.com/en/docs/articles/sql-server/performance/sargability/</link><pubDate>Wed, 25 Feb 2026 00:00:00 +0000</pubDate><guid>https://www.pachadata.com/en/docs/articles/sql-server/performance/sargability/</guid><description>&lt;div class="alert alert-success" role="alert"&gt;&lt;div class="h4 alert-heading" role="heading"&gt;TL;DR&lt;/div&gt;&#10;&lt;p&gt;Applying a function to a column in the &lt;code&gt;WHERE&lt;/code&gt; clause stops SQL Server from using the indexes on that column. Such a query is called non-SARGable. The result: an &lt;strong&gt;Index Scan&lt;/strong&gt;, a full traversal, instead of an &lt;strong&gt;Index Seek&lt;/strong&gt;, a direct lookup.&lt;/p&gt;&#10;&lt;p&gt;The most frequent culprits: &lt;code&gt;COALESCE&lt;/code&gt;, &lt;code&gt;ISNULL&lt;/code&gt;, &lt;code&gt;CONVERT&lt;/code&gt;, &lt;code&gt;YEAR()&lt;/code&gt;, &lt;code&gt;LEFT()&lt;/code&gt;, &lt;code&gt;TRIM()&lt;/code&gt; applied to the filtered columns.&lt;/p&gt;&#10;&lt;p&gt;The fix: move the logic to the value or the parameter side, never to the column side.&lt;/p&gt;</description></item></channel></rss>