# Scan Operator > [!Note] > The Scan Operator sequentially reads every row in a table or index when a selective path such as an index seek is not available or deemed inefficient. A **Scan Operator** embodies the execution strategy where SQL Server traverses **all pages** of a table or index in their physical order. When the optimizer concludes that a **table scan** or **index scan** will outperform a **seek**—often due to low **predicate selectivity** or outdated **statistics**—it opts for this linear read approach. While scans ensure complete data coverage, they carry significant **I/O overhead** and can elevate **CPU consumption**, particularly on large or heavily fragmented tables. This operator surfaces in execution plans whenever no suitable **B-tree** path exists to quickly locate target rows. Its presence is a clear signal that query tuning or the introduction of additional **nonclustered indexes** might enable more efficient **seek** operations. In scenarios where scans are unavoidable—such as queries retrieving most of a table’s rows—techniques like **table partitioning** or **filtered indexes** can help restrict the volume of pages read, mitigating performance impacts. > [!Tip] > Ensuring your **statistics** are current empowers the optimizer to make informed choices between scans and seeks, often reducing unnecessary full-table reads. --- ## 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.