MySQLでEntityFrameworkを使用する場合、Unicode文字は基本文字に置き換えられます

MySQLでは、クライアント/サーバー通信のいくつかの側面を構成できます（10.4接続文字セットと照合ドキュメント）：

ソース（つまりクライアント）エンコーディング：character_set_client
宛先（つまりサーバー）エンコーディング：character_set_connection
返されたデータとメタデータ：character_set_results

マイクロソフトのテクノロジに由来するソースエンコーディングは、UTF-16リトルエンディアンであると想定されていると思います。

他の2つについては、 Connector / NET接続-文字列オプションリファレンスドキュメントの状態：

MySQLへの接続は、ターゲットエンコーディングがUTF-8（MySQL列が使用しているもの）であることを通知する必要があります。 MySQLは現在、Unicode以外の文字列を送信していると想定しており、VARCHARに変換するのと実質的に同じことを行います。 SQL Serverでは、現在のデータベースのデフォルトの照合で指定されたコードページが1252であると想定しています（Windowsコードページ1252は、一般に「 ANSI "、たとえそれが技術的にであっても不正確な名前）。

次に、文字列の前に大文字の「N」を付けない場合のSQLServerの動作を示します。

SELECT 'α'; -- Database's default Collation = Latin1_General_100_CI_AS_SC
-- a

SELECT 'α'; -- Database's default Collation = Hebrew_100_BIN2
-- ?

これを修正するには、次のことを試してください。

最初の試みは、接続文字列に以下を追加して、文字データをUTF-8としてMySQLに送信することです（これはcharacter_set_connectionを設定するだけです。）：
```
CharSet=utf8;
```
完全な接続文字列の例ここ
2番目の試みは、最初の接続時にSQLコマンドを送信して、宛先エンコーディングを制御するセッションレベルの変数を設定することです。
```
SET character_set_connection = utf8;
```

詳細については、以下を参照してください。

MySQL Charset / Collate

そのページの「utf8Collations」セクションによると、utf8_unicode_ciを使用する方がはるかに優れています。 utf8_general_ciの代わりに照合用（明確にするために、この推奨事項は、ここで扱われている文字変換の問題とは何の関係もありません。）

P.S.この質問/回答には、DBA.StackExhangeに関するQ＆Aがあります：

SQL ServerでBase64文字列をNVARCHARにデコードするときに間違った文字が表示されるのはなぜですか？