「パフォーマンス」タグアーカイブ

PowerShell, ブログ, プログラミング

PowerShellで数十万行のCSVを高速処理するベストプラクティス

2025年11月15日管理者コメントする

PowerShellで数十万行以上のCSVを扱うと、
「読み込みが遅い」「メモリが一気に膨れる」「処理が固まったように見える」
といった問題が発生しがちです。

実はこれ、PowerShellのCSV処理の仕組みによる“あるある”で、
正しい書き方をすれば劇的に高速化できます。

この記事では、現場でも使われている 高速処理テクニック・実装例・注意点 をまとめます。

✔ なぜPowerShellはCSV処理が遅くなるのか

PowerShellの Import-Csv は便利ですが…

全行を一度にメモリへ展開する
オブジェクト化のコストが高い
数十万件を超えると数百MB〜GB級のメモリ使用

という特徴があります。

そのため、以下のような書き方は最も遅くなります。

✔ 高速化のポイントは「逐次読み込み」と「Stream処理」

PowerShellで数十万行を高速に処理する場合の最重要ポイントは以下。

💡 高速化の基本

Import-Csv を使わず StreamReader を使う
1行ずつ処理して不要になったデータは捨てる
Select-Object, Where-Object をループで使わない
型変換を最小限にする
出力は StringBuilder にまとめて最後に書き込む

✔ ベストプラクティス①：StreamReaderで逐次処理

最も高速でメモリ効率も良い方法です。

$path = "large.csv"
$out  = "result.csv"

$reader = [System.IO.StreamReader]::new($path)
$writer = [System.IO.StreamWriter]::new($out, $false, [Text.Encoding]::UTF8)

# ヘッダー読み込み
$header = $reader.ReadLine()
$writer.WriteLine($header)

# 1行ずつ高速処理
while (($line = $reader.ReadLine()) -ne $null) {
    $cols = $line.Split(",")
    
    # 例：3列目が100以上の場合だけ出力
    if ([int]$cols[2] -ge 100) {
        $writer.WriteLine($line)
    }
}

$reader.Close()
$writer.Close()

Write-Host "完了"

$path = "large.csv"

$out = "result.csv"

$reader = [System.IO.StreamReader]::new($path)

$writer = [System.IO.StreamWriter]::new($out, $false, [Text.Encoding]::UTF8)

# ヘッダー読み込み

$header = $reader.ReadLine()

$writer.WriteLine($header)

# 1行ずつ高速処理

while (($line = $reader.ReadLine()) -ne $null) {

$cols = $line.Split(",")

# 例：3列目が100以上の場合だけ出力

if ([int]$cols[2] -ge 100) {

$writer.WriteLine($line)

}

$reader.Close()

$writer.Close()

Write-Host "完了"

✔ 特徴

Import-Csv ではなく Split で直接取得 → 超高速
メモリ使用量は常に一定
数百万行でも余裕

✔ ベストプラクティス②：Import-Csv を使う場合の高速化

「やっぱりオブジェクトで扱いたい」という場合はこちら。

✔ 注意点

ForEach-Object -Parallel は PowerShell 7 以降限定
並列化は CPUコア数に依存
メモリ使用量は多め

✔ ベストプラクティス③：Select-Object / Where-Object を避ける

以下は遅くなりがち：

理由：すべての行をオブジェクトとして保持してしまう。

💡 改善

または、最速は StreamReader + Split。

✔ ベストプラクティス④：StringBuilderで出力バッファを作る

行ごとに Add-Content を実行すると激遅になります。

✔ StringBuilderを使う（高速）

✔ ベストプラクティス⑤：PowerShell 7 を使う

PowerShell 5.1 から PowerShell 7 に変えるだけで速度が倍以上になるケースが多いです。

理由

.NET Core ベースで高速化
ForEach-Object が最適化
Parallel 処理対応

✔ 実際の処理速度比較（目安）

手法	100万行の処理	メモリ使用量
Import-Csv → ループ	数十秒〜数分	数百MB〜1GB超
Import-Csv -Parallel	10〜40秒	多め
StreamReader + Split	5〜15秒	数MB

※ PCスペックにより変動。

✔ まとめ：最速は「StreamReader＋Splitによる逐次処理」

PowerShellで数十万行のCSVを高速処理するなら

✔ 最適解

逐次読み込み（ストリーム処理）
行ごとにSplitして必要な列だけ触る
StringBuilderでまとめて出力する
PowerShell 7 ならParallel化も可能

業務バッチで使う場合は、
StreamReader方式が最も安全で高速です。

実際の現場でも「メモリ溢れ対策」「速度改善」で最も採用されています。

Java, ブログ, プログラミング

Javaメモリ管理の仕組み：ガーベジコレクションとヒープの基本

2025年11月5日管理者コメントする

1. Javaのメモリ管理とは？

Javaはプログラマーが手動でメモリを解放しなくても良い言語です。
C・C++のように free() を使う必要はありません。

Javaでは、必要なくなったオブジェクトを自動で回収（解放）する仕組みが備わっています。
これを**ガーベジコレクション（Garbage Collection, GC）**と呼びます。

「解放漏れによるメモリリークが発生しづらい」
→ Javaが幅広く使われる理由の1つ

2. Javaのメモリ領域：ヒープとスタック

Javaアプリのメモリは主に次の2領域で管理されます。

領域	役割	特徴
ヒープ（Heap）	オブジェクト、配列を格納	GCの対象
スタック（Stack）	メソッド実行中の変数・参照	メソッド終了で自動解放

ヒープ領域の構造（JDK8以降）

領域	内容
Young Generation	新規オブジェクト領域（Eden、Survivor）
Old Generation	長生きするオブジェクト領域

多くのオブジェクトはすぐ不要になる → Young に多く配置するのが効率的

3. ガーベジコレクションの動き

ガーベジコレクションは、参照されなくなったオブジェクトを検出・削除します。

処理の流れ

オブジェクトを生成（ヒープに配置）
参照が切れる or 到達不能になる
GCが不要オブジェクトを回収

GCアルゴリズム（代表）

名称	特徴
Mark and Sweep	到達可能オブジェクトに印を付け、残りを削除
Copying	生きているオブジェクトを別領域に移動して残りを破棄
Generational GC	世代（Young/Old）でGC動作を変える効率化方式

4. Javaの主要GC方式（JDKバージョン別）

GC機能	特徴	対象バージョン
Serial GC	シングルスレッド、単純設計	軽量アプリ
Parallel GC	並列処理で高速	デフォルト（Java8）
G1 GC	大規模ヒープ向け、低停止時間	Java9以降推奨
ZGC	超低遅延GC、数百GB〜TB向け	Java15以降
Shenandoah	RedHat版、低遅延	OpenJDK系

5. よくあるメモリ関連エラー

❌ `java.lang.OutOfMemoryError`

ヒープ不足で発生
→ ヒープ拡張 or メモリリーク調査

❌ `StackOverflowError`

再帰のしすぎなどでスタック溢れ

❌ メモリリーク

Javaでも発生します（例：Listにaddしっぱなし）

6. メモリ管理・GCチューニングのポイント

対策	内容
不要な参照を早く消す	ローカル変数は小スコープ
大規模データは逐次処理	巨大Listを避けIterator活用
WeakReference活用	キャッシュ管理時に便利
GCログ・ツール利用	-Xmx設定、VisualVM/FlightRecorder

JVMオプション例

7. まとめ

ポイント	内容
Javaは自動メモリ管理	ガーベジコレクションが解放処理
ヒープが主な領域	Young/Old世代で効率化
GC方式は進化中	G1GC・ZGCが主流
最適化の余地あり	適切なコーディング＋JVM設定

「自動だから安心」ではなく、仕組み理解でパフォーマンス向上！

SQL, ブログ

インデックスの仕組みを理解してSQLを劇的に高速化する方法

2025年10月29日管理者コメントする

SQLの処理が遅いと感じたとき、多くの人が「サーバが遅いのでは？」と思いがちです。
しかし、実際の原因の多くは「インデックス（索引）」の使い方にあります。
この記事では、インデックスの基本構造から、実際のチューニング手法までを体系的に解説します。

1. インデックスとは？

インデックスとは、データベースが**検索を高速化するために作成する“索引”**のことです。
書籍の巻末索引のように、「この値はどこにあるか」を素早く見つけるための目次のような仕組みです。

🔹 例：インデックスなしの検索

このとき、インデックスが無ければ、データベースは全件を1件ずつ確認します（フルスキャン）。

🔹 例：インデックスありの検索

これにより、該当レコードを索引経由で一瞬で特定できるようになります。

2. インデックスの仕組みを理解する

🧩 B-treeインデックス

ほとんどのRDBMS（Oracle、MySQL、PostgreSQLなど）で採用されている構造です。
値が昇順に整理され、2分探索のように効率的に検索できます。

例えば「70」を探すとき、50より大きいので右に進み、次に70を発見します。
わずか2ステップで到達できるため、フルスキャンに比べて圧倒的に速いのです。

🧩 ビットマップインデックス（Oracleなど）

主に**値の種類が少ないカラム（性別、ステータスなど）**に有効です。
各値に対応するレコードのビットマップを管理することで、AND/OR検索が高速化します。

3. どんなカラムにインデックスを貼るべきか？

✅ 有効なケース

WHERE句で頻繁に検索される列
JOIN条件に使われる列
ORDER BYやGROUP BYの対象列
外部キー（FOREIGN KEY）列

🚫 不向きなケース

データ件数が極端に少ない列（例：性別など）
更新頻度が高い列（INSERT/UPDATEが多いと再構築コストが増大）
テーブル全件を常に取得するクエリ

4. 実行計画で確認する

SQLの速度改善は、**「インデックスが使われているか」**を確認することが第一歩です。

結果例（MySQLの場合）

type	key	rows	Extra
ref	idx_users_email	1	Using index

「Using index」と表示されていれば、インデックスが利用されています。
逆に「ALL」となっている場合はフルスキャンです。

5. インデックスを使った高速化テクニック

🌟 複合インデックス（複数列）

複数の列を組み合わせた検索で効果を発揮します。
ただし、先頭の列が条件に含まれないと使われない点に注意が必要です。

例：

🌟 カバリングインデックス（Covering Index）

インデックスに必要な列すべてを含めることで、テーブルアクセスをスキップできます。

テーブルを参照せずにインデックスだけで完結するため、極めて高速です。

🌟 LIKE検索の最適化

前方一致（Yui%）はインデックスが有効ですが、

のような部分一致はインデックス無効です。
対策としては、**全文検索エンジン（MySQLのFULLTEXT、PostgreSQLのGIN/GiST）**を使う方法があります。

6. 注意点：インデックスの弊害

インデックスは便利ですが、万能ではありません。
特に以下の点には注意が必要です。

リスク	説明
更新コスト増大	INSERTやUPDATE時にインデックスも更新されるため、処理が重くなる
ストレージ消費	大規模テーブルに多くのインデックスを張ると、容量が急増
メンテナンス負荷	不要なインデックスを放置すると、統計情報がずれて性能が劣化

🧹 定期的に ANALYZE TABLE や REBUILD INDEX を実施して、統計情報を更新しましょう。

7. 実践チューニング例

✏️ 例1：検索が遅いクエリ

🩹 改善策

✅ 実行計画の変化

変更前：type = ALL（フルスキャン）
変更後：type = ref（インデックス参照）

実行時間が数秒 → 数ミリ秒まで短縮されることもあります。

まとめ

ポイント	内容
インデックスとは	データ検索を高速化するための“索引”
構造	B-treeが主流。ビットマップは限定用途
効果的な付与	検索条件、JOIN、GROUP BY、ORDER BY列
落とし穴	更新負荷、容量増加、部分一致非対応
確認方法	EXPLAINで実行計画を必ずチェック

🚀 結論

インデックスを理解すれば、SQLの速度は10倍以上高速化することも珍しくありません。
なんとなく作るのではなく、「どう検索されるか」を意識して設計することが重要です。

SQL, ブログ

SQL：NOT IN と NOT EXISTS の違いとパフォーマンス比較

2025年10月10日管理者コメントする

SQLでサブクエリを使って除外条件を指定する際に利用される「NOT IN」と「NOT EXISTS」。両者の動作の違いやNULLの扱い、パフォーマンス差を実例付きで徹底解説します。

EXISTS は ANSI SQL（国際標準SQL）に含まれる構文 のため、
ほぼすべてのリレーショナルデータベースで利用できます。
古いバージョンの一部DBを除き、標準構文として移植性が非常に高いのが特徴です。

1. NOT IN と NOT EXISTS の基本構文

句	構文例	説明
NOT IN	SELECT * FROM A WHERE ID NOT IN (SELECT ID FROM B);	サブクエリの結果に含まれないIDを抽出
NOT EXISTS	SELECT * FROM A WHERE NOT EXISTS (SELECT 1 FROM B WHERE A.ID = B.ID);	Bに同じIDが存在しない場合のみAを取得

ポイント：

両者とも「除外」目的だが、評価タイミングとNULL処理が異なる。

2. 動作の違い（NULLの扱いに注目）

条件	NOT INの結果	NOT EXISTSの結果
サブクエリにNULLが含まれる	すべての行が除外される	正常に比較できる
サブクエリが空（0件）	全件取得される	全件取得される

理由：
NOT IN は内部的に「A.ID <> B.ID」を繰り返すような処理を行うため、NULLが含まれると比較結果がUNKNOWNとなり、全体が評価されなくなる。
一方、NOT EXISTS は行ごとに存在チェックを行うため、NULLの影響を受けない。

3. 実行結果の比較例

以下の例を見てみましょう。

テーブルA

ID	NAME
1	田中
2	鈴木
3	佐藤

テーブルB

ID
1
NULL

-- NOT IN
SELECT * FROM A WHERE ID NOT IN (SELECT ID FROM B);
-- 結果：0件（NULLが含まれているため）

-- NOT EXISTS
SELECT * FROM A WHERE NOT EXISTS (SELECT 1 FROM B WHERE A.ID = B.ID);
-- 結果：ID=2,3 が取得される

-- NOT IN

SELECT * FROM A WHERE ID NOT IN (SELECT ID FROM B);

-- 結果：0件（NULLが含まれているため）

-- NOT EXISTS

SELECT * FROM A WHERE NOT EXISTS (SELECT 1 FROM B WHERE A.ID = B.ID);

-- 結果：ID=2,3 が取得される

4. パフォーマンスの違い

比較項目	NOT IN	NOT EXISTS
NULLの影響	受ける	受けない
実行計画（最適化）	インデックス利用されにくい場合あり	最適化されやすい
大量データ時の効率	遅くなるケースあり	より安定して高速
Oracleの最適化傾向	半結合（Anti-Join）に変換されることあり	同様に最適化される

実測例（概略）

件数	NOT IN所要時間	NOT EXISTS所要時間
1万件	0.25秒	0.20秒
10万件	3.1秒	1.8秒

※ 実測環境：Oracle 19c、インデックスあり、CPU 4コア相当

5. どちらを使うべきか

条件	推奨句
サブクエリにNULLが含まれる可能性あり	NOT EXISTS
データが小規模でNULLなし	どちらでも可
大規模データ・実行計画を重視	NOT EXISTS（推奨）
可読性を優先	NOT EXISTS のほうが誤動作が少ない

6. まとめ

観点	内容
ANSI SQL対応	○（どのDBでも使用可能）
実行パフォーマンス	DBごとに最適化される（MySQL 8以降で特に改善）
推奨度	高い（NOT INより安全で移植性が高い）
注意点	MySQL 5.x 以前では最適化が弱いケースがある

✔ 結論：
除外条件を指定する場合は、基本的に「NOT EXISTS」を使う方が安全で高速です。
ただし、NULLが確実に存在しないことが保証される小規模データではNOT INも選択肢になります。

Windows, ブログ

Windows 11とWindows 10のUI・機能・動作速度の違いをわかりやすく解説

2025年9月15日管理者コメントする

2025年10月14日で Windows 10のサポートが完全終了 します。つまり、あと1か月足らずでセキュリティ更新が受けられなくなります。
「今Windows 10を使っているけど、Windows 11に移行すべき？」というユーザーが非常に多い時期です。

そこで本記事では、Windows 11とWindows 10の UI（デザイン）・機能・動作速度 の違いを整理し、2025年9月現在の状況を踏まえて解説します。

Windows 11とWindows 10の比較表

項目	Windows 10	Windows 11	コメント（2025年9月時点）
サポート期限	2025年10月14日まで	継続（現行版は2031年頃まで想定）	Windows 10はサポート終了目前
スタートメニュー	左下配置・ライブタイルあり	中央配置・シンプルUI	慣れやすさ重視なら10、モダンなら11
ウィンドウデザイン	角ばったデザイン	角が丸く柔らかい印象	見た目の違いが大きい
タスクバー	上下左右に移動可能	下固定・柔軟性少ない	カスタマイズ性は10が有利
新機能	基本更新のみ	スナップレイアウト、ウィジェット、DirectStorageなど	生産性・ゲーム用途は11が強い
互換性	古いアプリ・周辺機器も動作しやすい	古い機器は非対応の可能性あり	企業利用では要検証
動作速度	古いPCでも動作	新ハードで最適化、体感的に高速	性能を引き出すには新PC推奨
セキュリティ	更新は終了予定	TPM 2.0必須、強化済み	今後は11一択になる見込み
ゲーム性能	DirectX 12まで	DirectStorage・AutoHDR対応	ゲーマーは11必須

今の選択肢（2025年9月時点）

Windows 11へ移行
→ サポート継続、最新機能・セキュリティが利用可能。
Windows 10を使い続ける
→ 来月以降は更新が止まり、セキュリティリスク直結。業務利用は極めて危険。
PC買い替え
→ 要件（TPM 2.0、CPU世代）を満たさない古いPCはアップグレード不可。買い替え検討が必要。

1. UI（デザイン・操作性）の違いと移行のインパクト

Windows 11は中央寄せのスタートメニューや丸みを帯びたウィンドウなど、モダンで洗練された印象。
Windows 10は従来型のUIに慣れている人には安心感があるが、今後サポートが切れるため使い続けるリスクあり。
切迫点：Windows 11の操作に慣れる猶予期間が「今」しか残されていない。

2. 機能面の違い ― 移行しないと使えない新機能

Windows 11には スナップレイアウト・ウィジェット・DirectStorage などの新機能が搭載。
Windows 10では利用できず、今後も更新されない。
切迫点：業務効率化やゲーム性能で差が拡大中。

3. 動作速度・パフォーマンスの違い

Windows 11は最新CPUやSSDで高速化が体感できる設計。
Windows 10は古いPCで安定動作するが、性能を引き出す更新はもう来ない。
切迫点：古いPCをWindows 11にアップグレードできない場合、買い替えの判断が必須に。

4. 2025年9月の選択肢 ― 待ったなし！

Windows 11に移行する：サポートが続き、最新機能・セキュリティが得られる。
Windows 10を使い続ける：1か月後にはセキュリティリスク直結。企業利用は特に危険。
PC買い替えも検討：要件（TPM 2.0や新CPU）を満たさないPCではアップグレード不可。

まとめ

2025年9月時点では、Windows 10とWindows 11の違いは「比較検討」の段階を過ぎ、移行判断を迫られている状況 です。

Windows 10は来月で完全サポート終了
Windows 11は最新UI・機能・速度で進化を続ける
今のうちに移行しないとセキュリティリスクが現実化する

👉 結論：まだ迷っているなら「今」移行準備を始めるべきです。

SQL, ブログ

SQL：IN句からEXISTS句への変換方法

2022年6月9日管理者コメントする

IN句をEXISTS句へ変換するとパフォーマンスが向上すると言われることがあるので

IN句からEXISTS句への変換例をメモしておきます。

サンプルテーブル

以下の商品テーブル「goods」と属性コードテーブル「type_code」を元に説明します。

商品テーブル「goods」	属性コードテーブル「type_code」
"	"

IN句を使用したSQL例

商品テーブル「goods」のtype_codeが ‘101’で属性コードテーブル「type_code」にも存在する商品名を取得する例となります。

SELECT tc.code_name
FROM type_code AS tc
WHERE
 tc.code IN(SELECT type_code FROM goods WHERE type_code = '101');

SELECT tc.code_name

FROM type_code AS tc

WHERE

tc.code IN(SELECT type_code FROM goods WHERE type_code = '101');

EXISTS句を使用したSQL例

WHERE句後の「tc.code IN」を「EXISTS」に変更し、「AND type_code = tc.code」を追加しただけです。

SELECT tc.code_name
FROM type_code AS tc
WHERE 
 EXISTS
 (SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

SELECT tc.code_name

FROM type_code AS tc

WHERE

EXISTS

(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

出力結果（IN句、EXISTS句）

IN句、EXISTS句どちらの場合も以下の結果となります。

NOT EXISTS句を使用したSQL例

EXISTS句は使い慣れてないと今一つ分かりにくい気がするので、上記のEXISTSをNOT EXISTSで実行してみた例も記載しておきます。なんとなくEXISTSがどういう結果を出力しているかわかるかも。。

SELECT tc.code_name
FROM type_code AS tc
WHERE 
 NOT EXISTS(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

SELECT tc.code_name

FROM type_code AS tc

WHERE

NOT EXISTS(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

出力結果（NOT EXISTS句）

NOT EXISTS句の結果は以下となります。

補足

本稿では、 IN句から EXISTS句への変換例およびその基本的な使い分けを紹介しましたが、実運用においては以下の点にもご留意ください。

データベース製品（たとえば PostgreSQL／Oracle Database／MySQL）やバージョンによって、IN句とEXISTS句の内部実行プランや最適化状況が異なるため、単純に「INは遅い」「EXISTSの方が速い」と一律判断するのは危険です。
実際には、サブクエリの対象件数・インデックス構成・統計情報の鮮度などがパフォーマンスに大きく影響します。EXISTSに変えたからといって必ずしも高速化するとは限りません。
また、可読性・保守性の観点からは「どちらが読みやすいか・将来変更しやすいか」も考慮に入れるべきです。たとえば、複雑な条件・結合・集計を伴うSQLでは、意図が明確な記述を優先したほうがトラブルを防げます。
最後に、SQLのチューニングは「手段」ではなく「目的」—つまり、「実際の業務で期待されるレスポンスタイムを満たしているか」「運用負荷を適切にコントロールできているか」という観点が最も重要です。この点を忘れず、必要に応じて実行計画の確認やプロファイリングを実施してください。

引き続き、SQL設計・実装・運用の改善にお役立ていただければ幸いです。
今後も他の観点（たとえば JOINの最適化／ウィンドウ関数の活用／データ量に対するスケーリング）についても、機会を改めてご紹介したいと思います。

✔ なぜPowerShellはCSV処理が遅くなるのか

✔ 高速化のポイントは「逐次読み込み」と「Stream処理」

💡 高速化の基本

✔ ベストプラクティス①：StreamReaderで逐次処理

✔ 特徴

✔ ベストプラクティス②：Import-Csv を使う場合の高速化

✔ 注意点

✔ ベストプラクティス③：Select-Object / Where-Object を避ける

💡 改善

✔ ベストプラクティス④：StringBuilderで出力バッファを作る

✔ StringBuilderを使う（高速）

✔ ベストプラクティス⑤：PowerShell 7 を使う

理由

✔ 実際の処理速度比較（目安）

✔ まとめ：最速は「StreamReader＋Splitによる逐次処理」

✔ 最適解

関連記事

1. Javaのメモリ管理とは？

2. Javaのメモリ領域：ヒープとスタック

ヒープ領域の構造（JDK8以降）

3. ガーベジコレクションの動き

処理の流れ

GCアルゴリズム（代表）

4. Javaの主要GC方式（JDKバージョン別）

5. よくあるメモリ関連エラー

❌ java.lang.OutOfMemoryError

❌ StackOverflowError

❌ メモリリーク

6. メモリ管理・GCチューニングのポイント

JVMオプション例

7. まとめ

関連記事

1. インデックスとは？

🔹 例：インデックスなしの検索

🔹 例：インデックスありの検索

2. インデックスの仕組みを理解する

🧩 B-treeインデックス

🧩 ビットマップインデックス（Oracleなど）

3. どんなカラムにインデックスを貼るべきか？

✅ 有効なケース

🚫 不向きなケース

4. 実行計画で確認する

結果例（MySQLの場合）

5. インデックスを使った高速化テクニック

🌟 複合インデックス（複数列）

🌟 カバリングインデックス（Covering Index）

🌟 LIKE検索の最適化

6. 注意点：インデックスの弊害

7. 実践チューニング例

✏️ 例1：検索が遅いクエリ

🩹 改善策

✅ 実行計画の変化

まとめ

🚀 結論

関連記事

1. NOT IN と NOT EXISTS の基本構文

2. 動作の違い（NULLの扱いに注目）

3. 実行結果の比較例

テーブルA

テーブルB

4. パフォーマンスの違い

5. どちらを使うべきか

6. まとめ

関連記事

Windows 11とWindows 10の比較表

今の選択肢（2025年9月時点）

1. UI（デザイン・操作性）の違いと移行のインパクト

2. 機能面の違い ― 移行しないと使えない新機能

3. 動作速度・パフォーマンスの違い

4. 2025年9月の選択肢 ― 待ったなし！

まとめ

関連記事

サンプルテーブル

IN句を使用したSQL例

EXISTS句を使用したSQL例

出力結果（IN句、EXISTS句）

NOT EXISTS句を使用したSQL例

出力結果（NOT EXISTS句）

補足

関連記事

　関連記事

❌ `java.lang.OutOfMemoryError`

❌ `StackOverflowError`

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事