# Columns in Indexes: KEY vs INCLUDE > [!Note] > `Deciding whether to define a column as an index **KEY** or as an **INCLUDE** column influences how the index orders data, supports searches and sorts, impacts storage and maintenance costs, and ultimately determines which queries can be served entirely from the index.` In SQL Server, every nonclustered index implicitly carries the clustered index key in its leaf level, so choosing which additional columns become part of the **KEY** versus which simply **INCLUDE** can make a big difference. A **KEY** column participates in the B-Tree structure—appearing in internal nodes and leaf nodes—thereby driving the physical sort order and enabling range scans and seek operations. An **INCLUDE** column is stored only at the leaf level, adding minimal overhead and enabling covering queries without affecting the sorted sequence. Below is a concise comparison of their behaviors and ideal use cases: |**Aspect**|**Column as KEY**|**Column as INCLUDE**| |---|---|---| |**Position in Index**|Part of the main B-Tree structure (internal and leaf nodes).|Stored only at the leaf level.| |**Order**|Defines the index sort order and sequence of rows.|Does not affect row ordering.| |**Seeks & Filters**|Usable for seeks, range scans, predicates, and ORDER BY operations.|Cannot be used for seeks or ordering; only contributes to covering queries.| |**Coverage**|Can cover queries but increases maintenance and storage at all B-Tree levels.|Helps fully cover queries without additional lookups, with minimal maintenance overhead.| |**Index Size**|Adds size at every level of the B-Tree, increasing I/O and memory use.|Increases size only at the leaf level, keeping internal nodes lean.| |**Cardinality & Uniqueness**|Can define uniqueness and affects the index’s cardinality.|Does not influence cardinality or uniqueness.| |**Recommended Use**|For columns used in WHERE, ORDER BY, GROUP BY, or any operation requiring sorted access or range scans.|For columns only referenced in the SELECT list that you want to cover without driving seeks, filters, or sorts.| > [!tip] > Use **KEY** columns to optimize search and sort operations; use **INCLUDE** columns to cover queries without inflating the B-Tree or incurring extra page splits. --- ## ## References - Korotkevitch, D. (2022). _SQL Server advanced troubleshooting and performance tuning: Best practices and techniques_. O’Reilly Media. - Nevarez, B. (2022). _SQL Server query tuning and optimization: Optimize Microsoft SQL Server 2022 queries and applications_. Packt Publishing.