常時スキャンには0秒または2〜3分かかります

行を返さないことが保証されている以下のようなクエリは、いずれかのサーバーで0〜160秒かかります。

select col1, col2, col3
from tab1
where 0 = 1

2週間前、これは48時間の間隔で6回発生しました。先週、同じクエリにかかった時間は〜0秒でした。アプリケーションのSQLのログはありますが、容疑者はまだ見つかりません。さらに、上位0 / where 0 = 1タイプのクエリはデータページにヒットしないので、行/ページ/テーブルレベルのデータロックに耐性があると思いましたか？スキーマは（既知の）SQLの影響を受けません。

問題が一貫しておらず、サーバーに非常に大きな負荷がかかっているため、SQLプロファイラーを接続する前に何が起こっているのかについての理論を理解したいと思います。他のクエリは、これらの遅延中に問題なく実行されます。アプリケーションの既知の問題は、動的に作成された多数のSQLクエリです-48時間にわたって合計850k（ログ）クエリのうち約200kの一意のクエリは、このような問題を引き起こす可能性がありますか？

サーバーはSQL Server 2005 Standard Edition、96 GB RAM、SAN上のディスクおよび4 CPU / 16コアを実行しています。データベースファイルとファイルグループは十分に最適化されており、問題にはなりません（ただし、これについては個別に調査しています）。

どこを見ればよいかについてのポインタは大歓迎です。

編集：完璧です！クエリを再生して実行プランを追加したところ、1分35秒かかりました。クエリ期間を示す実行プランとスクリーンショットは次のとおりです。

編集2：2回目の実行の統計時間の詳細。現在、一貫して遅いようですので、プロファイラーとperfmonを接続します：

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 97402 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

たとえ... WHERE 0 = 1節があってもIS、テーブルにインテント共有（）ロックが引き続き必要であるように見えます。これを証明しましょう：

まず、テストテーブルを作成します。

use TestDb1;
go

create table dbo.MyTestTable1
(
    Id int identity(1, 1) not null,
    SomeInt int not null
);
go

insert into dbo.MyTestTable1 (SomeInt)
values (10), (20), (30), (40), (50);
go

これでテストテーブルが作成されたので、1つのセッション（クエリウィンドウ）で次のコードを実行して、排他（X）ロックをオンにしdbo.MyTestTable1ます。

use TestDb1;
go

begin tran;
    select
        Id, SomeInt
    from dbo.MyTestTable1 with (tablockx);
--commit tran;

sys.dm_tran_locksDMVを見て、排他ロックを確認できます。次に、別のセッション（新しいクエリウィンドウ）で、クエリの内容を正確に実行します。

use TestDb1;
go

select
    Id, SomeInt
from dbo.MyTestTable1
where 0 = 1;

一見、完了していないようです。を見るとsys.dm_exec_requests、これが事実である理由が正確にわかります。

select
    r.session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    r.blocking_session_id
from sys.dm_exec_requests r
cross apply sys.dm_exec_sql_text(r.sql_handle) st
where st.text like '%where 0 = 1%'
and r.session_id <> @@spid;

... WHERE 0 = 1クエリがISこのオブジェクトのロックを待機していることがわかります（object_idはに変換されますdbo.MyTestTable1）。

私は決して同時実行性があなたの問題であると言っているのではなく、その音によってあなたは症状を示しています。上記の例は、WHEREデータを返さない句がある場合でも、ロックとブロックが免除されていないことを証明するためのものです。

私たちにできることは推測だけなので、「時間がかかる」場合に必要なのは、その要求が実行している処理を正確に確認することです。それが何かを待っているなら、それが待っているものを見てください。

クエリを要求するスパイクとスレッドの程度によっては、システムが単にそのクエリをキューに入れている可能性があります。セットアップのデフォルトのワーカー数（つまり、同時SQLサーバースレッドの数）は約700になるはずです。

sys.dm_os_schedulersおよびsys.dm_os_waiting_tasksをチェックして、それが問題であるかどうかを確認してください。