SQL LIKE部分一致とエスケープ｜%・_の扱いをDB別にコピペ解説

SQLのLIKEとは、%（0文字以上の任意の文字列）と _（任意の1文字）という2つのワイルドカードで、文字列のパターン一致を調べる演算子です。 name LIKE '%ジュース%' と書けば「ジュース」を含む行、name LIKE 'apple%' と書けば「apple」で始まる行が取り出せます。

ただし、使い込むと次のような疑問が出てきます。「50% という文字そのものを探したいときは？」「同じSQLなのにMySQLとPostgreSQLで件数が違う」「% から始まる検索は遅い？」。この記事では、PostgreSQL 16.15・MySQL 8.0.46・SQLite 3.45.1 で同じSQLを実行した結果を並べて、基本の書き方からエスケープ、大文字小文字、アプリからの安全な渡し方、インデックスまでを一通り確認します。上位の解説記事にあまりない「DB別の既定エスケープ文字」「照合順序による件数の違い」「EXPLAINでの確認」を、実際の出力つきで載せています。

MySQL 8.0 は2026年4月にサポートが終了しています。本記事の検証は手元の 8.0.46 で行いましたが、ここで扱うLIKE・ESCAPE・照合順序・EXPLAINの書き方は MySQL 8.4／9.7 でも同じ手順で使えます（違いがある箇所は本文で明記します）。

SQL LIKEの早見表

DB別の違い（要点）

（SQL Server・Oracle の列は公式ドキュメントで確認した内容で、本記事の環境では実行していません。）

サンプルデータを用意する

以下の表で全DB共通のSQLを動かします。そのまま貼り付けて試せます。

DROP TABLE IF EXISTS items;
CREATE TABLE items (id INT PRIMARY KEY, name VARCHAR(50));
INSERT INTO items VALUES
 (1,'Apple Juice'),(2,'apple pie'),(3,'Pineapple'),(4,'グレープジュース'),
 (5,'ジュースセット'),(6,'50%オフ'),(7,'500円引き'),(8,'user_id'),(9,'userXid'),(10,'C:\temp');

MySQLだけは 'C:\temp' の \t がタブ文字に変換されて保存されます。 MySQLの文字列リテラルではバックスラッシュがエスケープ文字だからです。MySQLでは 'C:\\temp' と2つ重ねて書いてください。また、mysqlクライアントの文字コードが latin1 のままだと日本語の比較結果が変わるため、mysql --default-character-set=utf8mb4 で接続します。

前方一致・後方一致・部分一致を書く

基本の3パターン

SELECT id, name FROM items WHERE name LIKE 'apple%'     ORDER BY id;  -- 前方一致
SELECT id, name FROM items WHERE name LIKE '%ジュース'   ORDER BY id;  -- 後方一致
SELECT id, name FROM items WHERE name LIKE '%ジュース%'  ORDER BY id;  -- 部分一致

実行結果（3つのDBで比較）

前方一致の件数がDBによって違います。 PostgreSQLはLIKEで大文字小文字を区別し、MySQL（既定の照合順序 utf8mb4_0900_ai_ci）とSQLiteは区別しないためです。詳しくは後半の「大文字小文字」の章で確認します。

_（アンダースコア）で1文字だけ任意にする

SELECT id, name FROM items WHERE name LIKE 'user_id' ORDER BY id;

 id |  name
----+---------
  8 | user_id
  9 | userXid
(2 rows)

_ は「ちょうど1文字」のワイルドカードです。 user_id という列名やコードをそのまま条件に書くと、userXid のような値まで一致します。_ を文字として探す方法は次の章で扱います。

NOT LIKE で除外する

SELECT id, name FROM items WHERE name NOT LIKE '%ジュース%' ORDER BY id;

結果は3つのDBとも id 1〜3、6〜10 の8件でした。NOT LIKE は NULL の行を返しません。 name が NULL の行は LIKE でも NOT LIKE でも結果が「不明」になるため、NULLも含めたいときは name NOT LIKE '%ジュース%' OR name IS NULL と書きます。

複数条件（OR／AND）

-- どちらかを含む
SELECT id, name FROM items WHERE name LIKE '%pie%' OR name LIKE '%ジュース' ORDER BY id;
-- すべてを含む（p を含み、かつ e で終わる）
SELECT id, name FROM items WHERE name LIKE '%p%' AND name LIKE '%e' ORDER BY id;

キーワードが多いときの書き方もDBごとに用意されています。

WHERE category = 1 AND name LIKE '%a%' OR name LIKE '%b%' のように括弧を忘れると、AND が先に評価されて意図しない行まで返ります。OR を含む条件は括弧で囲むと覚えておくと安心です。

%や_を含む文字列を検索する（エスケープ）

エスケープしないとどうなるか

「50%」という文字を含む商品を探すつもりで LIKE '50%' と書くと、% がワイルドカードとして働きます。

SELECT id, name FROM items WHERE name LIKE '50%' ORDER BY id;

 id |   name
----+-----------
  6 | 50%オフ
  7 | 500円引き
(2 rows)

「50で始まる」という意味になり、500円引き も一致します。 % や _ を文字として扱うには、直前にエスケープ文字を置きます。

ESCAPE句を使う（全DB共通の書き方）

SELECT id, name FROM items WHERE name LIKE '50!%%'     ESCAPE '!' ORDER BY id;
SELECT id, name FROM items WHERE name LIKE 'user!_id'  ESCAPE '!' ORDER BY id;

実行結果（PostgreSQL 16・MySQL 8.0・SQLite 3.45 すべて同じ）

 id |  name
----+---------
  6 | 50%オフ
(1 row)

 id |  name
----+---------
  8 | user_id
(1 row)

'50!%%' は「!% ＝文字としての%」＋「% ＝ワイルドカード」です。ESCAPE句で ! や # のような記号を指定する書き方が、どのDBでも同じ結果になるのでおすすめです。 バックスラッシュは文字列リテラル側でも特別な意味を持つDBがあり、書き方がDBごとに変わるためです。

既定のエスケープ文字（ESCAPE句なし）をDB別に比べる

ESCAPE句を書かずに \ でエスケープしたときの結果です。

PostgreSQLとMySQLは \ が既定のエスケープ文字、SQLiteには既定のエスケープ文字がありません。 SQLiteでは \ がただの文字として比較されるので、50\ で始まる行を探すことになり0件です。SQLiteでは必ず ESCAPE 句を書きます。

SQL Server と Oracle は公式ドキュメントで確認しました（本記事では未実行）。

SQL Server では [ 自体も特別な文字（[a-c] のような文字集合）になる点が他のDBと異なります。

バックスラッシュそのものを探す

C:\temp のようにバックスラッシュを含む値を探す場合です。

MySQLは「文字列リテラル」と「LIKEのパターン」の2段階でバックスラッシュが解釈されます。 'C:\\%' はリテラルの段階で C:\% になり、パターンの段階で \% が「文字としての%」になるため0件です。ESCAPEを ! に変えると \ がただの文字になり、意図どおり一致します。

MySQLの NO_BACKSLASH_ESCAPES モード

MySQL の sql_mode に NO_BACKSLASH_ESCAPES を加えると、バックスラッシュは文字列リテラルでもLIKEでもエスケープ文字ではなくなります。

SET SESSION sql_mode = CONCAT(@@sql_mode, ',NO_BACKSLASH_ESCAPES');
SELECT id, name FROM items WHERE name LIKE '50\%%';             -- 0件
SELECT id, name FROM items WHERE name LIKE '50!%%' ESCAPE '!';  -- 6 50%オフ
SELECT id, name FROM items WHERE name LIKE 'C:\%';              -- 10 C:\temp

サーバー設定によって \ の意味が変わるため、ESCAPE句で記号を明示しておくと設定に左右されません。

大文字小文字・ひらがなカタカナの区別

サンプルに (11,'じゅーす'),(12,'ｊｕｉｃｅ'),(13,'ÄPFEL') を追加して比べました。

PostgreSQL：LIKE は区別、ILIKE は区別しない

SELECT id, name FROM items WHERE name LIKE  '%juice%';  -- 0件
SELECT id, name FROM items WHERE name ILIKE '%juice%';  -- 1 Apple Juice
SELECT id, name FROM items WHERE lower(name) LIKE lower('%JUICE%');  -- 1 Apple Juice

ILIKE はPostgreSQL独自の「大文字小文字を区別しないLIKE」です（演算子では ~~*）。全角の ｊｕｉｃｅ は半角とは別の文字なので、ILIKEでも一致しません。他のDBへ移す可能性があるSQLでは lower() 同士で比べる書き方が使いやすいです。

MySQL：照合順序（collation）で決まる

MySQLの既定の照合順序 utf8mb4_0900_ai_ci は、大文字小文字・アクセント・全角半角・ひらがなカタカナを同じ文字として比べます。 あいまいに探したい検索窓には便利で、厳密に探したいときは COLLATE utf8mb4_bin を付けます。

検証中に気づいた点として、MySQL 8.0.46 では日本語用の utf8mb4_ja_0900_as_cs_ks（かな区別あり）を指定しても、LIKE では ジュース と じゅーす が一致しました。

SELECT 'ジュース' =    'じゅーす' COLLATE utf8mb4_ja_0900_as_cs_ks AS eq_ks,
       'ジュース' LIKE 'じゅーす' COLLATE utf8mb4_ja_0900_as_cs_ks AS like_ks,
       'ジュース' LIKE 'じゅーす' COLLATE utf8mb4_bin              AS like_bin;

+-------+---------+----------+
| eq_ks | like_ks | like_bin |
+-------+---------+----------+
|     0 |       1 |        0 |
+-------+---------+----------+

= ではかなを区別し、LIKE では区別しない結果でした。 ひらがなとカタカナを確実に分けてLIKE検索したいときは utf8mb4_bin を使うと意図どおりになります。照合順序そのものの比較は「MySQL照合順序（collation）の違い」の記事で詳しくまとめています。

SQLite：ASCIIの英字だけ区別しない

SELECT id, name FROM items WHERE name LIKE '%juice%';   -- 1 Apple Juice
SELECT id, name FROM items WHERE name LIKE 'äpfel';     -- 0件（Ä と ä は別扱い）
PRAGMA case_sensitive_like = ON;
SELECT id, name FROM items WHERE name LIKE '%juice%';   -- 0件
SELECT id, name FROM items WHERE name GLOB '*Juice*';   -- 1 Apple Juice

SQLiteのLIKEはASCIIの英字だけ大文字小文字を同一視します。 PRAGMA case_sensitive_like = ON で区別するように切り替えられ、GLOB（* と ? を使うパターン）は常に区別します。

大文字小文字の判断表

アプリからLIKEを使う（プレースホルダとエスケープ関数）

検索窓の入力を条件にするときは、SQLを文字列連結せずプレースホルダ（? や %s）で渡し、そのうえで % _ をエスケープするのが基本です。プレースホルダはSQLインジェクションを防ぎますが、% や _ はLIKEのワイルドカードとしてそのまま働くため、「50%」と入力すると 500円引き まで一致します。

Python（sqlite3）

import sqlite3

def escape_like(s: str, esc: str = "!") -> str:
    """LIKE のワイルドカード（% と _）とエスケープ文字自体をエスケープする"""
    return (s.replace(esc, esc + esc)
             .replace("%", esc + "%")
             .replace("_", esc + "_"))

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT)")
conn.executemany("INSERT INTO items(name) VALUES (?)",
                 [("50%オフ",), ("500円引き",), ("user_id",), ("userXid",), ("C:\\temp",)])

for keyword in ["50%", "user_id", "C:\\"]:
    raw = conn.execute("SELECT name FROM items WHERE name LIKE ? ORDER BY id",
                       (f"%{keyword}%",)).fetchall()
    safe = conn.execute("SELECT name FROM items WHERE name LIKE ? ESCAPE '!' ORDER BY id",
                        (f"%{escape_like(keyword)}%",)).fetchall()
    print(f"{keyword!r:12} エスケープなし={[r[0] for r in raw]}  エスケープあり={[r[0] for r in safe]}")

実行結果（Python 3.11）

'50%'        エスケープなし=['50%オフ', '500円引き']  エスケープあり=['50%オフ']
'user_id'    エスケープなし=['user_id', 'userXid']  エスケープあり=['user_id']
'C:\\'       エスケープなし=['C:\\temp']  エスケープあり=['C:\\temp']

エスケープ文字自体（ここでは !）を最初に置き換えるのがポイントです。順番を逆にすると、% を !% に変えたあとでその ! が !! になり、意味が変わってしまいます。

同じ escape_like() と ESCAPE '!' を、psycopg 3.3.6（PostgreSQL 16）と PyMySQL（MySQL 8.0）でも実行しました。

SQL = "SELECT name FROM items WHERE name LIKE %s ESCAPE '!' ORDER BY id"
cur.execute(SQL, (f"%{escape_like(keyword)}%",))

PostgreSQL '50%' → ['50%オフ']
PostgreSQL 'user_id' → ['user_id']
PostgreSQL 'C:\\' → ['C:\\temp']
MySQL '50%' → ['50%オフ']
MySQL 'user_id' → ['user_id']
MySQL 'C:\\' → ['C:\\temp']

ESCAPE文字を ! にそろえると、同じ関数がSQLite・PostgreSQL・MySQLのどれでもそのまま使えました。

JavaScript（Node.js 22 の node:sqlite）

import { DatabaseSync } from 'node:sqlite';

// LIKE のワイルドカード（% と _）とエスケープ文字自体をエスケープする
const escapeLike = (s, esc = '!') =>
  s.replaceAll(esc, esc + esc).replaceAll('%', esc + '%').replaceAll('_', esc + '_');

const db = new DatabaseSync(':memory:');
db.exec('CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT)');
const ins = db.prepare('INSERT INTO items(name) VALUES (?)');
for (const n of ['50%オフ', '500円引き', 'user_id', 'userXid', 'C:\\temp']) ins.run(n);

const stmt = db.prepare("SELECT name FROM items WHERE name LIKE ? ESCAPE '!' ORDER BY id");
for (const keyword of ['50%', 'user_id', 'C:\\']) {
  const rows = stmt.all(`%${escapeLike(keyword)}%`).map(r => r.name);
  console.log(keyword.padEnd(8), '→', rows);
}

実行結果（Node.js v22.22.2、node like_escape.mjs）

50%      → [ '50%オフ' ]
user_id  → [ 'user_id' ]
C:\      → [ 'C:\\temp' ]

Node.js 22 の node:sqlite は実行時に ExperimentalWarning を表示します。pg や mysql2 など他のドライバでも、escapeLike() とプレースホルダの組み合わせは同じです。SQL Server を使う場合は [ もエスケープ対象に加えると、[a-c] のような文字集合として解釈されるのを防げます。

インデックスが効くLIKE・効かないLIKE

判断表

MySQL 8.0 の EXPLAIN

20万行の products(code) にインデックスを作って比べました。

CREATE INDEX idx_code ON products(code);
EXPLAIN ANALYZE SELECT * FROM products WHERE code LIKE 'P00123%';
EXPLAIN ANALYZE SELECT * FROM products WHERE code LIKE '%0123%';

-> Index range scan on products using idx_code over ('P00123' <= code <= 'P00123????...'),
   with index condition: (products.`code` like 'P00123%')  (cost=45.3 rows=100) (actual time=0.037..0.225 rows=100 loops=1)

-> Filter: (products.`code` like '%0123%')  (cost=20146 rows=22177) (actual time=0.122..68.4 rows=1140 loops=1)
    -> Table scan on products  (cost=20146 rows=199613) (actual time=0.0894..40.5 rows=200000 loops=1)

（1行目の ???? は長いため途中を省略しています。）前方一致は Index range scan、% 始まりは Table scan で20万行すべてを読んでいます。

PostgreSQL 16 の EXPLAIN（照合順序に注意）

CREATE INDEX idx_code ON products(code);
EXPLAIN SELECT * FROM products WHERE code LIKE 'P00123%';

 Seq Scan on products  (cost=0.00..4166.00 rows=20 width=34)
   Filter: ((code)::text ~~ 'P00123%'::text)

PostgreSQLでは、データベースの照合順序が C 以外（今回は C.UTF-8）だと、通常のB-treeインデックスはLIKEの前方一致に使われません。 varchar_pattern_ops（text型なら text_pattern_ops）を付けたインデックスを作ると使われます。

CREATE INDEX idx_code_pattern ON products(code varchar_pattern_ops);
EXPLAIN ANALYZE SELECT * FROM products WHERE code LIKE 'P00123%';

 Index Scan using idx_code_pattern on products  (cost=0.42..8.44 rows=20 width=34) (actual time=0.032..0.048 rows=100 loops=1)
   Index Cond: (((code)::text ~>=~ 'P00123'::text) AND ((code)::text ~<~ 'P00124'::text))
   Filter: ((code)::text ~~ 'P00123%'::text)
 Execution Time: 0.073 ms

'P00123%' が >= 'P00123' AND < 'P00124' の範囲検索に変換されているのがわかります。同じ表で LIKE '%0123%' は Seq Scan（Rows Removed by Filter: 198860、Execution Time: 39.563 ms）でした。

部分一致を速くする代替手段

pg_trgm で LIKE '%ジュース%' を実行した結果です（PostgreSQL 16、20万行中2,000件一致）。

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX idx_name_trgm ON products USING gin (name gin_trgm_ops);
EXPLAIN ANALYZE SELECT count(*) FROM products WHERE name LIKE '%ジュース%';

   ->  Bitmap Heap Scan on products  (cost=21.59..95.27 rows=20 width=0) (actual time=0.808..2.141 rows=2000 loops=1)
         Recheck Cond: (name ~~ '%ジュース%'::text)
         ->  Bitmap Index Scan on idx_name_trgm  (cost=0.00..21.59 rows=20 width=0) (actual time=0.299..0.299 rows=2000 loops=1)
               Index Cond: (name ~~ '%ジュース%'::text)
 Execution Time: 2.275 ms

% 始まりのLIKEのまま、インデックスが使われました。 ILIKE '%ジュース%' でも同じGINインデックスが使われ、Execution Time は 2.551 ms でした。pg_trgm は3文字単位で索引を作るため、2文字以下の検索語では効果が出にくい点に注意します。MySQLでは ALTER TABLE products ADD FULLTEXT INDEX ft_name (name) WITH PARSER ngram; を作成し、MATCH(name) AGAINST('ジュース' IN BOOLEAN MODE) で LIKE と同じ2,000件が返ることを確認しました。全文検索の詳しい比較やインデックスが使われない他のパターンは、「PostgreSQL日本語全文検索」「SQLのインデックスが効かない10のパターン」の記事で扱っています。

よくあるつまずきと直し方

よくある質問

Q. LIKEと = はどちらが速いですか？ A. ワイルドカードを含まない LIKE 'abc' は = 'abc' とほぼ同じ扱いになることが多いですが、意図が伝わりやすいので完全一致は = で書くのがおすすめです。末尾の空白の扱いなど細かな違いもあります。

Q. ESCAPE に使う文字は何がよいですか？ A. 検索対象のデータにあまり出てこない1文字の記号（!、#、^ など）が扱いやすいです。本記事の escape_like() のようにエスケープ文字自体もエスケープしておけば、データに含まれていても正しく検索できます。

Q. 正規表現（REGEXP、~）とLIKEはどう使い分けますか？ A. 「含む」「始まる」程度ならLIKEが読みやすく、前方一致ならインデックスも使えます。「数字が3桁続く」のような複雑な条件は正規表現が向いています。

Q. MySQL 8.4 や 9.7 でも同じ結果になりますか？ A. 本記事で扱ったLIKE・ESCAPE・NO_BACKSLASH_ESCAPES・照合順序の指定方法は、8.4／9.7でも同じ手順で使えます。照合順序ごとの細かな比較結果はバージョンで変わる可能性があるため、重要な検索は利用中のバージョンで本記事のSQLを一度実行して確認すると確実です。

まとめ

• LIKEのワイルドカードは %（0文字以上）と _（1文字）の2つ。前方・後方・部分一致は % の位置で決まる
• % や _ を文字として探すときは ESCAPE '!' を明示すると、PostgreSQL・MySQL・SQLiteで同じ結果になる
• 既定のエスケープ文字はPostgreSQLとMySQLが \、SQLite・SQL Server・Oracleはなし。SQL Serverは [%] も使える
• 大文字小文字の扱いはDBごとに異なる。PostgreSQLは ILIKE、MySQLは COLLATE、SQLiteは PRAGMA で切り替える
• アプリではプレースホルダ＋エスケープ関数。エスケープ文字自体を最初に置き換える
• インデックスが効くのは前方一致。PostgreSQLは照合順序によって text_pattern_ops が必要
• 部分一致を速くしたいときは pg_trgm や FULLTEXT（ngram） を検討する

株式会社RJCでは、SQLの検索の書き方やDBごとの違いを仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。