回答

テキストデータを扱う際には、さまざまな言語やアルファベットのサポートが必要です。これを実現するために、SQLでは並べ替えルール— COLLATION が使用されます。COLLATIONは、文字列がどのように比較され、ソートされるかを定義します。言語の特性に応じてCOLLATIONを列、テーブル、またはクエリのレベルで正しく指定することが重要です（例：ё ≠ е）。

例:

SELECT * FROM users
ORDER BY username COLLATE 'ru_RU.UTF8';

このクエリは、ユーザーをロシアのアルファベットに従ってソートします。異なるDBMSでは、COLLATEの構文が異なる場合があります。

• MySQLの場合： COLLATE utf8mb4_unicode_ci または utf8mb4_ru_0900_as_cs は大文字と小文字を区別し、言語を考慮します。
• MSSQLの場合： COLLATE Cyrillic_General_CS_AS — ロシア語のサポート、大文字小文字の違い（CS = 大文字と小文字を区別、AS = アクセントを区別）。

重要: COLLATIONは検索（LIKE、比較）にも影響するため、ソートだけではありません！

トリッキーな質問

同じクエリで異なるCOLLATIONを持つ文字列をソートする際の問題は何ですか？明示的な変換なしで、異なる並べ替え順序のデータを集約できますか？

エラー：COLLATIONが異なる場合（たとえば、一方の列はutf8mb4_unicode_ci、他方はutf8mb4_bin）のときに、UNIONを試みたり、直接比較したりすると、COLLATIONの不一致エラーが発生します。

正しい方法：常に文字列を統一されたCOLLATIONに変換し、COLLATE構文を使用してください。

SELECT name COLLATE 'utf8mb4_unicode_ci' FROM customers
UNION
SELECT name COLLATE 'utf8mb4_unicode_ci' FROM suppliers;

このテーマの詳細を知らないが故の実際のエラーの例

---

物語 1

大規模なeコマースプラットフォームで、ロシア語の顧客リストをExcelにエクスポートする際、名前が'Ё'で始まるユーザーがリストの最後に表示され、'Е'で始まるユーザーが最初に表示されることに気づきました。原因はCOLLATIONの違いで、標準のラテン式が使用されており、ロシアのアルファベット順に沿った並べ替えになっていませんでした。ユーザーは明確でない並べ替えについて不満を持っていました。

---

物語 2

医療システムでは、異なるテーブルに異なるCOLLATION（デフォルトおよび明示的にロシア語指定）が含まれていました。テーブルスキーマを変更した後、集計レポートが機能しなくなり、クエリは「COLLATION conflict」と表示されるようになりました。サポートチームは、何百ものクエリで明示的にCOLLATEを指定しなければなりませんでした。

---

物語 3

姓での検索APIは、大文字と小文字の書き方が正確である必要がありました（case sensitive）が、ユーザーはケースに対して無関心であることを期待していました。調べてみると、列はCOLLATION _CSで作成されており、検索が大文字と小文字を区別していたことが分かりました。それを_CI（case insensitive）に修正したところ、問題が解決しました。