「MySQL」タグアーカイブ

インデックスの仕組みを理解して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：結合順序を意識してクエリ最適化を行う方法

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

SQLでパフォーマンスを高めるうえで「結合順序（Join Order）」は非常に重要な要素です。
同じ結果を返すクエリでも、テーブルの結合順序によって処理時間が大きく変わることがあります。

この記事では、結合順序を意識したSQLの最適化方法を、実例とともにわかりやすく解説します。

🔍 なぜ結合順序が重要なのか

SQLの実行順序は見た目の記述順と異なり、最適化エンジンが最も効率的な順序を自動で選択します。
しかし、結合対象のテーブルサイズや結合条件によっては、自動最適化が必ずしも最適とは限りません。

特に以下のようなケースでは、結合順序が大きく影響します。

状況	パフォーマンスへの影響
大規模テーブルを先に結合している	不要なデータを大量に読み込む可能性
絞り込み条件のないテーブルを先に結合	フルスキャンのリスク
結合条件にインデックスが効いていない	結合ごとに多重ループが発生

🧩 結合順序の基本原則

一般的に、以下の順序を意識すると効率的です。

データ件数の少ないテーブルから結合する
WHERE句で絞り込めるテーブルを先に結合する
インデックスの効くテーブルを優先する
結合条件（ON句）は明確に指定する

例1：非効率な結合順序

この場合、employeesが数十万件あり、departmentsが数百件なら、
大テーブル→小テーブルの順になり、効率が悪くなります。

✅ 効率的な結合順序の書き方（例）

例2：効率的な書き方

先にdepartments（小テーブル）を起点にしてemployeesを結合すると、
条件に合う部署のみを先に絞り込めるため、結合コストを大幅に削減できます。

🧮 実行計画で結合順序を確認する

実際に最適化できているかを確認するには、**実行計画（EXPLAIN）**を確認します。

チェックポイント

項目	確認ポイント
type	ALL（全件走査）よりrefやindexが望ましい
rows	結合ごとの推定行数を確認し、不要な膨張がないか
Extra	Using where, "Using index" など最適化の有無を確認

⚙️ 結合順序の強制指定（ヒント句）

DBによっては**ヒント句（Hint）**を利用して結合順序を指定することも可能です。

Oracle の例

MySQL の例

STRAIGHT_JOINを使うと、記述順通りの結合順序で実行されます。

⚡ 実践Tipsまとめ

最適化ポイント	内容
小さいテーブルを先に結合	大量データの無駄読みを防ぐ
WHERE句の絞り込みを早期適用	不要データを結合前に排除
実行計画を確認	JOIN順序やインデックス利用を把握
ヒント句を活用	自動最適化がうまく働かない場合に使用

💡 まとめ

SQLの結合順序は、パフォーマンスチューニングの重要ポイントです。
自動最適化に頼るだけでなく、結合対象のデータ規模や条件を意識して設計することが大切です。
実行計画やヒント句を活用し、最適なクエリ構造を追求しましょう。

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

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

商品	月	売上
A	1月	100
A	2月	150
B	1月	200
B	2月	180

PIVOTのイメージ

商品	1月売上	2月売上
A	100	150
B	200	180

UNPIVOTとは？

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

各DBMSでの書き方比較

1. SQL Server

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

-- PIVOT
SELECT 商品, [1月] AS 売上1月, [2月] AS 売上2月
FROM (
  SELECT 商品, 月, 売上
  FROM Sales
) AS src
PIVOT (
  SUM(売上) FOR 月 IN ([1月], [2月])
) AS pvt;

-- PIVOT

SELECT 商品, [1月] AS 売上1月, [2月] AS 売上2月

FROM (

SELECT 商品, 月, 売上

FROM Sales

) AS src

PIVOT (

SUM(売上) FOR 月 IN ([1月], [2月])

) AS pvt;

-- UNPIVOT
SELECT 商品, 月, 売上
FROM SalesPivot
UNPIVOT (
  売上 FOR 月 IN ([1月売上], [2月売上])
) AS unpvt;

-- UNPIVOT

SELECT 商品, 月, 売上

FROM SalesPivot

UNPIVOT (

売上 FOR 月 IN ([1月売上], [2月売上])

) AS unpvt;

2. Oracle

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

3. PostgreSQL

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

4. MySQL

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

-- PIVOT
SELECT
  商品,
  SUM(CASE WHEN 月 = '1月' THEN 売上 END) AS 売上1月,
  SUM(CASE WHEN 月 = '2月' THEN 売上 END) AS 売上2月
FROM Sales
GROUP BY 商品;

-- PIVOT

SELECT

商品,

SUM(CASE WHEN 月 = '1月' THEN 売上 END) AS 売上1月,

SUM(CASE WHEN 月 = '2月' THEN 売上 END) AS 売上2月

FROM Sales

GROUP BY 商品;

UNPIVOTも標準構文がないので、PostgreSQL同様 UNION ALL を用いる。

-- UNPIVOT (UNION ALL)
SELECT 商品, '1月' AS 月, 売上1月 AS 売上 FROM sales_pivot
UNION ALL
SELECT 商品, '2月', 売上2月 FROM sales_pivot;

-- UNPIVOT (UNION ALL)

SELECT 商品, '1月' AS 月, 売上1月 AS 売上 FROM sales_pivot

UNION ALL

SELECT 商品, '2月', 売上2月 FROM sales_pivot;

DBMS比較表

DBMS PIVOT対応 UNPIVOT対応代替手段

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

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

PostgreSQL なしなし crosstab関数 / UNION ALL

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

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に応じた方法を覚えておくと、データ整形がぐっと楽になります。

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

MySQLで「Too many connections」エラーが出たときの原因と対処法

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

MySQLを運用していると、ある日突然アプリケーション側から「Too many connections」というエラーが返され、データベースに接続できなくなることがあります。これは利用者にとってはサイトやサービスが「停止状態」と同じであり、早急な対応が必要です。本記事では、このエラーの原因と具体的な対処方法を整理します。

「Too many connections」エラーとは？

MySQLには同時に接続できるクライアント数を制御する仕組みがあります。
max_connections というパラメータで上限値が決められており、この数を超える新規接続要求があった場合に 「Too many connections」 エラーが発生します。

初期値：151（バージョンによって異なる）
上限：OSやハードウェアのリソースに依存

つまり、データベースが過負荷状態になったサインと捉えることができます。

主な原因

1. 接続数の急増

一時的にアクセスが集中し、アプリケーションからの同時接続数が急増することで上限を超えてしまいます。

2. 接続のクローズ漏れ

アプリケーション側で 接続プールの管理不備 や close処理の抜け があると、不要な接続が残り続けます。

3. 長時間実行されるクエリ

重いSQLが大量に実行されると、処理待ちの接続が積み重なり、結果的に接続枠を圧迫します。

4. 不適切な設定

wait_timeout や interactive_timeout の値が長すぎると、アイドル状態の接続が切断されずに残ってしまうことがあります。

対処法

1. 一時的な応急処置

まずはサービス復旧を優先します。
MySQLに管理者で接続できる場合、現在の接続状況を確認します。

どうしても管理者で接続できない場合は、MySQLサービスの再起動が必要になる場合もあります。
（※ただし根本解決にはならず、緊急回避策に過ぎません。）

2. 根本的な解決策

(1) max_connections を増やす

一時的なアクセス増に備えるために上限値を上げます。

(2) 接続プールの導入・見直し

アプリケーションで コネクションプーリング を利用し、使い終わった接続は必ず解放するようにします。
JavaならHikariCP、PHPならPDOやmysqliの接続プールを利用するのが一般的です。

(3) クエリのチューニング

インデックスを適切に設定する
不要なJOINやサブクエリを減らす
キャッシュを導入する

これにより接続が長時間占有されることを防ぎます。

(4) timeout の調整

不要な接続が残り続けないように、wait_timeout の値を短めに設定します。

再発防止のために

アクセスのピーク時を想定して性能テストを行う
アプリケーション側で接続管理を徹底する
監視ツール（例：Zabbix, Prometheus, CloudWatchなど）で接続数を常時モニタリングする

これらを実施することで「Too many connections」エラーを未然に防ぐことができます。

まとめ

「Too many connections」エラーは単なる設定値不足ではなく、接続管理やクエリ設計の問題 が隠れていることが多いです。

一時的には接続数の上限を増やす
長期的にはアプリケーション側の接続管理やSQLチューニングを見直す

これらをバランスよく行うことで、安定したMySQL運用が可能になります。

SQL, ブログ

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

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

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

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

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

RANKとは？

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

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

SELECT
  name,
  score,
  RANK() OVER (ORDER BY score DESC) AS rank
FROM
  students;

SELECT

name,

score,

RANK() OVER (ORDER BY score DESC) AS rank

FROM

students;

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

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

DENSE_RANKとは？

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

SELECT
  name,
  score,
  DENSE_RANK() OVER (ORDER BY score DESC) AS dense_rank
FROM
  students;

SELECT

name,

score,

DENSE_RANK() OVER (ORDER BY score DESC) AS dense_rank

FROM

students;

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

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

実務での便利な活用例

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

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

SELECT
  product_id,
  SUM(sales_amount) AS total_sales,
  DENSE_RANK() OVER (
    ORDER BY SUM(sales_amount) DESC
  ) AS sales_rank
FROM
  sales
GROUP BY
  product_id;

SELECT

product_id,

SUM(sales_amount) AS total_sales,

DENSE_RANK() OVER (

ORDER BY SUM(sales_amount) DESC

) AS sales_rank

FROM

sales

GROUP BY

product_id;

👉 同順位の商品があっても「順位が飛ばない」ので、一覧が見やすくなります。

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

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

SELECT
  department,
  employee_name,
  sales_amount,
  RANK() OVER (
    PARTITION BY department
    ORDER BY sales_amount DESC
  ) AS rank_in_dept
FROM
  employee_sales;

SELECT

department,

employee_name,

sales_amount,

RANK() OVER (

PARTITION BY department

ORDER BY sales_amount DESC

) AS rank_in_dept

FROM

employee_sales;

👉 部門ごとに順位がリセットされ、それぞれの中でランキングが作成されます。

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

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

WITH ranked AS (
  SELECT
    product_id,
    SUM(sales_amount) AS total_sales,
    RANK() OVER (
      ORDER BY SUM(sales_amount) DESC
    ) AS rank
  FROM
    sales
  GROUP BY
    product_id
)
SELECT
  *
FROM
  ranked
WHERE
  rank <= 3;  -- ここを任意のNに変更

WITH ranked AS (

SELECT

product_id,

SUM(sales_amount) AS total_sales,

RANK() OVER (

ORDER BY SUM(sales_amount) DESC

) AS rank

FROM

sales

GROUP BY

product_id

)

SELECT

FROM

ranked

WHERE

rank <= 3; -- ここを任意のNに変更

👉 RANK を使うと、3位が同点の場合に4件以上取得されることがあります。

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でのランキング処理はシーンによって適切に関数を選ぶのがコツです。

SQL, ブログ

正規表現(REGEXP)でSQLがもっと楽になる！実践パターン集

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

SQLの検索でよく使われる LIKE 句は便利ですが、複雑な条件指定には限界があります。
そこで強力な武器となるのが 正規表現（REGEXP）。
この記事では、基本的な使い方からよく使うパターン、さらに「SQLで利用できる正規表現の一覧」をまとめました。

1. REGEXPの基本構文

SQLでは REGEXP を用いて文字列検索を行います。

2. 使用できる正規表現の一覧（MySQL準拠）

SQLで使える代表的な正規表現を整理しました。
※DBエンジンにより若干差異あり（MySQL、PostgreSQL、Oracleなど）

パターン	意味	使用例
^	行頭にマッチ	^A → Aで始まる
$	行末にマッチ	Z$ → Zで終わる
.	任意の1文字	c.t → cat, cot, cut
[...]	文字クラス	[0-9] → 数字1文字
[^...]	否定の文字クラス	[^0-9] → 数字以外
*	0回以上の繰り返し	a* → \\"	a	aaa"
+	1回以上の繰り返し	a+ → a, aa
?	0回または1回	colou?r → color, colour
{n}	n回の繰り返し	[0-9]{4} → 4桁の数字
{n,}	n回以上の繰り返し	[0-9]{2,} → 2桁以上の数字
{n,m}	n〜m回の繰り返し	[A-Z]{2,5} → 2〜5文字の大文字
\|	OR条件	cat\|dog → cat または dog
()	グループ化	(abc)+ → abc, abcabc
[:digit:]	数字	[[:digit:]] → 0〜9
[:alpha:]	英字	[[:alpha:]] → A〜Z, a〜z
[:alnum:]	英数字	[[:alnum:]] → 英数字
[:space:]	空白文字	[[:space:]] → 空白, 改行, タブ
[:upper:]	大文字	[[:upper:]] → 大文字
[:lower:]	小文字	[[:lower:]] → 小文字

3. よく使う実践パターン

(1) 先頭・末尾の一致

(2) 日付フォーマット判定

(3) メールアドレス判定

(4) 商品コードの書式検証

(5) 拡張子フィルタ

4. REGEXPのメリットと注意点

メリット

複雑な条件をシンプルに表現できる
SQLの可読性が向上
データ品質チェックに有効

注意点

DBごとに正規表現エンジンが異なる（MySQL、PostgreSQL、Oracleで互換性に注意）
パフォーマンス低下の可能性があるため、大量データ処理時はインデックス設計と併用が望ましい

SQLでのREGEXPサポート比較（DBMSごと）

DBMS	REGEXPサポート	演算子/関数例	備考
MySQL	◎	REGEXP, REGEXP_REPLACE	8.0以降はICUベース
PostgreSQL	◎	~, ~, !~, !~	高度な正規表現OK
Oracle	◎	REGEXP_LIKE, REGEXP_SUBSTR	POSIX互換
SQL Server	△	（CLR関数経由）	ネイティブ未対応
SQLite	△	REGEXP（要自作関数）	デフォルト非対応
BigQuery	◎	REGEXP_CONTAINS など	クラウドSQL
Snowflake	◎	RLIKE, REGEXP	ほぼMySQL互換

まとめ

REGEXPを使えばSQLの検索が格段に柔軟になります。
一覧表を参考に、ログ解析やメール判定、コード検証などに応用してみてください。

「LIKEでは表現できない…」と思ったら、REGEXPの出番です！

1. インデックスとは？

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

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

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

🧩 B-treeインデックス

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

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

✅ 有効なケース

🚫 不向きなケース

4. 実行計画で確認する

結果例（MySQLの場合）

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

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

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

🌟 LIKE検索の最適化

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

7. 実践チューニング例

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

🩹 改善策

✅ 実行計画の変化

まとめ

🚀 結論

関連記事

🔍 なぜ結合順序が重要なのか

🧩 結合順序の基本原則

例1：非効率な結合順序

✅ 効率的な結合順序の書き方（例）

例2：効率的な書き方

🧮 実行計画で結合順序を確認する

チェックポイント

⚙️ 結合順序の強制指定（ヒント句）

Oracle の例

MySQL の例

⚡ 実践Tipsまとめ

💡 まとめ

関連記事

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

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

3. 実行結果の比較例

テーブルA

テーブルB

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

5. どちらを使うべきか

6. まとめ

関連記事

PIVOTとは？

サンプルデータ 商品月売上 A1月100 A2月150 B1月200 B2月180

PIVOTのイメージ

商品1月売上2月売上 A100150 B200180

UNPIVOTとは？

各DBMSでの書き方比較

1. SQL Server

2. Oracle

3. PostgreSQL

4. MySQL

DBMS比較表

DBMSPIVOT対応UNPIVOT対応代替手段 SQL Serverネイティブネイティブそのまま使用可 Oracleネイティブネイティブそのまま使用可 PostgreSQLなしなしcrosstab関数 / UNION ALL MySQLなしなしCASE式 + GROUP BY / UNION ALL

まとめ

関連記事

「Too many connections」エラーとは？

主な原因

1. 接続数の急増

2. 接続のクローズ漏れ

3. 長時間実行されるクエリ

4. 不適切な設定

対処法

1. 一時的な応急処置

2. 根本的な解決策

(1) max_connections を増やす

(2) 接続プールの導入・見直し

(3) クエリのチューニング

(4) timeout の調整

再発防止のために

まとめ

関連記事

RANKとは？

DENSE_RANKとは？

実務での便利な活用例

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

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

　関連記事

　関連記事

　関連記事

サンプルデータ

商品月売上

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

　関連記事

　関連記事

　関連記事

　関連記事