SQLを実行したときに、データ量が少ないうちは問題なくても、データが増えるにつれて処理時間が長くなることがあります。
このような場合は、SQL文を見直す「SQLチューニング」を行うことで、処理速度を改善できる場合があります。
本記事では、SQL初心者向けに、代表的なSQLチューニングの方法を紹介します。
1. 必要なデータだけ取得する
まず確認したいのが、SELECT *を使用しちゃっていないかです。
チューニング前
SELECT *
FROM employees;
employeesテーブルに大量のデータがある場合、必要のない列まで取得することになります。
チューニング後
SELECT employee_id, employee_name, department_id
FROM employees;
必要な列だけを指定することで、取得するデータ量を減らせます。
特に大量のデータを扱う場合は、SELECT *を避け、必要な列を明示することが重要です。
2. WHERE句で検索対象を絞り込む
大量のデータを取得してから処理するのではなく、できるだけSQLの段階で対象を絞り込みます。
例
SELECT employee_id, employee_name
FROM employees
WHERE department_id = 10;
例えば10万件のデータから100件だけ必要なのであれば、最初から100件に絞り込むことで、処理するデータ量を減らせます。
3. インデックスを利用する
検索処理が遅い場合、インデックスが有効か確認します。
例えば、以下のSQLを頻繁に実行するとします。
SELECT *
FROM employees
WHERE employee_id = 1001;
employee_idに適切なインデックスが設定されていれば、テーブル全体を検索するより高速にデータを検索できる場合があります。
ただし、インデックスを作れば必ず速くなるわけではありません。
インデックスには、
- INSERT時の負荷が増える
- UPDATEやDELETE時の負荷が増える
- ディスク容量を使用する
といったデメリットもあります。
そのため、検索条件やデータ量を考慮して設定する必要があります。
4. WHERE句で関数を使用しすぎない
検索対象の列に関数を使用すると、インデックスが効きにくくなる場合があります。
例えば、日付を検索する場合です。
避けたい例
SELECT *
FROM orders
WHERE YEAR(order_date) = 2026;
order_dateに対してYEAR()を実行してから比較しています。
改善例
SELECT *
FROM orders
WHERE order_date >= '2026-01-01'
AND order_date < '2027-01-01';
このように検索条件を書き換えることで、インデックスを利用できる可能性があります。
※インデックスの利用可否は、使用するデータベース製品や実行計画によって異なります。
5. LIKE検索に注意する
文字列検索でLIKEを使用する場合も注意が必要です。
インデックスを利用しにくい例
SELECT *
FROM customers
WHERE customer_name LIKE '%山田%';
先頭に%があるため、インデックスを利用できない場合があります。
一方、前方一致であれば、
SELECT *
FROM customers
WHERE customer_name LIKE '山田%';
インデックスを利用できる可能性があります。
大量のデータを対象にした部分一致検索では、検索方法そのものを見直す必要がある場合があります。
6. 不要なJOINを減らす
複数のテーブルを結合するときは、本当に必要なテーブルだけをJOINします。
例
SELECT e.employee_name, d.department_name
FROM employees e
INNER JOIN departments d
ON e.department_id = d.department_id
WHERE e.department_id = 10;
JOINするテーブルが増えるほど、処理内容が複雑になります。
不要なJOINがないか、JOIN条件に適切なインデックスがあるかを確認することが重要です。
7. サブクエリを見直す
サブクエリが複雑になっている場合は、JOINなど別の書き方に変更することで改善できる場合があります。
例えば、
SELECT *
FROM employees
WHERE department_id IN (
SELECT department_id
FROM departments
WHERE location = 'Tokyo'
);
というSQLがある場合、処理内容によってはJOINを使用して、
SELECT e.*
FROM employees e
INNER JOIN departments d
ON e.department_id = d.department_id
WHERE d.location = 'Tokyo';
と書き換えられます。
ただし、「サブクエリよりJOINのほうが必ず速い」というわけではありません。
実際の速度は、データ量やインデックス、データベース製品などによって変わります。
8. ORDER BYの使用に注意する
ORDER BYを使用すると、データの並び替え処理が発生します。
SELECT *
FROM employees
ORDER BY employee_name;
大量のデータを並び替える場合、処理に時間がかかることがあります。
必要がない場合はORDER BYを使用しないこともチューニングの一つです。
また、必要なデータだけ取得してから並び替える方法も有効です。
SELECT employee_id, employee_name
FROM employees
WHERE department_id = 10
ORDER BY employee_name;
9. LIMITやTOPなどで取得件数を制限する
大量のデータが存在していても、画面に表示するのが数十件だけであれば、すべてのデータを取得する必要はありません。
データベース製品に応じて、取得件数を制限できます。
例えば、
SELECT employee_id, employee_name
FROM employees
ORDER BY employee_id
LIMIT 50;
のようにすることで、取得するデータ量を抑えられます。
10. 実行計画を確認する
SQLチューニングで特に重要なのが「実行計画」です。
実行計画を見ることで、データベースがSQLをどのように実行しているのかを確認できます。
例えば、
- テーブル全体を検索していないか
- インデックスを使用しているか
- 大量のデータをJOINしていないか
- ソート処理に時間がかかっていないか
などを確認できます。
SQLの見た目だけでは、どの処理に時間がかかっているのか分からない場合があります。
そのため、SQLチューニングでは実行計画を確認することが重要です。
SQLチューニングのポイントまとめ
SQLの速度を改善するときは、次のポイントを確認します。
| チェック項目 | ポイント |
|---|---|
| SELECT | 必要な列だけ取得する |
| WHERE | 早い段階でデータを絞り込む |
| インデックス | 検索条件に適切なインデックスがあるか確認する |
| 関数 | WHERE句で列に関数を使用しすぎない |
| LIKE | %の位置に注意する |
| JOIN | 不要なJOINを減らす |
| サブクエリ | JOINなど別の方法も検討する |
| ORDER BY | 不要な並び替えを行わない |
| 件数 | 必要な件数だけ取得する |
| 実行計画 | 実際のSQLの処理内容を確認する |
まとめ
SQLのチューニングでは、単純にSQLを書き換えるだけではなく、「どの処理に時間がかかっているのか」を確認することが重要です。
特に、
- 必要なデータだけ取得する
- WHERE句でデータを絞り込む
- インデックスを適切に利用する
- 不要なJOINやORDER BYを減らす
- 実行計画を確認する
といったポイントから確認すると、SQLチューニングの基本を理解しやすくなります。
SQLが遅い場合は、まず実行計画や処理時間を確認し、変更前と変更後の速度を比較しながら改善していくことが大切です。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
