{"id":46730,"date":"2026-09-08T13:32:57","date_gmt":"2026-09-08T11:32:57","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=46730"},"modified":"2026-09-08T13:33:00","modified_gmt":"2026-09-08T11:33:00","slug":"sql-server-stop-ordering-index-columns-by-selectivity","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/","title":{"rendered":"SQL Server: Stop ordering index columns by selectivity"},"content":{"rendered":"\n

In September 2026 Brent Ozar<\/a> published a post<\/a> arguing that the classic interview question about composite index column order has an answer everybody gets wrong, and that for a query filtering two columns with equality the order makes no difference whatsoever. <\/strong>I wanted to test that claim in logical reads on my own instance and dig into the B-tree architecture to see what actually happens.<\/p>\n\n\n\n

Building the test<\/h2>\n\n\n\n

One table, five million rows, and two indexes holding the same two columns in opposite order. The distribution is deliberately skewed<\/strong>, the way real order tables always are.<\/p>\n\n\n

\nCREATE TABLE dbo.Orders (\n    OrderID     INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,\n    Status      VARCHAR(12)   NOT NULL,\n    CustomerID  INT           NOT NULL,\n    OrderDate   DATETIME2(0)  NOT NULL,\n    Amount      DECIMAL(10,2) NOT NULL\n);\nGO\n\nINSERT INTO dbo.Orders (Status, CustomerID, OrderDate, Amount)\nSELECT TOP 3000000\n    'Shipped',\n    ABS(CHECKSUM(NEWID())) % 100000 + 1,\n    DATEADD(MINUTE, -ABS(CHECKSUM(NEWID())) % 1000000, SYSDATETIME()),\n    ABS(CHECKSUM(NEWID())) % 50000 \/ 100.0\nFROM sys.all_columns a CROSS JOIN sys.all_columns b;\n\nINSERT INTO dbo.Orders (Status, CustomerID, OrderDate, Amount)\nSELECT TOP 1500000\n    'Pending',\n    ABS(CHECKSUM(NEWID())) % 100000 + 1,\n    DATEADD(MINUTE, -ABS(CHECKSUM(NEWID())) % 1000000, SYSDATETIME()),\n    ABS(CHECKSUM(NEWID())) % 50000 \/ 100.0\nFROM sys.all_columns a CROSS JOIN sys.all_columns b;\n\nINSERT INTO dbo.Orders (Status, CustomerID, OrderDate, Amount)\nSELECT TOP 500000\n    'Cancelled',\n    ABS(CHECKSUM(NEWID())) % 100000 + 1,\n    DATEADD(MINUTE, -ABS(CHECKSUM(NEWID())) % 1000000, SYSDATETIME()),\n    ABS(CHECKSUM(NEWID())) % 50000 \/ 100.0\nFROM sys.all_columns a CROSS JOIN sys.all_columns b;\n\nCREATE NONCLUSTERED INDEX IX_Status_Customer ON dbo.Orders (Status, CustomerID);\nCREATE NONCLUSTERED INDEX IX_Customer_Status ON dbo.Orders (CustomerID, Status);\nGO\n\nUPDATE STATISTICS dbo.Orders WITH FULLSCAN;\nGO\n<\/pre><\/div>\n\n\n
Status<\/code> holds three distinct values across five million rows and CustomerID<\/code> holds a hundred thousand. Anyone applying the textbook rule puts CustomerID<\/code> first, since it slices the table thirty-three thousand times more finely, and writes off IX_Status_Customer<\/code> as a beginner’s mistake.<\/p>\n\n\n\n
Both indexes cover a query that selects only OrderID<\/code>, because the clustering key sits in every nonclustered leaf<\/a>. That keeps key lookups out of the read counts and leaves nothing but index access to measure.<\/p>\n\n\n\n
Test 1: both columns in the WHERE clause<\/h2>\n\n\n\n
Let’s run the same query against both indexes, with equality predicates on Status<\/code> and CustomerID<\/code>, and compare what comes back.<\/p>\n\n\n
\nSET STATISTICS IO ON;\n\nSELECT OrderID\nFROM dbo.Orders WITH (INDEX(IX_Status_Customer))\nWHERE Status = 'Cancelled' AND CustomerID = 42731;\n<\/pre><\/div>\n\n
\nTable 'Orders'. Scan count 1, logical reads 3, physical reads 0\n<\/pre><\/div>\n\n\n
\"\"<\/figure>\n\n\n
\nSELECT OrderID\nFROM dbo.Orders WITH (INDEX(IX_Customer_Status))\nWHERE Status = 'Cancelled' AND CustomerID = 42731;\n<\/pre><\/div>\n\n
\nTable 'Orders'. Scan count 1, logical reads 3, physical reads 0\n\n<\/pre><\/div>\n\n\n
\"\"<\/figure>\n\n\n\n
Three logical reads each. Same plan shape, same cost, same everything, from two indexes whose leading columns differ in cardinality by a factor of thirty-three thousand.<\/p>\n\n\n\n
The seek predicates settle it: both say Prefix<\/strong>, and neither plan carries a residual Predicate<\/code> section, which means both indexes reach the rows with a single descent on the full composite key rather than filtering one column after the other :<\/p>\n\n\n\n
\n
\n
\"\"<\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n
The word that matters is Prefix<\/strong>, and it appears on both sides. SQL Server uses that label when the seek keys form a leading portion of the index key and can be resolved in a single descent through the tree.<\/p>\n\n\n\n
This is the heart of the whole thing. A composite index does not store two sorted columns side by side, waiting to be consulted in sequence. It stores one sorted key made of both columns, and Cancelled | 42731<\/code> occupies exactly one position inside it. The engine descends once and arrives, and the picture most of us carry, in which the engine narrows the search using the first column, hands a smaller set of rows over to the second and narrows it again, describes something SQL Server never does.<\/p>\n\n\n\n
That mental picture is precisely what makes the selectivity rule feel so obviously right. Sort by the column that eliminates the most rows first, the reasoning goes, and the second column has less work left to do. It sounds like common sense, and the only trouble with it is that it describes a two-stage filter which the seek predicates above show to be nowhere in either plan, because the filtering it imagines was already finished the moment the descent landed.<\/p>\n\n\n\n
Deep-dive into the nonclustered B-trees<\/h2>\n\n\n\n
The plans agree. Now let’s see whether the physical structures agree too.<\/p>\n\n\n
\nSELECT\n    index_level,\n    page_count,\n    record_count,\n    avg_page_space_used_in_percent\nFROM sys.dm_db_index_physical_stats(\n        DB_ID(),\n        OBJECT_ID('dbo.Orders'),\n        INDEXPROPERTY(OBJECT_ID('dbo.Orders'), 'IX_Status_Customer', 'IndexID'),\n        NULL,\n        'DETAILED')\nORDER BY index_level DESC;\n\nSELECT\n    index_level,\n    page_count,\n    record_count,\n    avg_page_space_used_in_percent\nFROM sys.dm_db_index_physical_stats(\n        DB_ID(),\n        OBJECT_ID('dbo.Orders'),\n        INDEXPROPERTY(OBJECT_ID('dbo.Orders'), 'IX_Customer_Status', 'IndexID'),\n        NULL,\n        'DETAILED')\nORDER BY index_level DESC;\n<\/pre><\/div>\n\n\n
IX_Status_Customer:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
IX_Customer_Status:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Start with the number that ties back to test 1. Both indexes have three levels<\/strong>, and both queries reported three logical reads. Root page, intermediate page, leaf page. The execution plan and the physical structure confirm each other through two completely independent measurements, and neither leaves room for a second lookup step hiding somewhere. Five million rows on both sides, same depth, same cost, and the number of distinct values in the leading column changes neither one.<\/p>\n\n\n\n
Now read the tables diagonally. The record_count<\/code> of any level equals the page_count<\/code> of the level beneath it: 57 records at level 2 against 57 pages at level 1, then 15’605 records at level 1 against 15’605 pages at level 0. The second index does the same with its own figures, 58 and 58, then 15’589 and 15’589. An upper level therefore holds one entry per child page. One per page, whatever that page happens to contain, which is why the size of these levels tracks the number of pages underneath them and stays completely indifferent to how many distinct values live in the column you chose to lead with.<\/p>\n\n\n\n
And that brings us to the comparison the whole article was built for:<\/p>\n\n\n\n
<\/th>IX_Status_Customer<\/th>IX_Customer_Status<\/th><\/tr><\/thead>
Leading column<\/td>Status<\/td>CustomerID<\/td><\/tr>
Distinct values in the leading column<\/td>3<\/td>100’000<\/td><\/tr>
Levels<\/td>3<\/td>3<\/td><\/tr>
Root page entries<\/td>57<\/td>58<\/td><\/tr>
Level 1 pages<\/td>57<\/td>58<\/td><\/tr>
Leaf pages<\/td>15’605<\/td>15’589<\/td><\/tr>
Rows<\/td>5’000’000<\/td>5’000’000<\/td><\/tr>
Logical reads, equality seek<\/td>3<\/td>3<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Inside the root pages<\/h2>\n\n\n\n
The DMV tells us each root holds fifty-seven and fifty-eight entries. Let’s look at what those entries actually are.<\/p>\n\n\n
\nSELECT\n    allocated_page_file_id,\n    allocated_page_page_id,\n    page_type_desc,\n    page_level\nFROM sys.dm_db_database_page_allocations(\n        DB_ID(),\n        OBJECT_ID('dbo.Orders'),\n        INDEXPROPERTY(OBJECT_ID('dbo.Orders'), 'IX_Status_Customer', 'IndexID'),\n        NULL,\n        'DETAILED')\nWHERE page_type_desc = 'INDEX_PAGE'\nORDER BY page_level DESC;\n\nSELECT\n    allocated_page_file_id,\n    allocated_page_page_id,\n    page_type_desc,\n    page_level\nFROM sys.dm_db_database_page_allocations(\n        DB_ID(),\n        OBJECT_ID('dbo.Orders'),\n        INDEXPROPERTY(OBJECT_ID('dbo.Orders'), 'IX_Customer_Status', 'IndexID'),\n        NULL,\n        'DETAILED')\nWHERE page_type_desc = 'INDEX_PAGE'\nORDER BY page_level DESC;\n\n--Run once per index, using the page_level 2 page id returned above\nDBCC TRACEON(3604);\nDBCC PAGE('IndexOrderDemo', 1, <root_page_id_for_both_index>, 3);\n<\/pre><\/div>\n\n\n
IX_Status_Customer:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
IX_Customer_Status:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Several things show up in these dumps, and each of them says the same thing about how the key is treated.<\/p>\n\n\n\n
Row 0 carries NULL<\/code> in every key column, which means an index record holding no key whatsoever, pointing at the leftmost child page<\/strong> and covering every row that sorts below the first boundary anywhere in the page.<\/p>\n\n\n\n
Every other entry carries all three key columns, OrderID<\/code> included, because the clustering key forms part of every nonclustered key. No entry ever names a single column. Each one identifies one specific row out of five million, which is exactly what a boundary between two pages has to do.<\/p>\n\n\n\n
In IX_Status_Customer<\/code>, the same status value appears in entry after entry. Half a million Cancelled<\/code> rows span roughly 1’560 leaf pages and therefore about six intermediate pages, so the value contributes six separate boundaries.<\/p>\n\n\n\n
What about statistics?<\/h2>\n\n\n\n
Navigation <\/strong>is one thing, description <\/strong>is another. Run DBCC SHOW_STATISTICS<\/code> on both indexes and the density vectors tell the story of this whole article in five numbers:<\/p>\n\n\n
\nDBCC SHOW_STATISTICS('dbo.Orders', 'IX_Status_Customer');\n<\/pre><\/div>\n\n\n
\"\"<\/figure>\n\n\n
\nDBCC SHOW_STATISTICS('dbo.Orders', 'IX_Customer_Status');\n<\/pre><\/div>\n\n\n
\"\"<\/figure>\n\n\n\n
The single-column entries are worlds apart, 0.3333333 for Status<\/code> against 1E-05 for CustomerID<\/code>. The two-column entries are identical to the last digit, 3.340538E-06 on both, because the density<\/a> of the full prefix counts the same combinations<\/strong> whichever way round you write them. Furthermore, both previous execution plans above show 7 of 17, seven rows actually returned against seventeen expected, and seventeen is not a coincidence: 5’000’000 multiplied by the two-column density of 3.340538E-06 gives 16.7. Since that density is identical in both indexes, so is the estimate.<\/p>\n\n\n\n
The histograms for the first column have nothing in common. IX_Status_Customer<\/code> gets three steps with exact row counts, 500’000 Cancelled, 1’500’000 Pending, 3’000’000 Shipped. IX_Customer_Status<\/code> gets 21 steps across a hundred thousand customer numbers, with around 50 rows per step. A histogram only ever describes the leading column<\/a>, so each index is blind to the other’s.<\/p>\n\n\n\n
That matters the moment a query supplies one column instead of both, and it is worth knowing before you assume the two indexes are interchangeable for every purpose. It changes nothing for equality on the full key, which is what this article measured.<\/p>\n\n\n\n
What to take from this<\/h2>\n\n\n\n
For equality predicates covering the full key<\/strong>, the two indexes are interchangeable. Three logical reads each, three levels each, and root pages holding 57 entries against 58, from two indexes whose leading columns sit thirty-three thousand apart in cardinality. Brent was right, and the plan, the DMV and the pages all say so independently.<\/p>\n\n\n\n
The reason sits in the seek predicates. Prefix<\/code> on both sides, no residual predicate on either, one descent to one composite key. SQL Server treats the columns as a single sorted value, so there is no first column doing the heavy lifting and no second column mopping up.<\/p>\n\n\n\n
None of which makes column order free. Drop the leading column and the two part company immediately: WHERE CustomerID = 42731<\/code> alone seeks on one index and scans all 15’605 leaf pages on the other. Add an inequality and only the leading range predicate stays seekable<\/strong>, since a range cannot be resolved by a single descent. The seek finds the boundary and reads forward, everything after that column becomes a residual predicate evaluated row by row, and you can watch it appear as a Predicate<\/code> section under the seek that was absent from both plans above.<\/p>\n\n\n\n
So order your key columns by what your queries supply. Equality columns first, then the single range predicate that eliminates the most rows, because only the first of them gets a real seek.<\/span><\/strong> That is the one place selectivity earns its keep.<\/p>\n\n\n\n
One last thing worth saying plainly: this article compared two indexes on a single query,<\/span><\/strong> and no index ever exists to serve a single query. The right order for IX_Status_Customer<\/code> or IX_Customer_Status<\/code> depends on everything else your application runs against that table. Which columns appear alone, which appear together, which carry ranges. That is the analysis worth doing, and counting distinct values will never be a substitute for it.<\/p>\n\n\n\n
Next time you are ordering the columns of a composite index, write down the two or three query shapes that actually matter in your workload, check which of them the key prefix can serve, and let that decide the order. If you find yourself counting distinct values instead, stop, because you are answering a question nobody asked.<\/p>\n","protected":false},"excerpt":{"rendered":"
Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.<\/p>\n","protected":false},"author":157,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[368,99],"tags":[91,51],"type_dbi":[],"class_list":["post-46730","post","type-post","status-publish","format-standard","hentry","category-development-performance","category-sql-server","tag-index","tag-sql-server"],"acf":[],"yoast_head":"\nSQL Server: Stop ordering index columns by selectivity - dbi Blog<\/title>\n<meta name=\"description\" content=\"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SQL Server: Stop ordering index columns by selectivity\" \/>\n<meta property=\"og:description\" content=\"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-08T11:32:57+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-08T11:33:00+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1372\" \/>\n\t<meta property=\"og:image:height\" content=\"261\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Louis Tochon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Louis Tochon\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/\"},\"author\":{\"name\":\"Louis Tochon\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/e4195b0cb120295b3407a502c23e75b6\"},\"headline\":\"SQL Server: Stop ordering index columns by selectivity\",\"datePublished\":\"2026-09-08T11:32:57+00:00\",\"dateModified\":\"2026-09-08T11:33:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/\"},\"wordCount\":1436,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2026\\\/09\\\/image-6-1024x195.png\",\"keywords\":[\"index\",\"SQL Server\"],\"articleSection\":[\"Development & Performance\",\"SQL Server\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/\",\"name\":\"SQL Server: Stop ordering index columns by selectivity - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2026\\\/09\\\/image-6-1024x195.png\",\"datePublished\":\"2026-09-08T11:32:57+00:00\",\"dateModified\":\"2026-09-08T11:33:00+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/e4195b0cb120295b3407a502c23e75b6\"},\"description\":\"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2026\\\/09\\\/image-6.png\",\"contentUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2026\\\/09\\\/image-6.png\",\"width\":1372,\"height\":261},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/sql-server-stop-ordering-index-columns-by-selectivity\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SQL Server: Stop ordering index columns by selectivity\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/e4195b0cb120295b3407a502c23e75b6\",\"name\":\"Louis Tochon\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g\",\"caption\":\"Louis Tochon\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/louistochon\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"SQL Server: Stop ordering index columns by selectivity - dbi Blog","description":"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/","og_locale":"en_US","og_type":"article","og_title":"SQL Server: Stop ordering index columns by selectivity","og_description":"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.","og_url":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/","og_site_name":"dbi Blog","article_published_time":"2026-09-08T11:32:57+00:00","article_modified_time":"2026-09-08T11:33:00+00:00","og_image":[{"width":1372,"height":261,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6.png","type":"image\/png"}],"author":"Louis Tochon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Louis Tochon","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/"},"author":{"name":"Louis Tochon","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/e4195b0cb120295b3407a502c23e75b6"},"headline":"SQL Server: Stop ordering index columns by selectivity","datePublished":"2026-09-08T11:32:57+00:00","dateModified":"2026-09-08T11:33:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/"},"wordCount":1436,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6-1024x195.png","keywords":["index","SQL Server"],"articleSection":["Development & Performance","SQL Server"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/","url":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/","name":"SQL Server: Stop ordering index columns by selectivity - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6-1024x195.png","datePublished":"2026-09-08T11:32:57+00:00","dateModified":"2026-09-08T11:33:00+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/e4195b0cb120295b3407a502c23e75b6"},"description":"Column order does not affect equality seeks in SQL Server. Measured on 5M rows, then proven inside the B-tree pages.","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/09\/image-6.png","width":1372,"height":261},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-stop-ordering-index-columns-by-selectivity\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"SQL Server: Stop ordering index columns by selectivity"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/e4195b0cb120295b3407a502c23e75b6","name":"Louis Tochon","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ce0ee48c64e763e6c4076e21c80729d15bc4493288aeb8695125c69082100e10?s=96&d=mm&r=g","caption":"Louis Tochon"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/louistochon\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/46730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/157"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=46730"}],"version-history":[{"count":44,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/46730\/revisions"}],"predecessor-version":[{"id":46821,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/46730\/revisions\/46821"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=46730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=46730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=46730"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=46730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}