Nejprve bych měl říci, že nepoužívám MySQL, ale vím o ovladačích ODBC. V ODBC existují různá API pro unicode a ansi. Rozhraní ansi API končí na A a unicode API končí na W (např. SQLPrepareA a SQLPrepareW). Rozhraní ansi API přijímají bajty/oktety pro znakové řetězce, a proto mohou zpracovat pouze chrs 0-255. Unicode API přijímají SQLWCHAR, což jsou 2bajtové kódové body Unicode kódované UCS-2 (novější verze MS SQL Serveru dokážou zpracovat řetězce kódované UTF16), a tak mohou zpracovat přibližně prvních 65 000 kódových bodů v unicode.
Takže pokud potřebujete uložit data Unicode, nemáte na výběr, který ovladač použít.
Nenechal bych se komentáři o rychlosti od Carnangela odradit používáním unicode ovladače a v žádném případě jeho komentáře neobsahují žádná fakta. Možná má na mysli:
Pokud v MySQL uložíte data Unicode, budou zakódována v UTF-8 a přenesena přes vaši síť jako UTF-8. Na straně klienta bude muset ovladač ODBC převést data kódovaná UTF-8 do UCS-2, protože to je to, co ODBC potřebuje. Platí to samozřejmě obráceně.
Pokud napíšete aplikaci ANSI ODBC (to je ta, která používá rozhraní ANSI ODBC) s ovladačem ODBC unicode, bude muset správce ovladačů ODBC převést UCS-2, ovladač se vrátí na 8bitový (ztrátový) a převést 8bitový data, která předáte ovladači do UCS-2. Tak to nedělejte.
V těchto dnech bych byl překvapen, kdyby někdo stále používal ovladače ANSI ODBC.