SQLite LIKE入門：ワイルドカードを活用したデータ抽出

SQLite LIKE入門：ワイルドカードを活用したデータ抽出

はじめに：データ抽出の核心としてのLIKE演算子

現代社会において、データは「新たな石油」とまで呼ばれるほど重要な資源となっています。ビジネスの意思決定、科学研究、個人の日常生活に至るまで、あらゆる場面でデータが活用されています。しかし、データがいくら膨大にあっても、そこから必要な情報を効率的に「抽出」できなければ、その価値を最大限に引き出すことはできません。

リレーショナルデータベースは、このデータ管理と抽出の根幹をなす技術です。その中でも、SQL（Structured Query Language）は、データベースと対話するための標準言語として広く利用されています。SQLの最も基本的な操作の一つが、SELECT文を用いたデータ取得です。SELECT文は、データベース内のテーブルから特定の条件に合致するレコード（行）やカラム（列）を取り出すために使用されます。

通常、SELECT文で条件を指定する際には、WHERE句と組み合わせ、等号（=）や不等号（<, >, <=, >=）、あるいはBETWEEN, INなどの演算子を使用します。しかし、これらの演算子は、値が完全に一致する場合や、特定の範囲内にある場合など、比較的厳密な条件を指定する際に有効です。

では、「顧客名に『田中』が含まれるすべての記録を検索したい」「製品名が『XYZ』で始まるものを抽出したい」「電話番号の真ん中の桁だけが不明なレコードを見つけたい」といった、部分的な一致やあいまいなパターンでの検索を行いたい場合はどうでしょうか？このようなニーズに対して、従来の厳密な比較演算子では対応できません。

ここで登場するのが、本記事の主役であるLIKE演算子です。LIKE演算子は、特定の文字列パターンに合致するデータを検索するための強力なツールであり、その能力を最大限に引き出すのが「ワイルドカード」です。ワイルドカードを使用することで、文字列の一部が不明な場合や、様々なバリエーションを持つ文字列を柔軟に検索することが可能になります。

本記事では、データベース管理システムの一つであるSQLiteを例にとり、LIKE演算子の基礎から、二種類の主要なワイルドカード（%と_）の徹底的な活用方法、さらにはNOT LIKE、ESCAPE句といった高度なテクニック、そしてパフォーマンスに関する考慮事項まで、網羅的に解説していきます。約5000語にわたる詳細な説明と豊富な具体例を通じて、あなたがSQLiteにおけるデータ抽出のエキスパートになるための一助となれば幸いです。

1. SQLの基本とLIKE演算子への導入

1.1 データベースの基本的な概念

データベースは、構造化された情報の集合体です。リレーショナルデータベースでは、データはテーブルと呼ばれる二次元の表形式で管理されます。

• テーブル (Table): 関連するデータの集合。スプレッドシートのシートに似ています。
• カラム (Column): テーブルの縦の列。データの種類（例：名前、年齢、住所）を定義します。カラムにはデータ型（TEXT, INTEGER, REALなど）が設定されます。
• レコード/行 (Record/Row): テーブルの横の行。特定のエンティティ（例：一人の顧客、一つの製品）に関する完全な情報を含みます。

例えば、以下のようなUsersテーブルを考えます。

UserID	UserName	Email	Phone	Address
1	山田太郎	[email protected]	090-1234-5678	東京都渋谷区
2	鈴木花子	[email protected]	080-9876-5432	大阪府梅田区
3	佐藤健太	[email protected]	070-1111-2222	東京都新宿区

1.2 SELECT文の基本構文とWHERE句

SQLでデータを抽出する際の基本はSELECT文です。

sql
SELECT カラム名1, カラム名2, ...
FROM テーブル名
WHERE 条件;

• SELECT: どのカラムを取得するかを指定します。*を使用すると、すべてのカラムを取得します。
• FROM: どのテーブルからデータを取得するかを指定します。
• WHERE: どのような条件を満たすレコードを取得するかを指定します。この句がなければ、テーブル内のすべてのレコードが返されます。

例：UserNameが「山田太郎」のレコードを取得する

sql
SELECT *
FROM Users
WHERE UserName = '山田太郎';

1.3 従来の比較演算子の限界

WHERE句で用いられる一般的な比較演算子には以下のようなものがあります。

• =：等しい
• <> または !=：等しくない
• <：より小さい
• >：より大きい
• <=：より小さいか等しい
• >=：より大きいか等しい
• BETWEEN min AND max：範囲内にある
• IN (値1, 値2, ...)：リスト内のいずれかの値に一致する
• IS NULL / IS NOT NULL：NULLである / NULLでない

これらの演算子は非常に有用ですが、文字列の部分一致検索には対応していません。例えば、「メールアドレスに『example.com』が含まれるユーザーを探したい」という場合、Email = '[email protected]'のように完全一致でしか検索できません。部分的に一致する文字列を検索したいというニーズは非常に頻繁に発生し、これを解決するためにLIKE演算子が必要となるのです。

1.4 LIKE演算子の必要性：部分一致検索

LIKE演算子は、文字列が特定のパターンに「似ている」かどうかを判定するために使用されます。この「似ている」という概念は、ワイルドカード文字によって定義されます。ワイルドカードを使うことで、文字列の特定の位置に任意の文字や文字列が存在する場合でも、条件に合致させることが可能になります。

例えば、「UserNameが『山』で始まる人」「Emailに『.jp』が含まれる人」「Phone番号の3桁目が『0』の人」といった、柔軟な検索要求に応えることができます。これがLIKE演算子が持つ、他の比較演算子にはない独自の強力な機能です。

2. LIKE演算子の基礎

LIKE演算子は、WHERE句の中で使用され、カラムの値と指定されたパターンが一致するかどうかを評価します。

2.1 LIKE演算子の構文

基本的な構文は以下の通りです。

sql
SELECT column_name(s)
FROM table_name
WHERE column_name LIKE pattern;

• column_name: 検索対象となるカラムの名前。通常はテキスト型のカラムです。
• pattern: 検索したい文字列パターン。このパターンの中にワイルドカードを含めます。パターンはシングルクォート（'）で囲む必要があります。

2.2 基本的な使用例（固定文字列の検索）

ワイルドカードを使用しない場合、LIKEは=と同じ動作をします。

サンプルテーブル：Products

“`sql
— テーブルの作成
CREATE TABLE Products (
ProductID INTEGER PRIMARY KEY,
ProductName TEXT NOT NULL,
Description TEXT,
Category TEXT,
Price REAL
);

— サンプルデータの挿入
INSERT INTO Products (ProductID, ProductName, Description, Category, Price) VALUES
(1, ‘Apple iPhone 13’, ‘最新のスマートフォン’, ‘スマートフォン’, 999.99),
(2, ‘Samsung Galaxy S22’, ‘高性能Androidスマートフォン’, ‘スマートフォン’, 899.99),
(3, ‘Sony WH-1000XM4’, ‘ノイズキャンセリングヘッドホン’, ‘オーディオ’, 349.00),
(4, ‘Apple MacBook Air M1’, ‘超薄型ノートパソコン’, ‘ノートPC’, 1199.00),
(5, ‘Logitech MX Master 3’, ‘高機能ワイヤレスマウス’, ‘PC周辺機器’, 99.99),
(6, ‘Bose QuietComfort Earbuds’, ‘ノイズキャンセリングイヤホン’, ‘オーディオ’, 279.00),
(7, ‘Google Pixel 6’, ‘Google製Androidスマートフォン’, ‘スマートフォン’, 699.00),
(8, ‘Dell XPS 13’, ‘高性能Windowsノートパソコン’, ‘ノートPC’, 1399.00),
(9, ‘Microsoft Surface Pro 8’, ‘タブレットにもなるPC’, ‘ノートPC’, 1099.00),
(10, ‘Canon EOS R5’, ‘プロ向けミラーレスカメラ’, ‘カメラ’, 3899.00);
“`

クエリ例：ProductNameが完全に「Apple iPhone 13」であるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'Apple iPhone 13';

結果：

“`
ProductName

---

Apple iPhone 13
“`

この例では、=演算子を使用した場合と全く同じ結果になります。LIKEの真価は、後述するワイルドカードと組み合わせて発揮されます。

2.3 大文字・小文字の区別（SQLiteのデフォルト動作と設定について）

SQLiteのLIKE演算子における大文字・小文字の区別は、他のデータベースシステム（例えばMySQLやPostgreSQL、SQL Server）と比較して独特の振る舞いをします。

SQLiteのデフォルト動作：
SQLiteのデフォルトでは、LIKE演算子はASCIIの範囲内では大文字・小文字を区別しません（ケースインセンシティブ）。これは、英語などのアルファベットにおいては、「’A’ LIKE ‘a’」が真となることを意味します。

例：ProductNameが「apple iphone 13」であるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'apple iphone 13';

結果：

“`
ProductName

---

Apple iPhone 13
“`

見ての通り、元のデータは「Apple iPhone 13」ですが、パターンを小文字で指定しても一致しました。これはSQLiteのデフォルトのLIKE動作によるものです。

日本語や非ASCII文字の場合：
ただし、このケースインセンシティブな挙動は、ASCII文字に限定されます。日本語のひらがな・カタカナ、漢字、あるいは他のユニコード文字に対しては、デフォルトで大文字・小文字（のような概念）を区別します（ケースセンシティブ）。

例：ProductNameに「ノイズ」が含まれるものを検索

“`sql
— 「ノイズ」が含まれるものを検索 (元のデータは「ノイズキャンセリングヘッドホン」)
SELECT ProductName FROM Products WHERE ProductName LIKE ‘%ノイズ%’;
— 結果：Sony WH-1000XM4, Bose QuietComfort Earbuds

— 「のいず」と小文字（ひらがな）で検索
SELECT ProductName FROM Products WHERE ProductName LIKE ‘%のいず%’;
— 結果：なし (大文字・小文字が区別されるため)
“`

COLLATE NOCASEの紹介と使用例：
もし、ASCII以外の文字、特にユニコード文字に対しても大文字・小文字を区別しない検索を行いたい場合、または明示的に区別したい場合、COLLATE句を使用できます。

• COLLATE NOCASE: 大文字・小文字を区別しない比較を行います。これはSQLiteのデフォルトLIKEと同じ動作をASCII文字に適用し、さらに多くのUnicode文字に対しても同様のケースインセンシティブな比較を試みます。
• COLLATE BINARY: 大文字・小文字を厳密に区別する（バイト列として比較する）比較を行います。

COLLATE NOCASE を使用した例（ASCIIの場合）：

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'apple%' COLLATE NOCASE;

これはデフォルトの動作と同じ結果になります。

COLLATE BINARY を使用した例（ASCIIの場合）：

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'apple%' COLLATE BINARY;

結果：

-- なし (厳密に 'apple' で始まるものを検索するため、'Apple' とは一致しない)

もし、ProductNameに「apple iPhone 13」というデータがあったとしたら、それがヒットします。

PRAGMA case_sensitive_like の紹介（非推奨だが知識として）：
SQLiteには、PRAGMA case_sensitive_like = ON;という設定がありますが、これは非常に古く、SQLite 3.6.19（2009年）以降では非推奨とされており、通常は無視されます。現代のSQLiteでは、COLLATE句を使用するのが推奨される方法です。この知識は、古い資料や環境に遭遇した場合のために知っておくと良いでしょう。

結論として、SQLiteでLIKEを使用する際は、ASCII文字はデフォルトでケースインセンシティブであること、非ASCII文字はケースセンシティブであること、そして必要に応じてCOLLATE NOCASEやCOLLATE BINARYを使って明示的に動作を制御できることを覚えておきましょう。

3. ワイルドカードの探求：%（パーセント）

%は、LIKE演算子で最も頻繁に使用されるワイルドカードです。その役割は「0文字以上の任意の文字列」を表すことです。これにより、前方一致、後方一致、部分一致といった柔軟な検索が可能になります。

3.1 %の意味：0文字以上の任意の文字列

%は、その位置にどんな文字がいくつ（0個でも良い）入っていても一致すると解釈されます。

3.2 %の使い方と具体的な例

Productsテーブルを引き続き使用します。

3.2.1 前方一致検索: pattern%

指定した文字列で始まるデータを検索します。

クエリ例：ProductNameが「Apple」で始まるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'Apple%';

結果：

“`
ProductName

---

Apple iPhone 13
Apple MacBook Air M1
“`

説明： Appleの後ろに何らかの文字列が続くすべてのProductNameを検索します。Apple自体も対象に含まれます（%は0文字以上の任意の文字列にマッチするため、Appleという文字列の後ろに何もなくてもマッチします）。

3.2.2 後方一致検索: %pattern

指定した文字列で終わるデータを検索します。

クエリ例：ProductNameが「M1」で終わるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE '%M1';

結果：

“`
ProductName

---

Apple MacBook Air M1
“`

説明： M1の前に何らかの文字列が続くすべてのProductNameを検索します。

3.2.3 部分一致検索: %pattern%

指定した文字列がどこかに含まれるデータを検索します。

クエリ例：ProductNameに「Galaxy」が含まれるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE '%Galaxy%';

結果：

“`
ProductName

---

Samsung Galaxy S22
“`

説明： ProductNameのどこかにGalaxyという文字列が含まれるものを検索します。これは最も一般的なLIKEの利用方法の一つです。

3.2.4 複数の%の組み合わせ

%は複数回使用することも可能です。これにより、より複雑なパターンを表現できます。

クエリ例：ProductNameが「S」で始まり、どこかに「Pro」が含まれるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'S%Pro%';

結果：

“`
ProductName

---

Microsoft Surface Pro 8
“`

説明： Sで始まり、その後に任意の文字列が続き、さらにProがどこかに含まれるProductNameを検索します。この例では「Samsung Galaxy S22」はSで始まるがProを含まず、「Sony WH-1000XM4」はSで始まるがProを含まず、「Microsoft Surface Pro 8」はMで始まるがSurface Proという部分文字列を持つ。あれ？ S%Pro%では「Samsung」も「Sony」もヒットしないのは正しいが、「Microsoft Surface Pro 8」もヒットしないはず。この例は適切ではない。

修正版のクエリ例：ProductNameに「Mac」と「Air」がこの順序で含まれるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE '%Mac%Air%';

結果：

“`
ProductName

---

Apple MacBook Air M1
“`

説明： ProductNameのどこかにMacという文字列があり、その後に任意の文字列が続き、さらにAirという文字列が含まれるものを検索します。

3.3 実践的な応用例：%の活用

%ワイルドカードは、実際のデータ分析やアプリケーション開発において非常に多岐にわたる用途で活用されます。

3.3.1 商品名の検索（例：特定のブランドを含む）

ユーザーが検索ボックスにキーワードを入力する際に、完全な商品名を知らなくても検索できるようにするために使われます。

sql
-- 「iPhone」というキーワードで製品を検索
SELECT ProductID, ProductName, Price
FROM Products
WHERE ProductName LIKE '%iPhone%';

3.3.2 住所の検索（例：特定の市区町村を含む）

特定の地域に住む顧客をリストアップする際に便利です。

サンプルテーブル：Customers

“`sql
CREATE TABLE Customers (
CustomerID INTEGER PRIMARY KEY,
CustomerName TEXT NOT NULL,
Address TEXT,
City TEXT,
PostalCode TEXT
);

INSERT INTO Customers (CustomerID, CustomerName, Address, City, PostalCode) VALUES
(1, ‘田中一郎’, ‘東京都渋谷区道玄坂1-1’, ‘東京都’, ‘150-0043’),
(2, ‘佐藤二郎’, ‘大阪府大阪市北区梅田2-2’, ‘大阪府’, ‘530-0001’),
(3, ‘高橋三郎’, ‘東京都港区六本木3-3’, ‘東京都’, ‘106-0032’),
(4, ‘鈴木四郎’, ‘神奈川県横浜市中区桜木町4-4’, ‘神奈川県’, ‘231-0062’);

— 「東京都」に住む顧客を検索
SELECT CustomerName, Address
FROM Customers
WHERE Address LIKE ‘東京都%’;
“`

結果：

CustomerName|Address
------------|----------------
田中一郎 |東京都渋谷区道玄坂1-1
高橋三郎 |東京都港区六本木3-3

3.3.3 メールアドレスのドメイン検索

特定のドメインからのメールアドレスを持つユーザーを抽出します。

sql
-- 「.com」ドメインのメールアドレスを持つユーザーを検索
SELECT UserID, UserName, Email
FROM Users
WHERE Email LIKE '%.com%';

結果：

UserID|UserName|Email
------|--------|------------------
1 |山田太郎|[email protected]
（Usersテーブルのデータは最初に提示したものを参照）

4. ワイルドカードの探求：_（アンダースコア）

_（アンダースコア）は、%とは異なる種類のワイルドカードです。%が「0文字以上の任意の文字列」を表すのに対し、_は「任意の1文字」を表します。この違いが、特定のパターンマッチングにおいて非常に重要になります。

4.1 _の意味：任意の1文字

_は、その位置にどんな1文字が入っていても一致すると解釈されます。ちょうど1文字である必要があり、0文字や2文字以上では一致しません。

4.2 _の使い方と具体的な例

ProductsテーブルやUsersテーブルを引き続き使用します。

4.2.1 特定のパターンに合致するが、一部が不明な場合

特定の文字数が決まっていて、そのうちの1文字だけが不明な場合などに有効です。

クエリ例：ProductNameが「S_ny」というパターンに一致するものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'S_ny%';

結果：

“`
ProductName

---

Sony WH-1000XM4
“`

説明： Sで始まり、その次に任意の1文字が来て、その後にnyが続くProductNameを検索します。_がoにマッチします。

4.2.2 桁数指定検索

_を複数個使用することで、厳密な桁数を指定した検索が可能です。

クエリ例：ProductIDが1桁で、2桁目が「A」で、3桁目が任意の文字で、その後が「-B」となるような製品コード（例：X-A_ -Bのような）を想定
現在のProductsテーブルにはそのようなデータはないので、別の例を考えます。

サンプルテーブル：ProductCodes

“`sql
CREATE TABLE ProductCodes (
CodeID INTEGER PRIMARY KEY,
ProductCode TEXT NOT NULL
);

INSERT INTO ProductCodes (CodeID, ProductCode) VALUES
(1, ‘ABC-123-X’),
(2, ‘XYZ-456-Y’),
(3, ‘LMN-789-Z’),
(4, ‘ABC-999-A’),
(5, ‘DEF-012-P’);
“`

クエリ例：ProductCodeが「ABC-___-X」というパターンに一致するものを検索（ハイフンの後に続く3文字が任意のパターン）

sql
SELECT ProductCode
FROM ProductCodes
WHERE ProductCode LIKE 'ABC-___-X';

結果：

“`
ProductCode

---

ABC-123-X
“`

説明： ABC-で始まり、その後に任意の3文字が続き、最後に-Xが続くProductCodeを検索します。

4.2.3 前方・後方・部分一致と組み合わせた例

_と%は組み合わせて使用することで、さらに柔軟なパターンを表現できます。

クエリ例：ProductNameが「S」で始まり、2文字目が任意で、どこかに「Quiet」が含まれるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'S_%Quiet%';

結果：

“`
ProductName

---

Bose QuietComfort Earbuds
“`

説明： Sで始まり、その次に任意の1文字が来て、その後どこかにQuietが含まれるProductNameを検索します。この例では、Bose QuietComfort EarbudsはSで始まらないためヒットしません。これは私の例が悪かった。

修正版のクエリ例：ProductNameが「_o__」というパターンを含むものを検索（2文字目がoで、4文字の単語）

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE '%_o__%';

結果：

“`
ProductName

---

Sony WH-1000XM4
Logitech MX Master 3
Bose QuietComfort Earbuds
Google Pixel 6
Canon EOS R5
“`

説明： ProductNameのどこかに、任意の1文字、その次にo、さらに任意の2文字が続くパターン（合計4文字）が含まれるものを検索します。例えば、「Sony」のo、Logitechのo、Boseのo、Googleのo、Canon EOSのoがマッチします。

4.3 実践的な応用例：_の活用

4.3.1 製品コードの検索（例：ABC-X-YZ）

特定のフォーマットを持つが、一部の桁が不明または変動する製品コードの検索。

サンプルデータ
ProductCodesテーブルを使用。

“`sql
— ProductCodeが「ABC-X__-Y」のような形式のものを検索 (Xは任意、Yは任意の2文字)
SELECT ProductCode
FROM ProductCodes
WHERE ProductCode LIKE ‘ABC-___-Y’; — このパターンではProductCodesにはヒットしない。

— より適切な例: ProductCodeが「–-X」のような形式で、最後の文字が「X」のものを検索
SELECT ProductCode
FROM ProductCodes
WHERE ProductCode LIKE ‘–-X’;
“`

結果：

“`
ProductCode

---

ABC-123-X
“`

説明： 最初の3文字が任意、ハイフン、次の3文字が任意、ハイフン、最後の1文字がXであるProductCodeを検索します。

4.3.2 短い単語のバリエーション検索

スペルミスが許容される検索や、特定の形式を持つ短い単語の検索に利用できます。

サンプルテーブル：Words

“`sql
CREATE TABLE Words (
WordID INTEGER PRIMARY KEY,
Word TEXT NOT NULL
);

INSERT INTO Words (WordID, Word) VALUES
(1, ‘apple’),
(2, ‘aple’),
(3, ‘apply’),
(4, ‘apool’),
(5, ‘banana’);

— 「a_pl_」のように、2文字目と5文字目が任意の単語を検索
SELECT Word
FROM Words
WHERE Word LIKE ‘a_pl_’;
“`

結果：

“`
Word

---

apple
aple
apply
apool
``
（apleは5文字ではないのでヒットしないはず。a_pl_は5文字のパターンなので、apleは4文字なのでヒットしない。appleは5文字、applyは5文字、apoolは5文字なのでヒット。）
**修正：**apleは4文字なので、a_pl_という5文字のパターンにはマッチしません。結果からaple`は除外されます。

4.3.3 電話番号の特定部分検索

特定のパターンを持つ電話番号を抽出する際に便利です。

サンプルテーブル：Contacts

“`sql
CREATE TABLE Contacts (
ContactID INTEGER PRIMARY KEY,
Name TEXT NOT NULL,
PhoneNumber TEXT
);

INSERT INTO Contacts (ContactID, Name, PhoneNumber) VALUES
(1, ‘Alice’, ‘090-1234-5678’),
(2, ‘Bob’, ‘080-9876-5432’),
(3, ‘Charlie’, ‘070-1111-2222’),
(4, ‘David’, ‘090-5555-9999’);

— 電話番号の4桁目が「1」であるものを検索 (例: xxx-1xxx-xxxx)
SELECT Name, PhoneNumber
FROM Contacts
WHERE PhoneNumber LIKE ‘___-1%’;
“`

結果：

Name |PhoneNumber
-------|------------
Charlie|070-1111-2222

説明： 最初の3文字が任意、ハイフン、そして4文字目が1であるすべての電話番号を検索します。

5. LIKE演算子の高度なテクニックと応用

これまでに基本的なワイルドカードの活用法を見てきましたが、LIKE演算子はさらに柔軟な検索を可能にするためのいくつかの追加機能と、他のSQL句との組み合わせによって、より強力なツールとなります。

5.1 NOT LIKE

NOT LIKEは、LIKE演算子と逆の動作をします。つまり、指定したパターンに一致しないデータを検索するために使用されます。

5.1.1 NOT LIKEの構文と意味

構文はLIKEと同様ですが、NOTキーワードが前置されます。

sql
SELECT column_name(s)
FROM table_name
WHERE column_name NOT LIKE pattern;

意味： column_nameの値がpatternに合致しないレコードを返します。

5.1.2 特定のパターンに一致しないデータを抽出する方法

Productsテーブルを使用します。

クエリ例：ProductNameが「Apple」で始まらないすべての製品を検索

sql
SELECT ProductName
FROM Products
WHERE ProductName NOT LIKE 'Apple%';

結果：

“`
ProductName

---

Samsung Galaxy S22
Sony WH-1000XM4
Logitech MX Master 3
Bose QuietComfort Earbuds
Google Pixel 6
Dell XPS 13
Microsoft Surface Pro 8
Canon EOS R5
“`

説明： Appleで始まるProductNameを除外したすべての製品がリストされます。

5.1.3 応用例：特定のキーワードを含まない、特定の形式でないデータ

• 特定のキーワードを含まないレコードの抽出：
  sql
-- Descriptionに「スマートフォン」という単語が含まれない製品を検索
SELECT ProductName, Description
FROM Products
WHERE Description NOT LIKE '%スマートフォン%';

• 特定の形式でないメールアドレスの抽出（データクレンジングに有用）：
  例えば、メールアドレスが「@」を含まない、または「.」を含まないなど、不完全なデータを特定する場合。

  sql
-- Usersテーブルを使用
-- @と.comの形式ではないメールアドレスを検索
SELECT UserName, Email
FROM Users
WHERE Email NOT LIKE '%@%.com%';
  結果：
  Emailカラムにdomain.netを持つ「佐藤健太」がヒットする。

5.2 エスケープ文字の利用

ワイルドカード文字そのもの（%や_）を検索したい場合、LIKE演算子はその文字をワイルドカードとして解釈してしまいます。これを回避するためには、エスケープ文字を使用し、ワイルドカード文字を通常の文字として扱うように指定する必要があります。

5.2.1 ワイルドカード文字そのもの（%や_）を検索する方法

例えば、製品名が「100% Cotton」のような文字列を含む場合、'%100%%'とすると「100」の後に任意の文字列が続くものと解釈されてしまいます。%を文字として検索するためには、特別な指示が必要です。

5.2.2 ESCAPEキーワードの構文と使用例

ESCAPEキーワードを使用すると、エスケープ文字を定義し、そのエスケープ文字が直前にあるワイルドカード文字を通常の文字として扱わせることができます。

構文は以下の通りです。

sql
SELECT column_name(s)
FROM table_name
WHERE column_name LIKE pattern ESCAPE escape_character;

• escape_character: エスケープ文字として使用する任意の1文字を指定します。一般的には、バックスラッシュ（\）がよく使われますが、他の文字（例：#, $など）も使用できます。

例：ProductNameに「%」文字が含まれるものを検索

サンプルテーブル：Items

“`sql
CREATE TABLE Items (
ItemID INTEGER PRIMARY KEY,
ItemName TEXT NOT NULL
);

INSERT INTO Items (ItemID, ItemName) VALUES
(1, ‘Pure Cotton 100%’),
(2, ‘Discount 50% Off’),
(3, ‘Secret Item‘),
(4, ‘Normal Product’);
“`

クエリ例：ItemNameにパーセント記号（%）が含まれるものを検索

sql
SELECT ItemName
FROM Items
WHERE ItemName LIKE '%50\%%' ESCAPE '\';

結果：

“`
ItemName

---

Discount 50% Off
“`

説明：
* LIKE '%50\%%'：パターン文字列です。
* \：エスケープ文字として指定されたバックスラッシュです。
* \%：バックスラッシュの直後にある%はワイルドカードではなく、通常のパーセント文字として解釈されます。
* 最初の%と最後の%はワイルドカードとして機能し、50%がどこかに含まれる文字列を検索します。

5.2.3 ワイルドカード文字そのもの（_）を検索する例

クエリ例：ItemNameにアンダースコア（_）文字が含まれるものを検索

sql
SELECT ItemName
FROM Items
WHERE ItemName LIKE '%\_Secret\_Item\__%' ESCAPE '\';

結果：

“`
ItemName

---

Secret Item
“`

説明： \に続く_が通常のアンダースコア文字として解釈されます。

5.2.4 エスケープ文字を選ぶ際の注意点

• パターン文字列に含まれない文字を選ぶ： エスケープ文字として選んだ文字が、パターン文字列や検索対象のデータ中に通常の文字として現れると、予期せぬ結果を招く可能性があります。例えば、#をエスケープ文字に選び、検索対象の文字列にも#がある場合、混乱が生じる可能性があります。そのため、バックスラッシュ（\）のように、データ中に頻繁に現れない文字を選ぶのが一般的です。
• 一貫性： 複数のクエリでエスケープ文字を使用する場合、一貫した文字を使用することをお勧めします。

5.3 複数のLIKE条件の組み合わせ

SQLでは、AND、OR、NOTなどの論理演算子を使用して、複数の条件を組み合わせることができます。これはLIKE演算子にも適用され、より複雑なデータ抽出のニーズに対応できます。

5.3.1 ANDを使った複数条件の結合

すべての条件が真である場合にレコードを返します。

クエリ例：ProductNameに「Apple」が含まれ、かつ「iPhone」も含まれるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE '%Apple%' AND ProductName LIKE '%iPhone%';

結果：

“`
ProductName

---

Apple iPhone 13
“`

5.3.2 ORを使った複数条件の結合

いずれかの条件が真である場合にレコードを返します。

クエリ例：ProductNameが「Apple」で始まるか、「Samsung」で始まるものを検索

sql
SELECT ProductName
FROM Products
WHERE ProductName LIKE 'Apple%' OR ProductName LIKE 'Samsung%';

結果：

“`
ProductName

---

Apple iPhone 13
Samsung Galaxy S22
Apple MacBook Air M1
“`

5.3.3 IN と LIKE の使い分け

• IN演算子： 特定の値のリストと完全に一致するものを検索する場合に最適です。値は固定で、ワイルドカードは使えません。
  例: WHERE Category IN ('スマートフォン', 'ノートPC')

• LIKE演算子： ワイルドカードを使用して部分一致検索を行う場合に最適です。

INとLIKEを組み合わせて使うことはできませんが、複数のLIKE条件をORで繋ぐことで、INに近い柔軟なパターンマッチングを実現できます。

sql
-- Categoryが「スマ」で始まるか、「ノー」で始まるものを検索（LIKEのOR結合）
SELECT ProductName, Category
FROM Products
WHERE Category LIKE 'スマ%' OR Category LIKE 'ノー%';

結果：

ProductName |Category
----------------------|------------
Apple iPhone 13 |スマートフォン
Samsung Galaxy S22 |スマートフォン
Apple MacBook Air M1 |ノートPC
Google Pixel 6 |スマートフォン
Dell XPS 13 |ノートPC
Microsoft Surface Pro 8|ノートPC

5.3.4 複合的な検索クエリの構築

AND, OR, NOTとLIKEを組み合わせることで、非常に具体的な条件を持つクエリを作成できます。括弧を使って条件の優先順位を明確にすることが重要です。

クエリ例：
* ProductNameが「Apple」で始まるが「MacBook」は含まない、または「Sony」で始まる製品を検索

sql
SELECT ProductName
FROM Products
WHERE (ProductName LIKE 'Apple%' AND ProductName NOT LIKE '%MacBook%')
OR ProductName LIKE 'Sony%';

結果：

“`
ProductName

---

Apple iPhone 13
Sony WH-1000XM4
“`

説明：
1. ProductName LIKE 'Apple%' AND ProductName NOT LIKE '%MacBook%': 「Apple」で始まるが「MacBook」を含まない製品 (Apple iPhone 13が該当)。
2. OR ProductName LIKE 'Sony%': または「Sony」で始まる製品 (Sony WH-1000XM4が該当)。
これらの条件のいずれかが真であればレコードが抽出されます。

6. LIKE演算子のパフォーマンスと最適化

LIKE演算子、特にワイルドカードを使用する検索は、データベースのパフォーマンスに大きな影響を与える可能性があります。適切に利用しないと、大量のデータを扱う際にクエリの実行が遅くなる原因となります。

6.1 インデックスの役割

データベースインデックスは、書籍の索引のようなもので、データ検索の速度を大幅に向上させるために使用されます。特定のカラムにインデックスを作成すると、データベースはそのカラムの値に基づいてソートされたリスト（またはツリー構造）を内部的に保持し、検索時にすべての行をスキャンする代わりに、インデックスを効率的に辿って目的のデータを見つけることができます。

6.2 LIKEとインデックス：前方一致は利用可能、後方・部分一致は利用しにくい理由

LIKE演算子とインデックスの関係は、ワイルドカードの位置によって大きく異なります。

• 前方一致検索 (pattern%)：インデックスを利用可能

  • 例: WHERE ProductName LIKE 'Apple%'
  • この場合、ProductNameカラムにインデックスが作成されていれば、データベースはそのインデックスの順序を利用して「Apple」で始まる最初のレコードを探し、そこから順に読み進めることができます。これは非常に効率的です。インデックスがアルファベット順に並んでいるため、指定されたプレフィックス（前方部分）と一致するエントリを高速に見つけることができるためです。

• 後方一致検索 (%pattern)：インデックスを利用しにくい

  • 例: WHERE ProductName LIKE '%M1'
  • データベースはM1で終わるすべての文字列を探すために、文字列全体をスキャンする必要があります。インデックスは通常、文字列の先頭から順にソートされているため、文字列の末尾だけを頼りにインデックスを効率的に利用することは困難です。結果として、フルテーブルスキャン（テーブル内のすべての行を最初から最後までチェックする）が発生し、パフォーマンスが低下します。

• 部分一致検索 (%pattern%)：インデックスを利用できない

  • 例: WHERE ProductName LIKE '%Galaxy%'
  • この場合、検索パターンが文字列のどの位置に現れるか不明なため、インデックスは全く利用できません。データベースは結局、すべてのレコードのProductNameカラムを一つずつチェックするしかなく、必ずフルテーブルスキャンが発生します。

6.3 pattern% と WHERE col >= 'pattern' AND col < 'pattern~' の比較

前方一致検索を行う場合、LIKE 'pattern%' は、多くの場合、WHERE col >= 'pattern' AND col < 'pattern~' (PostgreSQLなど一部のDBで利用される技法) と同等の効率を持ちます。
SQLiteでは、通常のLIKE 'pattern%' クエリがすでに前方一致を効率的に処理するように最適化されていますので、この代替構文を特に意識する必要はありません。

ただし、インデックスが利用できない後方一致や部分一致のLIKEクエリは、大量データでは問題となります。

6.4 大量データにおけるLIKEの考慮事項

• フルテーブルスキャン： %patternや%pattern%のように、ワイルドカードがパターンの先頭にある場合、インデックスが使用されず、データベースはテーブル内のすべてのレコードをスキャンします。テーブルのサイズが大きくなるほど、このスキャンにかかる時間は長くなり、パフォーマンスは著しく低下します。
• CPU負荷： 文字列のマッチングはCPUを消費する操作です。大量のデータに対して部分一致検索を行うと、CPUの負荷が高まります。

6.5 代替手段の検討（全文検索機能 FTS5、正規表現 REGEXP）

LIKE演算子のパフォーマンスが問題となる場合、以下の代替手段を検討できます。

• 全文検索機能 (Full-Text Search – FTS)：

  • SQLiteにはFTS5という組み込みの全文検索モジュールがあります。これは、テキストデータの中からキーワードを効率的に検索するために特化しており、インデックス作成やランキング、フレーズ検索など、高度な検索機能を提供します。
  • FTS5は、LIKE '%pattern%'のような部分一致検索がボトルネックになる場合に非常に強力な解決策となります。大量のドキュメントや長いテキストフィールドからの検索に適しています。
  • FTS5テーブルを作成し、検索対象のテキストをそこに挿入することで、高速な全文検索が可能になります。

  FTS5の簡単な例：
  “`sql
  — FTS5テーブルの作成
  CREATE VIRTUAL TABLE ProductDescriptions USING fts5(ProductName, Description);

  — データの挿入（既存のProductsテーブルから）
  INSERT INTO ProductDescriptions (rowid, ProductName, Description)
  SELECT ProductID, ProductName, Description FROM Products;

  — 全文検索
  SELECT ProductID, ProductName, Description
  FROM ProductDescriptions
  WHERE ProductDescriptions MATCH ‘スマートフォン’; — MATCH演算子を使用
  ``
これはDescription LIKE ‘%スマートフォン%’`よりもはるかに高速です。

• 正規表現 (REGEXP)：

  • SQL標準にはREGEXP演算子は含まれていませんが、多くのデータベースシステム（MySQL、PostgreSQLなど）がこれをサポートしています。
  • SQLiteは、デフォルトではREGEXP関数を提供していません。しかし、カスタム関数としてREGEXPをC言語などで実装し、SQLiteに組み込むことで利用可能になります。これは高度なプログラミング知識が必要です。
  • 正規表現はLIKEよりもはるかに複雑なパターンマッチングが可能ですが、一般的にLIKEよりもパフォーマンスは劣ります（特にインデックスが使えない場合）。

まとめ：
LIKE演算子は非常に便利ですが、そのパフォーマンス特性、特にワイルドカードの位置を理解することが重要です。前方一致は効率的ですが、後方一致や部分一致はフルテーブルスキャンを引き起こし、大量データではボトルネックとなります。そのような場合は、FTS5のような専用の全文検索ソリューションの導入を検討すべきです。

7. 実践的なシナリオと応用例（総合演習）

これまでに学んだLIKE演算子、ワイルドカード、NOT LIKE、ESCAPE、そして論理演算子の組み合わせを使い、実際のデータ抽出シナリオを想定した総合的な演習を行います。

使用するサンプルデータ：Customersテーブル

“`sql
CREATE TABLE Customers (
CustomerID INTEGER PRIMARY KEY,
CustomerName TEXT NOT NULL,
Email TEXT,
Phone TEXT,
Address TEXT,
RegistrationDate TEXT
);

INSERT INTO Customers (CustomerID, CustomerName, Email, Phone, Address, RegistrationDate) VALUES
(1, ‘山田太郎’, ‘[email protected]’, ‘090-1234-5678’, ‘東京都渋谷区道玄坂1-1’, ‘2023-01-15’),
(2, ‘鈴木花子’, ‘[email protected]’, ‘080-9876-5432’, ‘大阪府大阪市北区梅田2-2’, ‘2023-02-20’),
(3, ‘佐藤健太’, ‘[email protected]’, ‘070-1111-2222’, ‘東京都新宿区西新宿3-3’, ‘2023-03-05’),
(4, ‘田中一郎’, ‘[email protected]’, ‘090-5555-9999’, ‘神奈川県横浜市中区桜木町4-4’, ‘2023-04-10’),
(5, ‘高橋明美’, ‘[email protected]’, ‘080-2222-3333’, ‘東京都世田谷区玉川5-5’, ‘2023-05-25’),
(6, ‘中村純一’, ‘[email protected]’, ‘070-4444-5555’, ‘福岡県福岡市博多区6-6’, ‘2023-06-01’),
(7, ‘小林由美’, ‘[email protected]’, ‘090-6666-7777’, ‘東京都練馬区桜台7-7’, ‘2023-07-12’),
(8, ‘加藤正樹’, ‘[email protected]’, ‘080-7777-8888’, ‘愛知県名古屋市中村区8-8’, ‘2023-08-01’),
(9, ‘木村大輔’, ‘[email protected]’, ‘070-8888-9999’, ‘北海道札幌市中央区9-9’, ‘2023-09-05’),
(10, ‘斉藤美咲’, ‘[email protected]’, ‘090-3333-1111’, ‘東京都千代田区10-10’, ‘2023-10-18’);
“`

7.1 ECサイトの顧客検索

ユーザーが入力したキーワードに基づいて顧客を検索します。

シナリオ：
1. 顧客名に「田」が含まれる人
2. メールアドレスが「.com」で終わる人
3. 電話番号の市外局番が「090」または「080」の人

“`sql
— 顧客名に「田」が含まれる人を検索
SELECT CustomerName, Email
FROM Customers
WHERE CustomerName LIKE ‘%田%’;

— 結果:
— 山田太郎
— 田中一郎

— メールアドレスが「.com」で終わる人を検索 (COLLATE NOCASEで大文字小文字を無視)
SELECT CustomerName, Email
FROM Customers
WHERE Email LIKE ‘%.com’ COLLATE NOCASE;

— 結果:
— 山田太郎
— 田中一郎
— 加藤正樹
— 斉藤美咲

— 電話番号の市外局番が「090」または「080」の人を検索
SELECT CustomerName, Phone
FROM Customers
WHERE Phone LIKE ‘090-%’ OR Phone LIKE ‘080-%’;

— 結果:
— 山田太郎|090-1234-5678
— 鈴木花子|080-9876-5432
— 田中一郎|090-5555-9999
— 高橋明美|080-2222-3333
— 加藤正樹|080-7777-8888
— 小林由美|090-6666-7777
— 斉藤美咲|090-3333-1111
“`

7.2 顧客情報のクレンジング（データの不整合な名前、住所のパターン特定）

データ入力の誤りや不整合なパターンを特定します。

シナリオ：
1. 名前の途中にアンダースコア（_）が含まれる顧客（例: takaha_s）
2. 住所に「渋谷」という単語が含まれるが、「東京都」ではない顧客（ありえないデータ）
3. メールアドレスに@が2つ以上含まれる不正な形式

“`sql
— 名前の途中にアンダースコア（_）が含まれる顧客を検索 (ESCAPEを使用)
SELECT CustomerName, Email
FROM Customers
WHERE CustomerName LIKE ‘%_%’ ESCAPE ‘\’;

— 結果:
— 高橋明美|[email protected]

— 住所に「渋谷」が含まれるが、「東京都」ではない顧客 (ANDとNOT LIKE)
SELECT CustomerName, Address
FROM Customers
WHERE Address LIKE ‘%渋谷%’ AND Address NOT LIKE ‘東京都%’;

— 結果:
— (なし) – 想定通り、このデータセットでは該当なし。

— メールアドレスに@が2つ以上含まれる不正な形式 (複雑なLIKEパターン)
— たとえば、user@[email protected] のような形式を想定
— WHERE Email LIKE ‘%@%@%’ (最初に@、次に任意の文字、次に@、次に任意の文字)
SELECT CustomerName, Email
FROM Customers
WHERE Email LIKE ‘%@%@%’;

— 結果:
— (なし) – 想定通り、このデータセットでは該当なし。
— （もし不正なデータがあればここに表示される）
“`

7.3 ログデータの分析（特定のエラーメッセージ、ユーザーエージェントの特定）

ログデータから特定のイベントやパターンを抽出します。

サンプルテーブル：SystemLogs

“`sql
CREATE TABLE SystemLogs (
LogID INTEGER PRIMARY KEY,
Timestamp TEXT NOT NULL,
LogLevel TEXT,
Message TEXT
);

INSERT INTO SystemLogs (LogID, Timestamp, LogLevel, Message) VALUES
(1, ‘2023-11-01 10:00:00’, ‘INFO’, ‘User logged in: user123’),
(2, ‘2023-11-01 10:05:10’, ‘ERROR’, ‘Failed to connect to DB: Network error’),
(3, ‘2023-11-01 10:10:20’, ‘WARN’, ‘Disk space low: 10% remaining’),
(4, ‘2023-11-01 10:15:30’, ‘INFO’, ‘User logged out: user123’),
(5, ‘2023-11-01 10:20:40’, ‘ERROR’, ‘Authentication failed for user: admin_user’),
(6, ‘2023-11-01 10:25:50’, ‘INFO’, ‘Application started successfully’),
(7, ‘2023-11-01 10:30:00’, ‘ERROR’, ‘DB connection pool exhausted’);
“`

シナリオ：
1. エラーメッセージで「DB」または「Disk」を含むログ
2. 「User」で始まるメッセージのログ（ログイン/ログアウトを区別せずに）
3. 特定のタイムスタンプパターンに合致するログ（例：10時台のログ）

“`sql
— エラーメッセージで「DB」または「Disk」を含むログを検索
SELECT Timestamp, LogLevel, Message
FROM SystemLogs
WHERE LogLevel = ‘ERROR’ AND (Message LIKE ‘%DB%’ OR Message LIKE ‘%Disk%’);

— 結果:
— 2023-11-01 10:05:10|ERROR|Failed to connect to DB: Network error
— 2023-11-01 10:30:00|ERROR|DB connection pool exhausted

— 「User」で始まるメッセージのログを検索
SELECT Timestamp, LogLevel, Message
FROM SystemLogs
WHERE Message LIKE ‘User%’;

— 結果:
— 2023-11-01 10:00:00|INFO|User logged in: user123
— 2023-11-01 10:15:30|INFO|User logged out: user123

— 特定のタイムスタンプパターンに合致するログ（例：10時台のログ）
SELECT Timestamp, LogLevel, Message
FROM SystemLogs
WHERE Timestamp LIKE ‘% 10:__:%’; — 年月日 時:分:秒の「時」が10であるもの

— 結果:
— 2023-11-01 10:00:00|INFO|User logged in: user123
— 2023-11-01 10:05:10|ERROR|Failed to connect to DB: Network error
— 2023-11-01 10:10:20|WARN|Disk space low: 10% remaining
— 2023-11-01 10:15:30|INFO|User logged out: user123
— 2023-11-01 10:20:40|ERROR|Authentication failed for user: admin_user
— 2023-11-01 10:25:50|INFO|Application started successfully
— 2023-11-01 10:30:00|ERROR|DB connection pool exhausted
“`

7.4 ブログ記事のキーワード検索

ブログ記事のタイトルや本文から関連するキーワードを検索します。

サンプルテーブル：BlogPosts

“`sql
CREATE TABLE BlogPosts (
PostID INTEGER PRIMARY KEY,
Title TEXT NOT NULL,
Content TEXT,
Author TEXT,
PublishDate TEXT
);

INSERT INTO BlogPosts (PostID, Title, Content, Author, PublishDate) VALUES
(1, ‘SQLite入門：データベースの基本’, ‘この記事では、SQLiteの基本的な使い方とデータベースの概念について解説します。初心者向けの内容です。’, ‘山田’, ‘2023-10-01’),
(2, ‘SQLパフォーマンスチューニングの秘訣’, ‘大量データにおけるSQLクエリの最適化方法について深く掘り下げます。インデックスやキャッシュの活用法。’, ‘鈴木’, ‘2023-10-15’),
(3, ‘Pythonで始めるデータ分析’, ‘Pythonを使ったデータ分析の基礎から応用まで。PandasやNumPyライブラリの紹介。’, ‘田中’, ‘2023-11-01’),
(4, ‘LIKE演算子のワイルドカード活用’, ‘SQLのLIKE演算子とワイルドカード（%と_）の使い方を詳細に説明します。データ抽出の柔軟性を高めます。’, ‘山田’, ‘2023-11-10’),
(5, ‘Web開発におけるセキュリティ対策’, ‘Webアプリケーションのセキュリティを高めるための基本的な対策と注意点。OWASP Top 10など。’, ‘佐藤’, ‘2023-11-20’),
(6, ‘データベース設計のベストプラクティス’, ‘効率的でスケーラブルなデータベースを設計するためのガイドラインとヒント。’, ‘鈴木’, ‘2023-12-05’);
“`

シナリオ：
1. タイトルに「SQL」または「SQLite」が含まれる記事
2. 本文に「データベース」が含まれるが、タイトルには含まれない記事
3. 「2023-11」に公開された記事で、「データ」というキーワードを含むもの

“`sql
— タイトルに「SQL」または「SQLite」が含まれる記事を検索
SELECT Title, Author
FROM BlogPosts
WHERE Title LIKE ‘%SQL%’ OR Title LIKE ‘%SQLite%’;

— 結果:
— SQLite入門：データベースの基本|山田
— SQLパフォーマンスチューニングの秘訣|鈴木
— LIKE演算子のワイルドカード活用|山田

— 本文に「データベース」が含まれるが、タイトルには含まれない記事を検索
SELECT Title, Author
FROM BlogPosts
WHERE Content LIKE ‘%データベース%’ AND Title NOT LIKE ‘%データベース%’;

— 結果:
— SQLパフォーマンスチューニングの秘訣|鈴木
— データベース設計のベストプラクティス|鈴木

— 「2023-11」に公開された記事で、「データ」というキーワードを含むもの
SELECT Title, PublishDate
FROM BlogPosts
WHERE PublishDate LIKE ‘2023-11%’ AND (Title LIKE ‘%データ%’ OR Content LIKE ‘%データ%’);

— 結果:
— Pythonで始めるデータ分析|2023-11-01
— LIKE演算子のワイルドカード活用|2023-11-10
“`

これらの演習を通じて、LIKE演算子がいかに多様なデータ抽出ニーズに対応できるか、そして他のSQL句と組み合わせることでその能力を最大限に引き出せるかを理解できたことでしょう。

8. SQLiteとLIKE演算子の特性まとめ

本記事で解説してきたSQLiteのLIKE演算子とそのワイルドカードは、非常に強力で柔軟なデータ抽出ツールです。最後に、SQLiteにおけるLIKEの主要な特性をまとめ、他のデータベースシステムとの互換性についても触れておきましょう。

8.1 大文字小文字の扱い（COLLATE NOCASEの重要性）

• ASCII文字: SQLiteのLIKEは、ASCII文字（a-z, A-Z）に対してはデフォルトで大文字・小文字を区別しません（ケースインセンシティブ）。これは、'apple' LIKE 'Apple'が真となることを意味します。
• 非ASCII文字（Unicodeなど）: 日本語などの非ASCII文字に対しては、デフォルトで大文字・小文字を区別します（ケースセンシティブ）。例えば、'ノイズ' LIKE 'のいず'は偽となります。
• 明示的な制御: 必要に応じてCOLLATE NOCASEを使用して明示的に大文字・小文字を区別しない検索を行ったり、COLLATE BINARYを使用して厳密な区別を行うことができます。特に非ASCII文字のケースインセンシティブな検索が必要な場合はCOLLATE NOCASEが不可欠です。

8.2 パフォーマンスの注意点

• ワイルドカードの位置：
  • pattern%（前方一致）：インデックスを利用できるため高速です。
  • %pattern（後方一致）：インデックスを利用しにくい、フルテーブルスキャンになりがちです。
  • %pattern%（部分一致）：インデックスを利用できず、必ずフルテーブルスキャンになります。
• 大量データ： 後方一致や部分一致のLIKEクエリは、データ量が膨大になると顕著にパフォーマンスが低下します。
• 代替手段： パフォーマンスが重要な場合は、SQLiteのFTS5（全文検索）モジュールを検討することが強く推奨されます。カスタムのREGEXP関数を組み込むことも可能ですが、より技術的な難易度が高くなります。

8.3 他のデータベースシステムとの互換性（MySQL, PostgreSQL, SQL Serverなど）

LIKE演算子とワイルドカード（%と_）は、SQLの標準的な機能であり、ほとんどすべての主要なリレーショナルデータベースシステムで共通して使用できます。しかし、細部にはいくつかの違いがあります。

• 大文字・小文字の扱い： SQLiteはASCII文字でデフォルトでケースインセンシティブですが、他のDBではデフォルトの動作が異なる場合があります。
  • MySQL: デフォルトでケースインセンシティブ（ただし、COLLATE設定による）。
  • PostgreSQL: デフォルトでケースセンシティブ（ILIKEを使用するとケースインセンシティブ検索が可能）。
  • SQL Server: デフォルトでケースインセンシティブ（ただし、COLLATE設定による）。
    データベースのデフォルト設定やカラムの照合順序（Collation）によって動作が変わるため、異なるDB環境でSQLを実行する際は注意が必要です。
• エスケープ文字： ESCAPEキーワードの機能は共通していますが、デフォルトのエスケープ文字はシステムによって異なる場合がある（例: MySQLではデフォルトで\、PostgreSQLではデフォルトのエスケープ文字はないが明示すれば使える）。
• REGEXPのサポート： SQLiteはデフォルトでREGEXPをサポートしていませんが、MySQLやPostgreSQLは標準でサポートしています。

これらの違いがあるため、SQLクエリをあるデータベースシステムから別のシステムへ移行する際には、特にLIKE演算子や文字列比較に関する部分でテストを行うことが重要です。

まとめと次のステップ

本記事では、「SQLite LIKE入門：ワイルドカードを活用したデータ抽出」と題し、約5000語にわたる詳細な解説を行いました。

• まず、データ抽出の重要性からSQLの基本的なSELECT文、そして従来の比較演算子の限界に触れ、LIKE演算子の必要性を導入しました。
• 次に、LIKE演算子の基本的な構文と、SQLite特有の大文字・小文字の区別について深く掘り下げました。
• 記事の核心として、二つの主要なワイルドカードである%（0文字以上の任意の文字列）と_（任意の1文字）について、それぞれ豊富な具体例を交えながらその意味と使い方を徹底的に探求しました。前方一致、後方一致、部分一致、桁数指定など、様々なパターンマッチングの可能性を提示しました。
• さらに、NOT LIKEによるパターンに一致しないデータの抽出、ESCAPEキーワードを使ったワイルドカード文字そのものの検索、そしてAND/ORを用いた複数条件の組み合わせといった高度なテクニックを解説しました。
• パフォーマンスに関する重要な考慮事項として、インデックスがLIKEクエリでどのように機能するか（またはしないか）を説明し、大量データに対する代替手段としてSQLiteのFTS5全文検索機能に言及しました。
• 最後に、実践的なシナリオとして、ECサイトの顧客検索、データクレンジング、ログ分析、ブログ記事検索といった具体的な応用例を通じて、学んだ知識を統合的に活用する方法を示しました。

LIKE演算子は、SQLにおける文字列検索の最も強力で柔軟なツールの一つです。ワイルドカードを使いこなすことで、あいまいなデータ、不完全なデータ、あるいは特定のパターンを持つデータを効率的に見つけ出すことができます。これは、日々のデータ分析、アプリケーション開発、データクレンジングなど、あらゆる場面であなたの生産性を飛躍的に向上させるでしょう。

これで、あなたはSQLiteにおけるLIKE演算子とワイルドカードの活用について、包括的な知識と実践的なスキルを習得したはずです。しかし、データベースの世界は奥深く、学ぶべきことはまだたくさんあります。

次のステップとして、以下のようなトピックを学ぶことをお勧めします：

• FTS5のさらに詳細な学習： 大量のテキストデータを扱う場合は必須のスキルです。
• 正規表現（REGEXP）： より複雑な文字列パターンマッチングが必要な場合に検討します。
• サブクエリとJOIN： 複数のテーブルを結合して複雑な情報を抽出するスキルです。
• 集計関数とGROUP BY： データの集計や統計を行うために不可欠です。
• データベース設計の原則： 効率的で管理しやすいデータベースを構築するための知識です。

これらのスキルを身につけることで、あなたはSQLの真の力を解き放ち、どんなデータ課題にも自信を持って取り組むことができるようになるでしょう。データとの対話を楽しんでください！