# Table Scan Operator > [!Note] > The Table Scan Operator reads every row of a table sequentially when no suitable index path exists or the optimizer deems a full scan more efficient than index access. A **Table Scan Operator** performs a linear traversal of all data pages in a table—whether organized as a [[Heap]] or under a [[Clustered Index]]—to evaluate each row against the query’s predicates. Because it does not leverage any B-tree structure for targeted access, the engine reads every page in physical order, incurring significant **I/O overhead** and **CPU work**, particularly on large or fragmented tables. This approach guarantees complete coverage but can impact concurrency and overall system throughput if scans occur frequently on heavily sized tables. The optimizer may choose a table scan when [[Statistics]] indicate that most rows qualify for the filter or when no useful index exists. In some cases, a [[Table Scan Operator]] outperforms multiple key lookups following an [[Index Seek Operator]], especially if the query requests a high percentage of the table’s rows. For tables with uneven data distribution, outdated [[Statistics]] can mislead the optimizer into unnecessary scans, so keeping [[Statistics]] current and considering [[Filtered Index]] or [[Covering Index]] helps the optimizer make more informed decisions. > [!Warning] > Overreliance on table scans for routine queries can lead to **lock escalation** and **blocking**, so monitoring execution plans and adding targeted indexes when appropriate is crucial. --- ## 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.