MySQLのFIND_IN_SET関数を完全解説｜使い方・注意点・代替手段まで丁寧に解説

By 佐川 直弘 | Naohiro Sagawa (運営者)

※記事内に広告を含みます。Amazonアソシエイトとして適格販売により収入を得ています。　

1. はじめに：FIND_IN_SETが必要になる「よくあるケース」

MySQLでデータを扱っていると、「1つのカラムに複数の値がカンマで区切られて保存されている」ケースに出くわすことがあります。たとえば、ユーザーが選択したタグやカテゴリ情報、設定フラグなどが、php,python,sqlのように1つの文字列として格納されている状況です。

このような構造は本来、データベースの正規化の観点では推奨されません。しかし、既存システムの設計や柔軟性のあるデータ入力を優先する場面では、現実的にこのような形式を使わざるを得ないこともあります。

タグ検索に困ったときの救世主

たとえば、あるユーザーが「python」というタグを持っているかどうかを調べたいとします。通常の=演算子やLIKE演算子では、部分一致や前後の文字とのマッチング精度に限界があり、誤った結果を返すことがあります。

このようなときに役立つのが、FIND_IN_SET()関数です。

FIND_IN_SET()は、カンマ区切りの文字列の中から、特定の文字列が何番目に存在するかを判定するMySQL関数です。存在すればそのインデックス（1始まり）を返し、存在しなければ0を返します。この機能を使えば、タグやカテゴリ、設定値などが含まれているかどうかを正確に、かつ柔軟に判定することが可能になります。

よくある使用シーン

FIND_IN_SETが活躍する典型的なケースは次のようなものです。

• カンマ区切りで保存された「タグ」や「カテゴリ」の中から特定の値を抽出したいとき
• 管理画面などでCSV形式で入力された値を検索条件として利用したいとき
• WordPressなどのCMSで、メタ情報に対する柔軟な絞り込みを行いたいとき
• 複数選択項目が1カラムにまとめられている既存テーブルに手を加えずに処理したいとき

こうしたニーズがある一方で、FIND_IN_SETは使い方を誤るとパフォーマンス低下や誤検出の原因になることもあります。そこでこの記事では、FIND_IN_SETの基本的な構文から応用例、注意点や代替手段までを、実例を交えながらわかりやすく解説していきます。

2. FIND_IN_SET関数とは？【基本構文と戻り値】

MySQLのFIND_IN_SET()関数は、カンマで区切られた文字列の中から、指定した値が何番目にあるかを調べるための関数です。データベース内の値が複数まとめて1つのフィールドに保存されているような場合に、非常に便利です。

この関数は、MySQL固有のものであり、他のデータベース（たとえばPostgreSQLやSQLite）には標準では存在しないため、MySQL環境に特化した機能といえます。

基本構文

FIND_IN_SET(検索値, カンマ区切りの文字列)

• 検索値：探したい文字列
• カンマ区切りの文字列：検索対象となるカンマ区切りのリスト

使用例

たとえば、次のようなSQLを考えてみましょう。

SELECT FIND_IN_SET('python', 'php,python,sql');

この場合、'python'は2番目にあるため、戻り値として2が返されます。

逆に、リストの中に指定した値が存在しない場合は、次のように0が返されます。

SELECT FIND_IN_SET('ruby', 'php,python,sql');
-- 結果：0

さらに、どちらかの引数がNULLである場合は、戻り値もNULLになります。

SELECT FIND_IN_SET(NULL, 'php,python,sql');
-- 結果：NULL

戻り値の仕様

このように、戻り値をうまく利用することで、検索だけでなく、「含まれている順序を確認したい」といった場面にも応用できます。

注意点：0は「存在しない」ことを意味する

戻り値が0のときは、「リスト内に存在しない」ことを示します。MySQLでは0はFALSEとして扱われるため、WHERE句で利用する際にそのまま使うと誤動作の原因になることがあります。

次章では、実際のテーブルデータに対してどのようにFIND_IN_SETを使って検索するか、基本的なクエリ例を紹介していきます。

3. 実践例①：基本的な使い方【シンプルなSELECT文】

FIND_IN_SET()関数は、その名の通り「セットの中から見つける」ための関数ですが、実際にテーブルデータを対象に使用する場面では、どのように書けばよいのでしょうか？
ここでは、もっともシンプルなSELECT文を使った使用例を紹介します。

例題テーブルの準備

まず、以下のようなテーブルを想定します。

テーブル名：user_tags

このtagsカラムは、ユーザーが登録したスキルタグをカンマ区切りで保存しているものです。

例：”python”を含むユーザーを検索する

この中から「python」というタグを持っているユーザーだけを抽出したい場合、次のようなSQLを書きます。

SELECT * FROM user_tags
WHERE FIND_IN_SET('python', tags);

実行結果：

このように、tagsカラムの中で「python」が含まれているレコードだけが返されました。

文字列の正確な一致がポイント

FIND_IN_SET()は、文字列の完全一致によってマッチングを行います。そのため、「py」や「pyth」などの部分文字列ではマッチしません。部分一致が必要な場合はLIKE演算子を使いますが、LIKE '%python%'のような書き方はphp,python,sqlの中のphpまで誤ってマッチしてしまうリスクがあるため、カンマ区切りのリストにはFIND_IN_SETの方が適しています。

SQLに変数を使った検索例

動的に検索値を変えたい場合、変数を用いることで柔軟に検索できます。

SET @skill = 'python';

SELECT * FROM user_tags
WHERE FIND_IN_SET(@skill, tags);

アプリケーションやストアドプロシージャと連携する場面でも、この書き方が有効です。

4. 実践例②：動的な検索に対応（変数やフォーム連携）

実際のWebアプリケーションや業務システムでは、検索条件をSQLに動的に組み込む場面がよくあります。
たとえば、ユーザーがフォームで選択した値や、システム内で自動生成される値を使って、FIND_IN_SET()で検索したいケースです。

ここでは、変数やバックエンド連携を想定した、実践的な使い方を紹介します。

SQL内の変数を使った動的検索

MySQLのセッション変数（@変数名）を使えば、検索値をコードの冒頭で定義して、複数のクエリで再利用できます。

-- 検索したいタグを変数に格納
SET @target_tag = 'python';

-- FIND_IN_SETで動的検索
SELECT * FROM user_tags
WHERE FIND_IN_SET(@target_tag, tags);

このようにすることで、検索値を簡単に差し替え可能になり、ストアドプロシージャやバッチ処理などでも活用できます。

アプリケーションとの連携：PHPの場合

たとえばPHPを使って、Webフォームの入力をもとにSQLを発行する場合、以下のようなコードになります。

<?php
$tag = $_GET['tag']; // 例: フォーム入力 "python"

// SQL生成（プリペアドステートメントが望ましい）
$sql = "SELECT * FROM user_tags WHERE FIND_IN_SET(?, tags)";

$stmt = $pdo->prepare($sql);
$stmt->execute([$tag]);
$results = $stmt->fetchAll();
?>

このように、プリペアドステートメントと組み合わせれば、SQLインジェクション対策も万全です。

WordPressでの応用：カスタムフィールドのタグ検索

WordPressでは、meta_queryを使ってカスタムフィールドを検索できますが、FIND_IN_SETを組み込みたい場合は、以下のように直接SQLを使う必要があります。

例：カスタムフィールド _user_tags に "php,python,sql" が保存されているとき

global $wpdb;
$tag = 'python';

$sql = $wpdb->prepare(
  "SELECT * FROM {$wpdb->prefix}postmeta WHERE meta_key = %s AND FIND_IN_SET(%s, meta_value)",
  '_user_tags', $tag
);
$results = $wpdb->get_results($sql);

この方法を使えば、WordPressの標準機能では対応しきれない柔軟な検索が可能になります。

注意：空白や全角カンマに要注意

FIND_IN_SETを使う場合、検索対象のカンマ区切り文字列に余計な空白や全角文字が含まれていると一致しません。
そのため、データ登録時や検索前に、次のような前処理を行うことが推奨されます。

• TRIM()関数で空白を除去
• カンマの形式を正規化（全角→半角）
• アプリケーション側で入力チェック

5. FIND_IN_SETの応用技【GROUP_CONCAT・サブクエリ・JOIN】

FIND_IN_SET関数は、基本的な単体検索だけでなく、他のSQL関数やサブクエリと組み合わせることで、より柔軟で複雑な検索処理にも対応できます。この章では、代表的な3つの応用パターンを紹介します。

GROUP_CONCATとの組み合わせ

まずは、複数行の値を1つのカンマ区切り文字列として扱えるGROUP_CONCAT()との連携です。たとえば、あるテーブルから対象となるタグのリストを作り、それを別のテーブルの検索条件として使う、というような場面で有効です。

例：user_tagsテーブルのtagsカラムの値と、master_tagsテーブルのタグ一覧を突き合わせる

SELECT *
FROM user_tags
WHERE FIND_IN_SET('python', (
  SELECT GROUP_CONCAT(tag_name)
  FROM master_tags
));

このクエリでは、master_tagsに存在するタグ一覧を1つのカンマ区切り文字列に変換し、それに対してFIND_IN_SET()でマッチングを行っています。

注意点としては、GROUP_CONCATで生成される文字列の長さには制限（デフォルトは1024文字）がありますので、対象データが多い場合はgroup_concat_max_lenの設定を確認してください。

サブクエリで動的に値を取得して検索

次に、検索対象の値をサブクエリで動的に取得し、それをFIND_IN_SETに渡す方法です。

例：最新の設定値を持つ管理テーブルから検索条件を取得し、それに基づいてデータを絞り込む

SELECT *
FROM user_tags
WHERE FIND_IN_SET(
  'python',
  (SELECT setting_value FROM search_conditions WHERE id = 1)
);

この例では、検索条件を管理テーブルに格納しておき、システム設定を変更するだけで検索内容を切り替えられるようにしています。
柔軟性が高いため、カスタマイズ可能な管理画面やダッシュボード系アプリケーションで便利です。

JOINとの比較：正規化された構造ではJOINが優位

FIND_IN_SETは便利な関数ですが、本来データベース設計が正規化されている場合は、JOINを使った検索の方が効率的かつ安全です。

たとえば、以下のように中間テーブルを使った多対多の関係であれば、FIND_IN_SETを使わずともシンプルにJOINで実現できます。

構成例：

• usersテーブル
• tagsテーブル
• user_tag_relationテーブル（user_idとtag_idを持つ中間テーブル）

SELECT users.*
FROM users
JOIN user_tag_relation ON users.id = user_tag_relation.user_id
JOIN tags ON user_tag_relation.tag_id = tags.id
WHERE tags.name = 'python';

このような設計にすることで、検索パフォーマンスも向上し、将来的なデータ拡張にも対応しやすくなります。

どの手法を選ぶべきか？

このように、FIND_IN_SET()は他のSQL機能と組み合わせることで、検索条件の柔軟性を大幅に高めることができます。ただし、使用する場面やデータ構造によっては、JOINや別の手法の方が適している場合もあるため、設計と目的に応じて使い分けることが重要です。

6. FIND_IN_SETの落とし穴と注意点【性能・設計面】

FIND_IN_SET関数は、カンマ区切りの文字列に対して柔軟な検索を可能にする便利な関数ですが、安易な多用は避けるべきです。
ここでは、実際の開発現場でもよく問題になるパフォーマンス面やデータベース設計上のリスクについて解説します。

インデックスが効かないためパフォーマンスが悪化する

FIND_IN_SET最大の欠点は、検索対象のカラムにインデックスが効かないことです。

たとえば、以下のようなクエリを実行したとします。

SELECT * FROM user_tags
WHERE FIND_IN_SET('python', tags);

この場合、tagsカラムにインデックスを張っていても、FIND_IN_SET関数を使うことでフルテーブルスキャンになり、MySQLは全行を読み込みながら逐次文字列を解析するしかありません。

そのため、対象のレコードが数千〜数万件を超えるような大規模データでは、検索速度が急激に低下します。

推奨される対応：

• 必要に応じて、中間テーブルを使った正規化を検討
• どうしてもFIND_IN_SETを使う場合は、対象レコードを事前に絞る（LIMITやWHEREの別条件と併用）

正規化に反する構造に依存してしまう

カンマ区切りの文字列を1カラムにまとめる構造自体が、データベースの正規化原則に反しています。

たとえば、"php,python,sql"という文字列は一見扱いやすいように見えますが、以下のような問題があります。

• 値ごとの集計や統計処理が難しい
• 一部の値だけを更新・削除するのが困難
• 値の重複やスペルミスが入りやすい（例：「Python」と「python」）

長期的に見れば、可読性・保守性・拡張性の観点からも大きなデメリットとなることが多く、特にチーム開発やスケーラブルなサービスでは致命的です。

カンマ以外の文字や空白の混入で検索に失敗する

FIND_IN_SETは非常に繊細です。データ中に以下のような問題があると、一致しなくなります。

• 値の前後に空白（スペース、タブ、改行）がある
• 全角カンマ（、）が混じっている
• 意図しないダブルクオートやシングルクオートで囲まれている

例：

FIND_IN_SET('python', 'php, python ,sql')
-- ⇒ マッチしない（空白付き " python " となってしまう）

対策：

• データを登録する段階でTRIM()処理を入れて空白を除去する
• 入力値をREPLACE(tags, ' ', '')で前処理する
• フロントエンドでの入力制限（不要な空白・記号を排除）

一時的な対応策としては有効、でも恒久運用には不向き

FIND_IN_SETは、既存の非正規化テーブルを短期的に活かすための暫定的な手段としては非常に有用です。
ただし、新しく設計するシステムや長期的に拡張・保守される予定のあるシステムでは、極力避けるか、将来的に正規化へ移行する計画を持っておくことが重要です。

7. よくある誤解・失敗例【LIKEとの違い／数値扱い】

FIND_IN_SET関数は一見シンプルに使えるように見えますが、正しく理解して使わないと意図しない結果になることがあります。
この章では、実務でも多い典型的な誤解や失敗パターンを紹介し、それぞれの対策も合わせて解説します。

誤解①：LIKEとFIND_IN_SETの違いがわかっていない

もっとも多いのが、LIKE演算子とFIND_IN_SET()の違いを正しく理解せず、誤った条件で検索してしまうケースです。

-- よくある誤用
SELECT * FROM user_tags WHERE tags LIKE '%python%';

このクエリは一見正しく動作しそうに見えますが、実はpythonという文字列を部分的に含むデータすべてにマッチしてしまいます。

たとえば、"cpython", "pythonista", "java,pythonic"など、本来マッチさせたくないケースまで拾ってしまいます。
また、php,python,sql のようなカンマ区切りの中にある「python」だけを一致させたい場合にも、部分一致のLIKEでは誤検出の可能性が高いのです。

正確に「python」という単語が含まれていることを確認したい場合は、FIND_IN_SET()が適切です。

-- 正しい書き方
SELECT * FROM user_tags WHERE FIND_IN_SET('python', tags);

誤解②：「数値型」の値に対してFIND_IN_SETを使ったら意図通りに動かない

FIND_IN_SETは、両方の引数が文字列として扱われることを前提としています。

そのため、次のようなデータの場合に予期せぬ結果になることがあります。

-- tagsカラムに: 1,2,10,20
SELECT * FROM user_tags WHERE FIND_IN_SET(1, tags);

このクエリでは、1も10も一致してしまうと思われがちですが、実際にはFIND_IN_SET(1, '1,2,10,20')は「1番目の1」にだけ一致します。

FIND_IN_SETは値を区切って完全一致で判定しているため、1は10や21とは異なります。

ただし、開発者によってはこの挙動を誤解し、「1」が「10」にもヒットすると勘違いするケースがあります。

対策： 常に文字列として扱うようにすることで、意図しない動作を防げます。

誤解③：空白・全角カンマ・改行などが混じって正しく一致しない

FIND_IN_SETは非常に繊細です。データ中に以下のような問題があると、一致しなくなります。

• 値の前後に空白（スペース、タブ、改行）がある
• 全角カンマ（、）が混じっている
• 意図しないダブルクオートやシングルクオートで囲まれている

例：

FIND_IN_SET('python', 'php, python ,sql')
-- ⇒ マッチしない（空白付き " python " となってしまう）

対策：

• データを登録する段階でTRIM()処理を入れて空白を除去する
• 入力値をREPLACE(tags, ' ', '')で前処理する
• フロントエンドでの入力制限（不要な空白・記号を排除）

まとめ：FIND_IN_SETを安全に使うためのポイント

こうした細かい挙動を理解せずに使ってしまうと、「検索できているつもり」で実は期待したデータが抽出されていなかったという重大なバグにつながる可能性があります。

次章では、これらの問題を根本から解決するために有効な「FIND_IN_SETの代替手段」について解説します。

8. FIND_IN_SETの代替手段【ベストプラクティス】

FIND_IN_SET関数は、カンマ区切りの文字列に対して柔軟な検索を可能にする便利な関数ですが、大規模データや拡張性を求めるシステムには不向きです。
この章では、FIND_IN_SETを使用しない、より推奨される代替手段（ベストプラクティス）を紹介します。

正規化されたテーブル設計に切り替える

もっとも推奨される方法は、データベースを正規化し、値を個別の行として管理することです。
カンマ区切りの1カラムに複数の値を保存するのではなく、中間テーブル（リレーションテーブル）を用いて、多対多の関係を明確に表現します。

例：ユーザーとタグの関係

従来の構造（非正規化）：

正規化後の構造：

users テーブル

tags テーブル

user_tag_relation（中間テーブル）

このように分けることで、FIND_IN_SETを使わずともJOINで柔軟に検索が可能になります。

SELECT users.*
FROM users
JOIN user_tag_relation ON users.id = user_tag_relation.user_id
JOIN tags ON user_tag_relation.tag_id = tags.id
WHERE tags.name = 'python';

この方法ならインデックスも有効に使え、パフォーマンスや拡張性も大幅に向上します。

JSON型を活用する（MySQL 5.7以降）

MySQL 5.7以降では、JSON型のカラムが利用可能です。カンマ区切りの文字列ではなく、JSON配列として値を格納することで、構造化されたデータのまま保存し、関数を使って検索ができます。

例：

["php", "python", "sql"]

検索例：

SELECT * FROM user_tags
WHERE JSON_CONTAINS(tags_json, '"python"');

この方法では、タグが構造的に保存されており、誤検出や空白の混入といった問題も防げます。
また、JSON型には専用のインデックス（MySQL 8.0以降）も利用でき、パフォーマンス向上も期待できます。

アプリケーション側で分解・再構築する

どうしてもFIND_IN_SETを使う設計を変えられない場合でも、アプリケーション側で配列に変換してループ処理やSQLのIN句に変換することで、類似の挙動を実現することができます。

例（PHP）:

$tags = explode(',', $record['tags']);
if (in_array('python', $tags)) {
    // 処理を実行
}

このようにすれば、データベース側の負荷を軽減しつつ、安全な処理を行うことが可能です。

FIND_IN_SETは“例外処理”として活用すべき

繰り返しになりますが、FIND_IN_SETは「既存の非正規化テーブルを短期的に活かすための暫定的な手段」としては非常に有用です。
ただし、新規で設計するシステムや長期的に拡張・保守される予定のあるシステムでは、極力避けるか、将来的に正規化へ移行する計画を持っておくことが重要です。

9. 【FAQ】よくある質問とその回答

FIND_IN_SET関数に関しては、実際の業務や学習中に多くの疑問や混乱が生じやすいポイントがあります。
ここでは、検索意図にも合致しやすく、よくある質問をQ&A形式で整理しました。

Q1. FIND_IN_SET関数はどんなときに使うのが正解ですか？

A.
FIND_IN_SET関数は、カンマ区切りの文字列に特定の値が含まれているかを調べたいときに使用されます。
具体的には、次のような場面に適しています：

• 設計上、1カラムに複数値を保存する必要がある（例：タグ、権限、フラグなど）
• 既存の非正規化データベースを修正せずに検索だけしたい
• 小〜中規模のデータ量で、限定的に使用する用途（管理画面、ツール系）

ただし、大量データや本番システムのコア処理には向いていません。

Q2. FIND_IN_SETとLIKEの違いは何ですか？

A.
LIKE '%値%'は部分一致検索であり、前後に何があってもヒットします。
一方、FIND_IN_SET('値', カンマ区切り文字列)は、カンマで区切られた1つ1つの値として完全一致で検索します。

-- LIKEの例（"python"を含むすべてにマッチ）
tags LIKE '%python%'

-- FIND_IN_SETの例（"python"という独立した要素にだけマッチ）
FIND_IN_SET('python', tags)

「python」が「cpython」や「pythonista」にも含まれてしまうのはLIKEの落とし穴です。

Q3. FIND_IN_SET関数を使うとSQLが遅くなるのはなぜ？

A.
FIND_IN_SETは、インデックスを使わずにフルスキャンする関数だからです。
カラム全体を1行ずつ確認し、文字列を分解して比較する処理が入るため、データ量が増えると急激に処理時間が延びます。

そのため、レコード数が多いテーブルではパフォーマンス劣化に直結します。

Q4. 数字を検索するときに「1」と「10」が誤認識されることはありませんか？

A.
FIND_IN_SETは完全一致の検索なので、基本的には「1」と「10」は別物として判定されます。
ただし、検索値やデータに空白やキャストの違いがあると、想定通りに動かないこともあります。

-- 正しい例
FIND_IN_SET('1', '1,2,10') -- ⇒ 1（1番目）

-- 誤解されがちな例
FIND_IN_SET(1, '1,2,10') -- ⇒ 同様に1（OKだが曖昧）

推奨： 常に文字列として扱うようにすることで、意図しない動作を防げます。

Q5. WordPressでFIND_IN_SETを使えますか？

A.
WordPress標準のmeta_queryなどではFIND_IN_SETは使えませんが、$wpdbを使った直接SQL発行で利用可能です。

global $wpdb;
$sql = $wpdb->prepare("
  SELECT * FROM {$wpdb->prefix}postmeta
  WHERE meta_key = %s AND FIND_IN_SET(%s, meta_value)
", 'your_meta_key', '検索値');

$results = $wpdb->get_results($sql);

ただし、DB設計がカスタムフィールドに依存している場合は、代替の方法（複数メタキー管理など）も検討すべきです。

Q6. JSON型との違いは？FIND_IN_SETより便利？

A.
MySQL 5.7以降のJSON型カラムを使えば、構造化されたデータを保持でき、JSON_CONTAINS()で検索も可能です。
FIND_IN_SETよりも精度・拡張性・柔軟性に優れています。

-- JSONでの検索
SELECT * FROM users WHERE JSON_CONTAINS(tags_json, '"python"');

今後の設計では、FIND_IN_SETよりJSON型を優先するのがトレンドです。

10. まとめ：FIND_IN_SETは“便利な例外”｜構造設計を見直すきっかけに

この記事では、MySQLのFIND_IN_SET()関数について、基本構文から実用的な応用例、注意点、代替手段に至るまで幅広く解説してきました。

一見すると地味な関数ですが、正しく使えばデータベース運用の幅を広げる強力なツールであることがおわかりいただけたかと思います。

FIND_IN_SETの特徴を振り返る

使用すべきケースと避けるべきケース

使ってOKな場面：

• 検索対象が小規模かつ用途が限定されている
• 既存システムの改修が難しく、即時対応が必要
• 管理画面やバッチ処理などで一時的に対応したい

使うべきでない場面：

• 大規模データで検索速度が求められる場面
• 頻繁に更新・集計・条件変更が必要な業務
• 将来的な拡張・保守を前提とする設計

FIND_IN_SETは“便利な例外”。本質は設計の見直しにある

FIND_IN_SETは、あくまで構造的な制約があるときの回避策です。
もし新規でテーブル設計を行うのであれば、以下の2点をぜひ検討してください。

• データベースは正規化して多対多を中間テーブルで管理する
• 柔軟性が必要ならJSON型を導入して構造化データを扱う

本記事をきっかけに、FIND_IN_SETの使いどころと限界、そして「設計の見直し」こそが最適解であることを再認識していただければ幸いです。