---
slug: "mysql-collate-utf8_unicode_ci-utf8_general_ci"
title: "MySQL の 照合順序 utf8_unicode_ci はけっこう遅いのでやめとくべき"
description: "まったく定量的な話でないのですが。"
url: "https://www.ytyng.com/blog/mysql-collate-utf8_unicode_ci-utf8_general_ci"
publish_date: "2016-09-14T09:44:56Z"
created: "2016-09-14T09:44:56Z"
updated: "2026-02-26T23:01:17.160Z"
categories: ["MySQL"]
keywords: ""
featured_image_url: "https://media.ytyng.com/resize/20230812/c7fb992c95954a6dae32a399fafc8beb.png.webp?width=768"
has_video: false
has_music: false
video_urls: []
music_urls: []
lang: "ja"
---

# MySQL の 照合順序 utf8_unicode_ci はけっこう遅いのでやめとくべき

<p>まったく定量的な話でないのですが。</p>
<p>某サービスで、MyISAM のテーブルのフィールドにフルテキストインデックスをつけて、バイグラムで検索インデックスを入れてました。20万レコードぐらい。</p>
<p>今までは、そのフィールドの文字コードの照合順序 ( collate ) は utf8_general_ci (デフォルト) だったんですが、日本語でカタカナ平仮名両方マッチさせたいので、collate を utf8_unicode_ci に変えてみたんです。</p>
<p>そうしたら、パフォーマンスが極端に悪くなり全然サービスが動かなくなってしまって。SHOW FULL PROCESSLIST; 見たら検索クエリが詰まってる。</p>
<p>ということで、utf8_unicode_ci やめて元に戻しました。日本語のカタカナ平仮名のゆれは、検索データを入れる際にノーマライズして入れることにしました。</p>
<p>utf8_unicode_ci やめといたほうがいい、という話。というか検索系は MySQL + フルテキストインデックスでやるより、Elasticsearch とか Cloudsearch とか使ったほうが良いですね。</p>
<p></p>