I've been having some trouble getting a single-column "varchar(5)" field to reliably use a table seek instead of a table scan. The production table in this case contains 25 million rows. As impressive as it is to scan 25 million rows in 35 seconds, the query should run much faster.Here's a partial table description:CREATE TABLE [dbo].[Summaries_MO]( [SummaryId] [int] IDENTITY(1,1) NOT NULL, [zipcode] [char](5) COLLATE Latin1_General_100_BIN2 NOT NULL, [Golf] [bit] NULL, [Homeowner] [bit] NULL, [IncomeCode] [char](1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [Pets] [bit] NULL,CONSTRAINT [Summaries_MO_primaryKey] PRIMARY KEY NONCLUSTERED HASH ( [SummaryId])WITH ( BUCKET_COUNT = 33554432),INDEX [ixZIP] NONCLUSTERED ( [zipcode] ASC))WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )Typically, this table is accessed with a query that includes:SELECT ... FROM SummaryTable WHERE ixZIP IN (SELECT ZipCode FROM @ZipCodesForMO)This query insists on using a table scan. I've tried WITH (FORCESEEK) for example, but that just makes the query fail.As I've investigated this issue I also tried:SELECT * FROM Summaries WHERE ZipCode IN ('xxxxx', 'xxxxx', 'xxxxx')When I run this query with 64 or fewer (actual, valid) ZIP codes, the query uses a table seek.But when I give it 65 or more ZIP codes it uses a table scan.To summarize, the production query always uses a table scan, and when I specify 65 or more ZIP codes the query also uses a table scan.Frankly, I'm wondering if the data type of the indexed column (Latin1_General_100_BIN2) is somehow the problem. I'll likely try converting the ZIP codes to an integer to see what happens.But I'd rather know what's going on than simply try things randomly.
↧