MySQLデータベースに接続するときに接続文字列でUTF8を使用する際にパフォーマンス上の問題はありますか？ （例：ADO.NETで "charset = utf8"を使用するか、JDBCでuseUnicode = yes & characterEncoding = utf8）MySQL - 接続文字列にUTF8エンコーディングを使用するとパフォーマンスが低下しますか？
異なるデータベースで同じ設定を使用できると仮定すると、サーバーデータベースはUTF8をサポートするように構成されていませんか？
例えば、私は、パラメータがUnicodeでない列（https://lostechies.com/jimmybogard/2012/07/18/troubleshooting-sql-index-performance-on-varchar-columns/）に対してUnicodeとして送信されたときに、テーブルスキャンで多少のパフォーマンス上の問題があることを知っています。
短い答え：いいえ。
ロング、トピックと関連項目についてとりとめのない、答え：
すべてutf8mb4すべての時間は、「最良の」アプローチです。
INSERTまたはSELECTの間にMySQLに文字セット変換を依頼するとパフォーマンスが低下することは、インデックス作成、検索、ネットワーク帯域幅、構文解析などの他のすべての問題と比較して軽微です。まともなインデックスの欠如のためにテーブルスキャン。大きなテーブルの場合、ディスクI/Oは圧倒的な要因になります。しかし、関数、式、文字セットの問題などは軽微です。
一方、JOINingの2つのテーブルがあり、結合列のデータ型が十分に一致しない場合、インデックス使用ではなくテーブルスキャンが発生する可能性があります。不一致CHARACTER SETまたはCOLLATION時々このパフォーマンスヒットにつながります。
質問に戻るまず、クライアントの文字に使用されているエンコーディングを設定します。あなたの例はutf8を示しました。 （おそらくスペルはUTF-8だったはずです）。次に、列レベルで、格納に使用する文字セットを指定します。 （データベースにはデフォルトが設定されています（デフォルトにすることができます）。
クライアント文字が一方向にエンコードされ、列が別の方法でエンコードされている場合、変換があります。パフォーマンスについて心配しないでください。
注：「照合」については言及しませんでした。この用語は、同じ文字セット内のテキスト間の比較を指します。 INSERTおよびSELECT（WHEREおよびORDER BYの他に）は、比較を含まない。
MySQL以外では、通常「UTF-8」と記述されています。 MySQL内部では、それは4バイトまでのエンコーディングを可能にする "utf8mb4"です。 MySQLの内部では、 "utf8"は3バイト（またはそれより短い）のサブセットを指します。
注：「Unicode」については言及していませんでした。 「UCS2」ではなく「UTF-8」を使用します。 （私は、残念ながら、JDBC接続パラメータに 'UTF-8'と 'Unicode'の両方が含まれていると思います）。
* "一方、2つのテーブルと結合カラムのデータ型をジョインするs）が十分に一致しない場合、これは索引の使用ではなく表のスキャンを引き起こす可能性があります。 "* - WHERE句の非Unicode列およびUnicode検索語句の場合もそうですか？もしそうなら、それはおそらく*「まともな[Unicode]インデックスの欠如のためにテーブルスキャンを実行する際のパフォーマンスが非常に悪い」*という結果になる可能性があります。 –
@GordThompsonの問題は、SQL Serverでvarchar列とnvarcharパラメータを使用した場合と同じです。フルテーブルスキャンが必要なためインデックスは無関係です。 – agentshowers
@GordThompson - WHERE utf8_col = 'some string'' - リテラル列の文字セットと照合に変換されるので、問題ありません。 'WHERE utf8_col = '一部の文字列' COLLATE utf8_turkish_ci'はテーブルスキャンにつながる可能性があります。 –