För det första bör jag säga att jag inte använder MySQL men jag känner till ODBC-drivrutiner. I ODBC finns det olika API:er för unicode och ansi. Ansi API:erna slutar på A och unicode API:erna slutar på W (t.ex. SQLPrepareA och SQLPrepareW). Ansi API:erna accepterar bytes/oktetter för teckensträngar och kan därför bara hantera chrs 0-255. Unicode-API:erna accepterar SQLWCHAR som är 2 byte UCS-2-kodade unicode-kodpunkter (nyare MS SQL Server-versioner kan hantera UTF16-kodade strängar) och kan därför hantera ungefär de första 65 000 kodpunkterna i unicode.
Så om du behöver lagra unicode-data har du inget val vilken drivrutin du ska använda.
Jag skulle inte låta kommentarerna om hastighet från Carnangel avskräcka dig från att använda unicode-drivrutinen och i alla fall innehåller hans kommentarer inte några fakta. Han kanske syftar på:
Om du lagrar unicode-data i MySQL kommer den att UTF-8-kodas och överföras över ditt nätverk som UTF-8. Vid klientänden måste ODBC-drivrutinen konvertera UTF-8-kodade data till UCS-2 eftersom detta är vad ODBC behöver. Uppenbarligen gäller det omvända.
Om du skriver en ANSI ODBC-applikation (det vill säga en som använder ansi ODBC-apis) med en unicode ODBC-drivrutin måste ODBC-drivrutinshanteraren konvertera UCS-2, drivrutinen återgår till 8 bitar (förlust) och konvertera 8-bitars data du skickar till föraren till UCS-2. Så gör inte det.
Nuförtiden skulle jag bli förvånad om någon fortfarande använder ANSI ODBC-drivrutiner.