「SQL」タグアーカイブ

SQL, ブログ

SQL：実行計画（EXPLAIN PLAN）の読み方とボトルネックの見つけ方

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

データベースチューニングにおいて「どのSQLが遅いのか」だけでなく、「どの処理がボトルネックなのか」を正しく把握することは非常に重要です。
そのための基本ツールが**実行計画（EXPLAIN PLAN）**です。

本記事では、Oracleを例に実行計画の見方とボトルネックの探し方を、初心者でも理解できるように解説します。

✅ EXPLAIN PLANとは？

SQLを実行する際、Oracleが内部的に考える**最適な実行手順（アクセス方法）**を表示する機能です。

実行計画を見ることで、次のようなことがわかります。

テーブルにアクセスする順番
インデックスを使っているかどうか
結合（JOIN）の方式
フルスキャンが走っているか
コスト（予測負荷）

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

GUI環境ではワンクリックで参照できます。

✅ Oracle実行計画の基本構造

実行計画は階層構造で、上から順に処理が行われます。
インデントが深いほど「その処理の中で実行される詳細処理」です。

例：

--------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    24 |     2   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    24 |     2   (0)|
|   2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     1   (0)|
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 24 | 2 (0)|

| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 24 | 2 (0)|

| 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 1 (0)|

--------------------------------------------------------------------------------

✅ よく出るOperationと解釈ポイント

Operation	説明	見どころ
TABLE ACCESS FULL	テーブルの全件スキャン	大量データで出たら要注意
TABLE ACCESS BY INDEX ROWID	インデックス参照後にROWIDアクセス	最適パターンの一つ
INDEX UNIQUE SCAN	主キー・ユニークインデックス検索	高速
INDEX RANGE SCAN	範囲検索	効率的だが条件次第
HASH JOIN	ハッシュ表でJOIN	大量データ向き、メモリ消費
NESTED LOOPS	小規模データに適したJOIN	結合相手の行数が多いと遅い
SORT ORDER BY	並び替え	必要ならOK、無駄がないか確認

✅ ボトルネックの探し方

① TABLE ACCESS FULL に注意

条件にインデックスが効いていない可能性
大規模テーブルで特に危険

対策：

WHERE句に使う列にインデックス追加
不必要なSELECT *を避ける
ファンクションインデックス

② JOIN方式を確認

JOIN方式	特徴	適したケース
NESTED LOOPS	小テーブル to 大テーブルに◎	OLTP向き
HASH JOIN	大量データ向き、高速	DWH向き
MERGE JOIN	並び替え前提、ソート負荷	ソート後結合

Nested Loops × 大量データ → 遅い可能性

③ コスト（COST）とROWSを確認

項目	意味
ROWS	見積もられる行数
COST	Oracleが見積もる負荷指数
BYTES	データ量

COSTが極端に高い行がボトルネック候補。

④ SORTが多い場合

ORDER BY や DISTINCTが多いと遅くなる

対策：

必要な場面以外でDISTINCT使用しない
ORDER BYの列にインデックス

✅ 実例：遅いSQLの典型パターン

問題点

UPPER(ENAME) → 関数でインデックス無効
LIKE ‘%〇〇’ → 前方ワイルドカードでインデックス無効
SELECT * → 不要な列読み込み

改善例

✅ チューニングの基本手順まとめ

ステップ	内容
1	実行計画を見る
2	TABLE FULL SCANをチェック
3	JOIN方法確認（Nested Loops vs Hash Join）
4	コスト高い箇所を特定
5	インデックス／SQL修正

✅ まとめ

EXPLAIN PLANはSQLの動作設計図
インデックス利用とJOIN方式を重視
FULL SCANと高コスト行は警戒
必要な列だけ取得し、関数利用に注意

SQLチューニングは**「まず実行計画を見る」**がスタートです。
慣れるほど読み解きが早くなり、効率的な分析ができるようになります。

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：MERGE文でINSERTとUPDATEを一度に行う効率的な方法

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

MERGE文とは？

SQLのMERGE文は、対象テーブルにデータが存在する場合はUPDATE、存在しない場合はINSERTを1回の処理でまとめて行える便利な構文です。
従来は「UPDATE → 該当しなければINSERT」といった2回の処理が必要でしたが、MERGEを使うことで1回のSQLで済むため、処理効率やパフォーマンスが向上します。

本記事ではOracleをベースに解説しつつ、他DBでの対応についても補足します。

MERGE文の基本構文（Oracleの場合）

MERGE INTO 対象テーブル T
USING 参照元テーブル S
ON (T.キー = S.キー)
WHEN MATCHED THEN
    UPDATE SET T.カラムA = S.カラムA,
               T.カラムB = S.カラムB
WHEN NOT MATCHED THEN
    INSERT (カラムA, カラムB, カラムC)
    VALUES (S.カラムA, S.カラムB, S.カラムC);

MERGE INTO 対象テーブル T

USING 参照元テーブル S

ON (T.キー = S.キー)

WHEN MATCHED THEN

UPDATE SET T.カラムA = S.カラムA,

T.カラムB = S.カラムB

WHEN NOT MATCHED THEN

INSERT (カラムA, カラムB, カラムC)

VALUES (S.カラムA, S.カラムB, S.カラムC);

実用例①：顧客マスタの更新 or 追加

MERGE INTO CUSTOMER T
USING (SELECT 'C001' AS ID, '山田太郎' AS NAME, 'TOKYO' AS ADDRESS FROM DUAL) S
ON (T.ID = S.ID)
WHEN MATCHED THEN
    UPDATE SET T.NAME = S.NAME,
               T.ADDRESS = S.ADDRESS
WHEN NOT MATCHED THEN
    INSERT (ID, NAME, ADDRESS)
    VALUES (S.ID, S.NAME, S.ADDRESS);

MERGE INTO CUSTOMER T

USING (SELECT 'C001' AS ID, '山田太郎' AS NAME, 'TOKYO' AS ADDRESS FROM DUAL) S

ON (T.ID = S.ID)

WHEN MATCHED THEN

UPDATE SET T.NAME = S.NAME,

T.ADDRESS = S.ADDRESS

WHEN NOT MATCHED THEN

INSERT (ID, NAME, ADDRESS)

VALUES (S.ID, S.NAME, S.ADDRESS);

✅ ID=C001 が存在すれば更新
✅ 存在しなければ新規追加

処理の流れ（フロー図で理解）

          +----------------------+
          | 対象テーブルに該当   |
          | レコードは存在する？ |
          +----------+-----------+
                     |
          YES ←------+→ NO
           |                 |
UPDATE処理        INSERT処理

+----------------------+

| 対象テーブルに該当 |

| レコードは存在する？ |

+----------+-----------+

YES ←------+→ NO

| |

UPDATE処理 INSERT処理

応用例②：条件によってDELETEも行う（Oracle/SQL Server対応）

MERGE INTO ORDER_TABLE T
USING NEW_ORDER_DATA S
ON (T.ORDER_ID = S.ORDER_ID)
WHEN MATCHED AND S.STATUS = 'CANCEL' THEN
    DELETE
WHEN MATCHED THEN
    UPDATE SET T.AMOUNT = S.AMOUNT,
               T.STATUS = S.STATUS
WHEN NOT MATCHED THEN
    INSERT (ORDER_ID, AMOUNT, STATUS)
    VALUES (S.ORDER_ID, S.AMOUNT, S.STATUS);

MERGE INTO ORDER_TABLE T

USING NEW_ORDER_DATA S

ON (T.ORDER_ID = S.ORDER_ID)

WHEN MATCHED AND S.STATUS = 'CANCEL' THEN

DELETE

WHEN MATCHED THEN

UPDATE SET T.AMOUNT = S.AMOUNT,

T.STATUS = S.STATUS

WHEN NOT MATCHED THEN

INSERT (ORDER_ID, AMOUNT, STATUS)

VALUES (S.ORDER_ID, S.AMOUNT, S.STATUS);

✅ ステータスがCANCELなら削除
✅ そうでなければ更新
✅ 該当なしならINSERT

MERGE文のメリット

項目	従来方法	MERGE文
SQL実行回数	UPDATEとINSERTの2回	1回
パフォーマンス	やや低い	高い
ロジックの明確さ	分岐が必要	条件分が整理されやすい
メンテナンス性	低め	高い

注意点

注意点	内容
ロックの影響	大量データの場合、テーブルロックが発生しやすい
複雑な条件	WHEN句が増えると可読性が下がる
DB依存性	MySQLは8.0.19以降、PostgreSQLはINSERT ... ON CONFLICTで代替

他DBでの補足

DB	MERGE対応	備考
Oracle	対応	本記事基準
SQL Server	対応	ほぼ同構文
MySQL	8.0.19～対応	REPLACE/INSERT ON DUPLICATEも可
PostgreSQL	15～対応	それ以前はINSERT ON CONFLICT

まとめ

✅ MERGE文はINSERTとUPDATEを1回の処理にまとめる強力なSQL構文
✅ DELETEも組み合わせれば高度なロジックも実現可能
✅ Oracle・SQL Serverでは標準的に使用される
✅ MySQL/PostgreSQLではバージョン確認が必要

「同じキーのデータを更新 or 追加したい」場面で積極的に使いましょう！

SQL, ブログ

SQL：インデックスヒント（INDEX HINT）でクエリ最適化を行う方法

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

1. インデックスヒントとは？

SQLの**インデックスヒント（INDEX HINT）**とは、データベースに対して「このテーブルでは特定のインデックスを使用して実行してほしい」と明示的に指示するための構文です。
通常、DBエンジン（オプティマイザ）が自動で最適な実行計画を選びますが、統計情報が古い・複雑な条件句などの場合に誤ったインデックスを選ぶことがあります。

そのようなとき、開発者が明示的にインデックスを指定して最適化を誘導するのがINDEX HINTの目的です。

2. 一般的な書き方

Oracleの場合

MySQLの場合

SQL Serverの場合

データベース	ヒント指定方法	備考
Oracle	/+ INDEX(テーブル名インデックス名) /	ヒント句はコメント形式
MySQL	USE INDEX (インデックス名)	FORCE INDEX / IGNORE INDEX も可
SQL Server	WITH (INDEX(インデックス名))	テーブルヒントとして指定

3. MySQLにおけるINDEX HINTの種類

種類	意味	使用例
USE INDEX	指定したインデックスを優先的に使用	USE INDEX (idx_col1)
FORCE INDEX	指定インデックスを強制的に使用	FORCE INDEX (idx_col1)
IGNORE INDEX	指定インデックスを無視して検索	IGNORE INDEX (idx_col1)

4. 実行計画を確認する

インデックスヒントを付与したら、実際に利用されているかを確認することが重要です。

MySQL

Oracle

EXPLAIN PLAN FOR
SELECT /*+ INDEX(employees emp_dept_idx) */ * FROM employees WHERE department_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

EXPLAIN PLAN FOR

SELECT /*+ INDEX(employees emp_dept_idx) */ * FROM employees WHERE department_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

チェック項目	内容
key列（MySQL）	使用されたインデックス名
access path（Oracle）	INDEX RANGE SCAN などが表示される
実行コスト	コストが下がっているか確認

5. 使用上の注意点

注意点	内容
1. 過信しない	ヒントは一時的なチューニングであり、将来的な統計情報変化で逆効果になることも。
2. 実行計画を常に確認	ヒント適用後は EXPLAIN で確認すること。
3. SQL互換性に注意	各DBMSで構文が異なるため、移植性が下がる。
4. ヒント指定よりも統計情報更新が基本	統計情報を更新することで自動最適化が正しく働くことも多い。

6. 実用例：複合インデックスを明示的に使用

以下のように複数条件を持つ検索で、DBが誤ったインデックスを選ぶ場合に有効です。

このように、複合インデックスの指定順序に合わせてヒントを指定することで、不要な全件スキャンを防ぐことができます。

7. まとめ

ポイント	内容
自動最適化が基本	まずはDBエンジンに任せるのが原則
ヒントは最終手段	特定クエリで誤選択時のみ使用
EXPLAINで検証	効果を数値で確認
統計情報更新も忘れずに	オプティマイザの精度を保つために重要

SQL, ブログ

SQL：ウィンドウ関数（OVER句）でランキング・累計を計算する

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

データ分析やレポート作成では、「順位付け」 や 「累計」 のような集計処理がよく登場します。
従来はサブクエリや自己結合を使う必要がありましたが、SQLの ウィンドウ関数（OVER句） を使えば簡潔に記述できます。
この記事では、代表的な使い方と主要DBMSごとの対応状況をサンプル付きで解説します。

🧠 ウィンドウ関数とは？

ウィンドウ関数とは、集計関数に対して「範囲（ウィンドウ）」を指定できる機能です。
通常の SUM() や AVG() はグループ全体を集計しますが、OVER() を使うことで「行単位の集計」も可能になります。

🔸 基本構文

句	役割
PARTITION BY	グループを分ける（省略可）
ORDER BY	並び順を指定
ROWS BETWEEN ～	範囲を細かく指定（任意）

🏅 ランキングを求める

商品の売上データを例に、売上額で順位をつけます。

📘 サンプルテーブル：sales

product	category	amount
A	飲料	300
B	飲料	500
C	食品	400
D	食品	200
E	食品	700

📗 SQL例

📊 実行結果

category	product	amount	rank
飲料	B	500	1
飲料	A	300	2
食品	E	700	1
食品	C	400	2
食品	D	200	3

✅ ポイント

同じカテゴリ内で順位を付与 (PARTITION BY category)
売上が高い順に並び替え (ORDER BY amount DESC)
RANK() は同順位がある場合にスキップ（例：1位,1位,3位）

🔢 累計を求める

カテゴリ別に売上の累計を出してみましょう。

📗 SQL例

📊 結果

category	product	amount	running_total
飲料	B	500	500
飲料	A	300	800
食品	E	700	700
食品	C	400	1100
食品	D	200	1300

✅ ポイント

SUM() に OVER() を組み合わせることで行ごとの累積が可能
ORDER BY により順序を指定できる
PARTITION BY を省略すると全体累計に

🧮 他の代表的なウィンドウ関数

関数	説明
ROW_NUMBER()	連番（重複なし）を付与
RANK()	同順位があるとスキップ（例：1,1,3）
DENSE_RANK()	同順位があっても連続（例：1,1,2）
NTILE(n)	n等分にグループ分け（例：四分位）
LAG(col, n)	n行前の値を取得
LEAD(col, n)	n行後の値を取得
SUM(), AVG(), MAX(), MIN()	累計・平均などの集計を行単位で

💡 応用例：前回比を計算する

前回の売上からの増減を求めたい場合は LAG() 関数を使用します。

SELECT
  category,
  product,
  amount,
  LAG(amount) OVER (PARTITION BY category ORDER BY amount DESC) AS prev_amount,
  amount - LAG(amount) OVER (PARTITION BY category ORDER BY amount DESC) AS diff
FROM sales;

SELECT

category,

product,

amount,

LAG(amount) OVER (PARTITION BY category ORDER BY amount DESC) AS prev_amount,

amount - LAG(amount) OVER (PARTITION BY category ORDER BY amount DESC) AS diff

FROM sales;



FROM sales;

category	product	amount	prev_amount	diff
飲料	B	500	NULL	NULL
飲料	A	300	500	-200
食品	E	700	NULL	NULL
食品	C	400	700	-300
食品	D	200	400	-200

🧭 DBMS別のウィンドウ関数対応表

DBMS	対応状況	対応バージョン	備考
Oracle Database	◎ 完全対応	8i 以降	ウィンドウ関数発祥の実装。機能最も豊富
PostgreSQL	◎ 完全対応	8.4 以降	PARTITION, ORDER, RANGE句など全対応
MySQL	○ 部分対応	8.0 以降	8.0から正式対応（それ以前は非対応）
SQL Server	◎ 完全対応	2012 以降	LAG/LEADなどもサポート
SQLite	○ 部分対応	3.25 以降	一部関数は制限あり（NTILEなど）
MariaDB	△ 限定対応	10.2 以降	SUMなどは対応、LAG/LEADは制限あり
IBM Db2	◎ 完全対応	9.7 以降	分析関数として強力なサポートあり
Snowflake / BigQuery	◎ 完全対応	最新	クラウドDWH系でもネイティブ対応

✅ 補足

旧バージョンのMySQL（5.x系）ではウィンドウ関数が非対応のため、サブクエリで代替が必要。
PostgreSQLとOracleはROWS BETWEENなどの範囲指定も細かく制御可能。
BigQueryはOVER()句のほかQUALIFY句でフィルタリングが可能。

🔍 まとめ

観点	内容
機能	グループ単位での行ごとの集計・順位付け
主な用途	累計・ランキング・前回比・順位比較
メリット	サブクエリ不要・可読性向上・パフォーマンス改善
対応DB	Oracle, PostgreSQL, SQL Server, MySQL 8+, BigQueryなど

ウィンドウ関数は、分析SQLの最重要機能といっても過言ではありません。
集計・比較・順位などを自在に扱えるようになれば、レポート作成の幅が大きく広がります。

Oracle, データベース, トラブル対応, ブログ

🧩 Oracle「ORA-01000: 最大オープン・カーソル数を超えました」対処手順

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

🔍 エラー概要

項目	内容
エラーコード	ORA-01000
メッセージ	最大オープン・カーソル数を超えました
発生原因	開いたカーソルをクローズせずに処理を繰り返した結果、open_cursors の上限に達した
対応優先度	高（アプリケーション修正・設定見直しが必要）

🧠 原因と仕組み

Oracle では、SQL 実行時に「カーソル」という内部ハンドルを使用して SQL 文を管理します。
アプリケーションが PreparedStatement や ResultSet を閉じずに再利用し続けると、未解放のカーソルが蓄積し、open_cursors パラメータで設定された上限値を超えた時点で ORA-01000 が発生します。

🧩 よくある原因パターン

原因	詳細
JDBCのクローズ漏れ	ResultSet や Statement を close() していない
ループ内で毎回 SQL を prepare	PreparedStatement を都度生成して再利用していない
コネクションプールの設定ミス	コネクションが正しく解放されず、カーソルが残存
長時間実行バッチ	同一セッションで大量SQLを連続実行してカーソルが累積
外部ライブラリのバグ	ORM（MyBatis、Hibernate等）でのカーソル管理不具合

🧭 対処法（順序付き）

手順	対処内容
①	アプリケーションコードを点検（ResultSet, Statement, Connection を確実に close）
②	try-with-resources 構文を使用して自動クローズ化（Java7以降推奨）
③	open_cursors パラメータ値を確認（show parameter open_cursors;）
④	必要に応じて上限を引き上げ（例：ALTER SYSTEM SET open_cursors = 1000 SCOPE=BOTH;）
⑤	v$open_cursor ビューで調査（どのSQLが残っているか確認）

🔧 調査SQL例

-- 現在のopen_cursors設定値を確認
SHOW PARAMETER open_cursors;

-- 現在開いているカーソルの状況を確認
SELECT
    s.sid,
    s.serial#,
    a.value AS open_cursor_count,
    s.username,
    s.program
FROM v$sesstat a
JOIN v$statname b ON a.statistic# = b.statistic#
JOIN v$session s  ON s.sid = a.sid
WHERE b.name = 'opened cursors current'
ORDER BY a.value DESC;

-- どのSQLが開きっぱなしになっているかを確認
SELECT sid, sql_id, sql_text
FROM v$open_cursor
WHERE sid = <問題セッションSID>;

-- 現在のopen_cursors設定値を確認

SHOW PARAMETER open_cursors;

-- 現在開いているカーソルの状況を確認

SELECT

s.sid,

s.serial#,

a.value AS open_cursor_count,

s.username,

s.program

FROM v$sesstat a

JOIN v$statname b ON a.statistic# = b.statistic#

JOIN v$session s ON s.sid = a.sid

WHERE b.name = 'opened cursors current'

ORDER BY a.value DESC;

-- どのSQLが開きっぱなしになっているかを確認

SELECT sid, sql_id, sql_text

FROM v$open_cursor

WHERE sid = <問題セッションSID>;

💡 Javaでの修正例（try-with-resources構文）

String sql = "SELECT * FROM EMPLOYEES WHERE DEPT_ID = ?";
try (Connection conn = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, 10);
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            System.out.println(rs.getString("EMP_NAME"));
        }
    }
} catch (SQLException e) {
    e.printStackTrace();
}

String sql = "SELECT * FROM EMPLOYEES WHERE DEPT_ID = ?";

try (Connection conn = dataSource.getConnection();

PreparedStatement ps = conn.prepareStatement(sql)) {

ps.setInt(1, 10);

try (ResultSet rs = ps.executeQuery()) {

while (rs.next()) {

System.out.println(rs.getString("EMP_NAME"));

}

} catch (SQLException e) {

e.printStackTrace();

}

✅ これにより、ResultSet・PreparedStatement・Connection が自動的にクローズされます。

⚙️ open_cursors の推奨設定値

システム規模	推奨値	備考
開発・検証環境	300〜500	検証負荷に応じて柔軟に設定
小〜中規模業務システム	500〜1000	通常アプリでは十分
大規模バッチ・Webサービス	1000〜2000	コネクションプール利用時に余裕をもたせる

🚨 注意点

open_cursors の値を単純に上げるだけでは根本解決になりません。
→ アプリケーションでのクローズ処理修正が最優先。
定期的に v$open_cursor を監視することで、リークを早期発見できます。

✅ まとめ

観点	内容
発生原因	カーソルの未クローズや過剰生成
一時対応	open_cursors の増加
根本対応	コード修正（try-with-resources等）
チェック方法	v$open_cursor / v$sesstat ビュー
再発防止	コーディング規約・静的解析の導入

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も選択肢になります。

Oracle, データベース, トラブル対応, ブログ

Oracle「ORA-06502: PL/SQL 数値または値エラー」エラーが出た時の解決方法

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

Oracle データベースを利用していると、**「ORA-06502: PL/SQL: 数値または値エラー」**というエラーに遭遇することがあります。これは比較的よく見られるエラーの一つで、主に「データ型の不一致」や「文字列長の超過」が原因です。この記事では、このエラーの代表的な原因と解決方法を解説します。

ORA-06502 エラーの意味

エラーメッセージ全文は以下のようになります。

このエラーは、PL/SQL 実行時に「値が期待されるデータ型に収まらない」場合に発生します。例えば以下のケースです。

数値型の変数に、文字列を代入しようとした場合
VARCHAR2 の長さ制限を超える文字列を代入した場合
型変換関数（TO_NUMBER, TO_DATE など）が失敗した場合

よくある原因と解決方法

1. 文字列長の超過

解決方法: 変数の長さを見直す、あるいは SUBSTR を利用して長さを調整する。

2. 数値変換エラー

解決方法: 入力値が数値かどうかを事前にチェックする。正規表現を利用するのも有効です。

3. 不正な日付変換

原因: 存在しない日付を変換しようとした。
解決方法: 入力フォーマットをチェックし、妥当な値のみ渡す。

4. 数値桁数のオーバーフロー

解決方法: NUMBER の定義を見直す、または値を丸める。

トラブルシューティングのポイント

エラー発生時の 変数定義 を確認する
DBMS_OUTPUT.PUT_LINE で 代入しようとしている値 を出力する
データベースの カラム定義と変数定義の不一致 を確認する
外部入力（CSV など）を扱う場合は 入力データの妥当性チェック を行う

まとめ

「ORA-06502」エラーは、ほとんどの場合 データ型の不一致 や 値の範囲超過 が原因です。
再発防止のためには以下が重要です。

変数やカラムの定義を余裕を持たせて設計する
入力値チェックを徹底する
デバッグ時に DBMS_OUTPUT を活用して値を追跡する

これらを意識することで、エラーを効率的に解消できるはずです。

SQL, ブログ

SQL便利技：PIVOTとUNPIVOTで自由自在に表を変換する方法

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

SQLを使ってデータを扱うとき、表の形を「横持ち」や「縦持ち」に変換したい場面は多々あります。
例えば、月ごとの売上を列ごとに並べたい、あるいはアンケート結果を1列にまとめたいなど。

こうした「表の回転」に便利なのが PIVOT と UNPIVOT です。
本記事では、それぞれの使い方と、主要なDBMSごとの違いを整理します。

PIVOTとは？

PIVOTは 縦持ちデータを横持ちに変換する 機能です。
例：月ごとの売上を集計して列化する。

サンプルデータ

商品月売上

A 1月 100

A 2月 150

B 1月 200

B 2月 180

PIVOTのイメージ

UNPIVOTとは？

UNPIVOTは 横持ちデータを縦持ちに変換する 機能です。
例：上記の「商品×月売上表」を再び「商品・月・売上」の縦持ちに戻す。

各DBMSでの書き方比較

1. SQL Server

SQL Serverはネイティブで PIVOT / UNPIVOT をサポート。

2. Oracle

Oracleは PIVOT / UNPIVOT が標準で利用可能。

3. PostgreSQL

PostgreSQLはPIVOT句を持たないため、crosstab関数（tablefunc拡張） を使う。

4. MySQL

MySQLには PIVOT 句はなく、CASE式 + GROUP BY を使う。

DBMS比較表

DBMS PIVOT対応 UNPIVOT対応代替手段

SQL Server ネイティブネイティブそのまま使用可

Oracle ネイティブネイティブそのまま使用可

PostgreSQL なしなし crosstab関数 / UNION ALL

MySQL なしなし CASE式 + GROUP BY / UNION ALL

まとめ

SQL Server / Oracle → PIVOT/UNPIVOTがシンプルに使える。
PostgreSQL / MySQL → 標準ではなく、関数やCASE式で工夫が必要。

「集計を横に展開したい」あるいは「フラットに戻したい」とき、
DBMSに応じた方法を覚えておくと、データ整形がぐっと楽になります。

SQL, ブログ

DENSE_RANKとRANKの違いを使い分けるランキング便利技

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

SQLでデータに順位を付けたいとき、よく使われるのが RANK と DENSE_RANK です。
どちらもウィンドウ関数として利用でき、同点がある場合にどう順位を振るかが異なります。

「売上ランキングを作りたい」「部門ごとのTOP3を出したい」といった実務シーンでは、両者の違いを理解していないと期待通りの結果にならないことがあります。

本記事では、RANKとDENSE_RANKの基本的な違い を解説したうえで、実務での使い分け方、さらに DBMSごとのサポート状況 までわかりやすく紹介します。

RANKとは？

RANK は、同点がある場合に同じ順位を付けますが、その分次の順位が飛びます。

例：テストの点数ランキング

👉 2位が2人いるため、次の順位は「4位」となります。

DENSE_RANKとは？

DENSE_RANK は、同点の場合も同じ順位を付けますが、次の順位は飛ばさずに連続します。

👉 2位が2人いても、次の順位は「3位」となります。

実務での便利な活用例

1. 売上ランキングを作る

売上データから各商品の順位を求めたいときは DENSE_RANK が便利です。

2. 部門別ランキングを作る

「部門ごとにランキングを出したい」場合は、PARTITION BY を組み合わせます。

3. TOP Nの商品を抽出する

「売上TOP3の商品を取得したい」といった場合は注意が必要です。

DENSE_RANK なら「必ず3位まで」に限定できるため安全です。

DBMSごとの違い

Oracle Database

RANK / DENSE_RANK ともに早期からサポート
標準SQLに準拠し、安定して利用可能

PostgreSQL

バージョン8.4以降でサポート
標準SQL準拠のため、OracleやSQL Serverとほぼ同じ書き方で利用できる

MySQL

MySQL 8.0 以降で利用可能
それ以前（5.x系など）では未対応で、ユーザー変数を使った代替実装が必要

SQL Server (Microsoft)

2005以降でサポート
標準SQLと同じ感覚で利用可能

👉 まとめると：

Oracle / PostgreSQL / SQL Server → そのまま使える
MySQL 8.0以降 → 標準対応
MySQL 5.x以前 → 対応なし（代替実装が必要）

まとめ

RANK → 同順位があると次の順位が飛ぶ（例：1,2,2,4）
DENSE_RANK → 順位が連続（例：1,2,2,3）
実務での使い分け：
- 売上ランキング → DENSE_RANK
- 部門別の表彰や順位 → RANK
- TOP N抽出 → DENSE_RANK が安全
DBMSによってサポート状況が異なるため、特にMySQLはバージョンを確認することが重要

SQLでのランキング処理はシーンによって適切に関数を選ぶのがコツです。

名前	点数	RANK
Aさん	100	1
Bさん	95	2
Cさん	95	2
Dさん	90	4

名前	点数	DENSE_RANK
Aさん	100	1
Bさん	95	2
Cさん	95	2
Dさん	90	3

✅ EXPLAIN PLANとは？

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

✅ Oracle実行計画の基本構造

✅ よく出るOperationと解釈ポイント

✅ ボトルネックの探し方

① TABLE ACCESS FULL に注意

② JOIN方式を確認

③ コスト（COST）とROWSを確認

④ SORTが多い場合

✅ 実例：遅いSQLの典型パターン

問題点

改善例

✅ チューニングの基本手順まとめ

✅ まとめ

関連記事

1. インデックスとは？

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

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

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

🧩 B-treeインデックス

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

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

✅ 有効なケース

🚫 不向きなケース

4. 実行計画で確認する

結果例（MySQLの場合）

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

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

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

🌟 LIKE検索の最適化

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

7. 実践チューニング例

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

🩹 改善策

✅ 実行計画の変化

まとめ

🚀 結論

関連記事

MERGE文とは？

MERGE文の基本構文（Oracleの場合）

実用例①：顧客マスタの更新 or 追加

処理の流れ（フロー図で理解）

応用例②：条件によってDELETEも行う（Oracle/SQL Server対応）

MERGE文のメリット

注意点

他DBでの補足

まとめ

関連記事

1. インデックスヒントとは？

2. 一般的な書き方

Oracleの場合

MySQLの場合

SQL Serverの場合

3. MySQLにおけるINDEX HINTの種類

4. 実行計画を確認する

MySQL

Oracle

5. 使用上の注意点

6. 実用例：複合インデックスを明示的に使用

7. まとめ

関連記事

🧠 ウィンドウ関数とは？

🔸 基本構文

🏅 ランキングを求める

📘 サンプルテーブル：sales

📗 SQL例

📊 実行結果

🔢 累計を求める

📗 SQL例

📊 結果

🧮 他の代表的なウィンドウ関数

💡 応用例：前回比を計算する

🧭 DBMS別のウィンドウ関数対応表

🔍 まとめ

関連記事

🔍 エラー概要

🧠 原因と仕組み

🧩 よくある原因パターン

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

サンプルデータ

商品月売上

A 1月 100

A 2月 150

B 1月 200

B 2月 180

商品 1月売上 2月売上

A 100 150

B 200 180

DBMS PIVOT対応 UNPIVOT対応代替手段

SQL Server ネイティブネイティブそのまま使用可

Oracle ネイティブネイティブそのまま使用可

PostgreSQL なしなし crosstab関数 / UNION ALL

MySQL なしなし CASE式 + GROUP BY / UNION ALL

　関連記事

　関連記事