あいまいなテキスト データではなく、質問にコードを含めることをお勧めします。これにより、全員が同じデータを操作できるようになります。私が想定したサンプルのスキーマとデータは次のとおりです。
CREATE TABLE tbl_data (
id INT NOT NULL,
code_1 CHAR(2),
code_2 CHAR(2)
);
INSERT INTO tbl_data (
id,
code_1,
code_2
)
VALUES
(1, 'AB', 'BC'),
(2, 'BC', NULL),
(3, 'DE', 'EF'),
(4, NULL, 'BC');
Blorgbeardがコメントしたように、演算子は重複行を排除するため、ソリューションの句はDISTINCT
不要です。重複を排除しない演算子がありますが、ここでは適切ではありませんUNION
。UNION ALL
句なしでクエリを書き直すことDISTINCT
は、この問題の優れた解決策です。
SELECT code_1
FROM tbl_data
WHERE code_1 IS NOT NULL
UNION
SELECT code_2
FROM tbl_data
WHERE code_2 IS NOT NULL;
2 つの列が同じテーブルにあることは問題ではありません。列が異なるテーブルにある場合でも、解決策は同じです。
同じフィルター句を 2 回指定する冗長性が気に入らない場合は、それをフィルター処理する前に、ユニオン クエリを仮想テーブルにカプセル化できます。
SELECT code
FROM (
SELECT code_1
FROM tbl_data
UNION
SELECT code_2
FROM tbl_data
) AS DistinctCodes (code)
WHERE code IS NOT NULL;
2 番目の構文の方が見にくいと思いますが、論理的にはすっきりしています。しかし、どちらがより優れたパフォーマンスを発揮しますか?
SQL Server 2005 のクエリ オプティマイザーが 2 つの異なるクエリに対して同じ実行プランを生成することを示すsqlfiddleを作成しました。

SQL Server が 2 つのクエリに対して同じ実行プランを生成する場合、それらは実質的にも論理的にも同等です。
上記を質問のクエリの実行計画と比較してください。

この句により、SQL Server 2005 は冗長な並べ替え操作を実行します。これは、クエリ オプティマイザが、最初のクエリでDISTINCT
によって除外された重複が後のクエリで除外されることを認識していないためです。DISTINCT
UNION
このクエリは他の 2 つのクエリと論理的に同等ですが、冗長な操作により効率が低下します。大規模なデータ セットでは、クエリが結果セットを返すのに、ここにある 2 つよりも時間がかかると予想されます。私の言葉を鵜呑みにしないでください。自分の環境で試してみてください。