views:

65

answers:

2

Hi Folks

I understand that Composite Indexes are always used Left to Right (e.g. if an Index was on City, State, WHERE City = "Blah" or WHERE City = "Blah" AND State = "AA" would work fine but WHERE State = "AA" would not).

Does this same principle apply to INCLUDE indexes?

Thanks in advance!

Clay

+1  A: 

No, include fields are not ordered.

Here are some additional design considerations:

http://msdn.microsoft.com/en-us/library/ms190806.aspx

BradC
+2  A: 

Include columns can only be used to supply columns to the SELECT portion of the query. They cannot be used as part of the index for filtering.

EDIT: To further clarify my point, consider this example:

I create a simple table and populate it:

create table MyTest (
    ID int,
    Name char(10)
)

insert into MyTest
    (ID, Name)
    select 1, 'Joe' union all
    select 2, 'Alex'

Now consider these 3 indexes and their corresponding execution plans for a simple SELECT.

select ID, Name
    from MyTest
    where Name = 'Joe'

Case 1: An index on just ID results in a TABLE SCAN.

create index idx_MyTest on MyTest(ID)

alt text

Case 2: An index on ID including name. Somewhat better because the index covers the query, but I still get a SCAN operation.

create index idx_MyTest on MyTest(ID) include (Name)

alt text

Case 3: An index on Name including ID. This is the best. The index is built on the column in my WHERE clause, so I get a SEEK operation, and the index covers the query because of the included column.

create index idx_MyTest on MyTest(Name) include (ID)

alt text

Joe Stefanelli
Thanks Joe. I can see where they wouldn't be helpful on their own but if they couldn't be used for filtering, there wouldn't be much point to their existence.
Clayton
I don't mind a down vote if I'm wrong, but I do dislike an anonymous down vote with no explanation. Can you explain your objection?
Joe Stefanelli
-1 I disagree with "they cannot be used as part of the index for filtering". You can create a cvoering index, add a condition on a column in INCLUDE clause, and the index will still be covering. My downvote is not anonymous.
AlexKuznetsov
@AlexKuznetsov: Help me understand. Say I have a table with ID and Name. I create an index on ID and include Name. If I `SELECT ID, Name FROM MyTable WHERE Name = 'Joe'` then yes, the index is covering, but I would still get a SCAN instead of a SEEK, right? That's the point I was trying to make.
Joe Stefanelli
@Joe Stefanelli: maybe we diagree on what "filtering" means. Surely in your example you will get an index SCAN, but you will not need bookmark lookups. If your query uses another column not in the index: SELECT State, Name, Weight FROM MyTable WHERE City='Seattle' AND Name = 'Joe', you may have less bookmark lookups if Name is included in the index, than if you only have an index on City. Does it make sense to you?
AlexKuznetsov
@AlexKeznetsov: I've edited my answer with an example to clarify. I think we're saying essentially the same thing.
Joe Stefanelli
@Joe Stefanelli: agreed, revoved downvote. Upvoted.
AlexKuznetsov
@AlexKuznetsov: Thanks for hearing me out and for reversing yourself. See you at Chi-SSUG! :-)
Joe Stefanelli
I understand your point, but there is a pretty simple counter example: `SELECT FName, LName, Phone FROM Customer WHERE LName = 'Smith' AND FName = 'Jon'`. If your index was on `(LNAME) INCLUDE (FNAME, PHONE)`, would it use it? Of course! Is it "filtering" on FName? Yes, it is. Of course, it would be *even more awesome* if the index was `(LNAME, FNAME) INCLUDE (PHONE)`, but with the first one you could hardly say that it "cannot be used" as a filter criteria.
BradC
@Joe Stefanelli: I live in the suburbs, and usually attend the suburban UG. In Dec I will be speaking about developing T-SQL for high concurrency. See you there ;)
AlexKuznetsov