Microsoft SQL Server 2005、SELECTステートメントWHERE句でのOR演算子

CREATE TABLE test_table01
(
	id INT PRIMARY KEY NOT NULL, /* 単語のID */
	hyoki NVARCHAR(256) NOT NULL, /* 単語の表記 */
	yomi NVARCHAR(256) NOT NULL, /* 単語の読み */
	hinshi INT NOT NULL, /* 単語の品詞 */
	kanren_id INT NOT NULL, /* 自分と関連する単語のID */
)

kanren_idは自分と関連する単語のidを持つ（自分自身はのぞく。kanren_id!=id。）。
kanren_idは無効値0で、20%の確率で有効な値が入る。

こんな感じでテーブルを作って、データを用意して流して込む。（50万件のデータを作って流し込んだ。）

簡単なテストコードを書く。

DECLARE @i INT

SET @i=1
WHILE (@i <= 500)
BEGIN
	SELECT * FROM test_table01 WHERE id=@i OR kanren_id=@i
	SET @i=@i+1
END
/* [実験SQL文 1] */

と、

DECLARE @i INT

SET @i=1
WHILE (@i <= 500)
BEGIN
	SELECT * FROM test_table01 WHERE id=@i
	SELECT * FROM test_table01 WHERE kanren_id=@i
	SET @i=@i+1
END
/* [実験SQL文 2] */

（ちなみにkanren_id != idなので、上と下の結果は同じ行が出力される。出力される順番は考えない。）

と、を実行してみる。

「実験SQL文 1」は39秒、「実験SQL文 2」は29秒と、1から2で約25%の処理時間削減となる*1。
……こういうOR演算子の使い方って別におかしいものじゃないよね？
なんで、25%もの処理時間の違いが出てくるんだろう。
こういうのデータベースの実装にもよるから、別のDBでは挙動も違うんだろうな。
SQLは、必要なときにぽちぽちさわっているだけなんだけれども、内部でどういう流れで処理がされているのか想像しにくい。
自分が慣れ親しんでいるのは手続き型の言語で、集合指向型（set-oriented）の言語であるSQLの考え方はなんというかピンとこない。

*1:ちなみにXeon 3.06GHzx2、メモリ2GBのマシンで実行している。