Can including columns into the SELECT from the same table slow down the query?

Question

Imagine Foo table has non-clustered indexes on ColA and ColB and NO Indexes on ColC, ColD

SELECT colA, colB
FROM Foo

takes about 30 seconds.

SELECT colA, colB, colC, colD
FROM Foo

takes about 2 minutes.

Foo table has more than 5 million rows.

Question: Is it possible that including columns that are not part of the indexes can slow down the query? If yes, WHY? -Are not they part of the already read PAGEs?

Answer 1

If you write a query that uses a covering index, then the full data pages in the heap/clustered index are not accessed.

If you subsequently add more columns to the query, such that the index is no longer covering, then either additional lookups will occur (if the index is still used), or you force a different data access path entirely (such as using a table scan instead of using an index)

---

Since 2005, SQL Server has supported the concept of Included Columns in an index. This includes non-key columns in the leaf of an index - so they're of no use during the data-lookup phase of index usage, but still help to avoid performing an additional lookup back in the heap/clustered index, if they're sufficient to make the index a covering index.

---

Also, in future, if you want to get a better understanding on why one query is fast and another is slow, look into generating Execution Plans, which you can then compare.

Even if you don't understand the terms used, you should at least be able to play "spot the difference" between them and then search on the terms (such as table scan, index seek, or lookup)

Answer 2

Simple answer is: because non-clustered index is not stored in the same page as data so SQL Server has to lookup actual data pages to pick up the rest.

Non-clustered index are stored in separate data structures while clustered indexes are stored in the same place as the actual data. That’s why you can have only one clustered index.