TableScan では、テーブルの全ページのローすべてが、データベースに格納された順に読み込まれます。これは、逐次テーブル・スキャンと呼ばれます。

逐次テーブル・スキャンは、短いテキスト・プランと長いテキスト・プランに correlation_name<seq> と表示されます。ここで、correlation_name は FROM 句に指定された相関名、または指定されていない場合はテーブル名です。

逐次テーブル・スキャンが使用されるのは、テーブル・ページの大多数にクエリの探索条件と一致するローがある場合、または適切なインデックスが定義されていない場合です。

逐次テーブル・スキャンではインデックス・スキャンより多数のページが読み込まれる場合があります。ただし、ディスクの連続するブロックからページが読み込まれるため、ディスク I/O はかなり低コストです (このパフォーマンスの改善は、データベース・ファイルがディスク上で断片化されていない場合には最適です)。逐次 I/O では、ディスク・ヘッドの移動と回転待ち時間は低下します。大きなテーブルの場合、逐次テーブル・スキャンでは、一度に数ページも読み込まれます。このため、逐次テーブル・スキャンはインデックス・スキャンに比べてさらに低コストになります。

多数のローを一致させる場合、逐次テーブル・スキャンの方がインデックス・スキャンより短時間で済みます。ただし、スキャンが数回実行される場合は、インデックス・スキャンほど効率的にキャッシュを利用できません。インデックス・スキャンの方がアクセスするテーブル・ページ数が少ないため、キャッシュ内のページを利用できる可能性が高くなり、その結果アクセスが短時間になります。このため、ネスト・ループ・ジョインの右側など、反復的なテーブル・アクセスにはインデックス・スキャンの方が適しています。

トランザクションが独立性レベル 3 で実行されている場合は、アクセスするローが探索条件を満たしていなくても、SQL Anywhere は各ローをロックします。この独立性レベルでは、逐次テーブル・スキャンはテーブル内のすべてのローにロックをかけますが、インデックス・スキャンは探索条件と一致するローだけにロックをかけます。つまり、マルチユーザ環境で逐次テーブル・スキャンを使用すると、スループットが大幅に悪くなる可能性があります。このため、独立性レベル 3 ではオプティマイザは逐次アクセスよりインデックス・アクセスを優先します。逐次スキャンでは、スキャン中にテーブル・カラムと定数の間の単純な比較述部を効率的に評価できます。スキャン中のテーブルだけを参照するその他の探索条件は、これらの単純な比較の後で評価されます。このアプローチは、逐次スキャンの後でフィルタ内の条件を評価する方法より多少効率的です。