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

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

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


1. インデックスとは?

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

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

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

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

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


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

🧩 B-treeインデックス

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

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


🧩 ビットマップインデックス(Oracleなど)

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


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

✅ 有効なケース

  • WHERE句で頻繁に検索される列

  • JOIN条件に使われる列

  • ORDER BYGROUP BYの対象列

  • 外部キー(FOREIGN KEY)列

🚫 不向きなケース

  • データ件数が極端に少ない列(例:性別など)

  • 更新頻度が高い列(INSERT/UPDATEが多いと再構築コストが増大)

  • テーブル全件を常に取得するクエリ


4. 実行計画で確認する

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

結果例(MySQLの場合)

typekeyrowsExtra
refidx_users_email1Using index

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


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

🌟 複合インデックス(複数列)

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

例:


🌟 カバリングインデックス(Covering Index)

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

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


🌟 LIKE検索の最適化

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

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


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

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

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

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


7. 実践チューニング例

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

🩹 改善策

✅ 実行計画の変化

  • 変更前:type = ALL(フルスキャン)

  • 変更後:type = ref(インデックス参照)

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


まとめ

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

🚀 結論

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

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

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

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

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

構文例説明
NOT INSELECT * FROM A WHERE ID NOT IN (SELECT ID FROM B);サブクエリの結果に含まれないIDを抽出
NOT EXISTSSELECT * 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

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

比較項目NOT INNOT 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 11とWindows 10のUI・機能・動作速度の違いをわかりやすく解説

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

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

Windows 11とWindows 10の比較表

項目Windows 10Windows 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:IN句からEXISTS句への変換方法

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

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

サンプルテーブル

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

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

IN句を使用したSQL例

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

EXISTS句を使用したSQL例

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

出力結果(IN句、EXISTS句)

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

NOT EXISTS句を使用したSQL例

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

出力結果(NOT EXISTS句)

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


補足

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

  • データベース製品(たとえば PostgreSQL/Oracle Database/MySQL)やバージョンによって、IN句とEXISTS句の内部実行プランや最適化状況が異なるため、単純に「INは遅い」「EXISTSの方が速い」と一律判断するのは危険です。

  • 実際には、サブクエリの対象件数・インデックス構成・統計情報の鮮度などがパフォーマンスに大きく影響します。EXISTSに変えたからといって必ずしも高速化するとは限りません。

  • また、可読性・保守性の観点からは「どちらが読みやすいか・将来変更しやすいか」も考慮に入れるべきです。たとえば、複雑な条件・結合・集計を伴うSQLでは、意図が明確な記述を優先したほうがトラブルを防げます。

  • 最後に、SQLのチューニングは「手段」ではなく「目的」—つまり、「実際の業務で期待されるレスポンスタイムを満たしているか」「運用負荷を適切にコントロールできているか」という観点が最も重要です。この点を忘れず、必要に応じて実行計画の確認やプロファイリングを実施してください。

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