Em primeiro lugar, devo dizer que não uso MySQL, mas sei sobre drivers ODBC. No ODBC existem diferentes APIs para unicode e ansi. As APIs ansi terminam em A e as APIs unicode terminam em W (por exemplo, SQLPrepareA e SQLPrepareW). As APIs ansi aceitam bytes/octetos para cadeias de caracteres e, portanto, só podem manipular chrs 0-255. As APIs de unicode aceitam SQLWCHARs que são pontos de código unicode codificados em UCS-2 de 2 bytes (versões mais recentes do MS SQL Server podem lidar com cadeias de caracteres codificadas em UTF16) e, portanto, podem lidar com aproximadamente os primeiros 65.000 pontos de código em unicode.

Portanto, se você precisar armazenar dados unicode, não terá escolha de qual driver usar.

Eu não deixaria que os comentários sobre a velocidade de Carnangel o impedissem de usar o driver unicode e, em qualquer caso, seus comentários não incluem nenhum fato. Ele pode estar se referindo a:

Se você armazenar dados unicode no MySQL, eles serão codificados em UTF-8 e transferidos pela sua rede como UTF-8. Na extremidade do cliente, o driver ODBC terá que converter os dados codificados em UTF-8 em UCS-2, pois é isso que o ODBC precisa. Obviamente o inverso se aplica.

Se você escrever um aplicativo ODBC ANSI (que usa as APIs ODBC ansi) com um driver ODBC unicode, o gerenciador de driver ODBC terá que converter o UCS-2, o driver retornará para 8 bits (com perdas) e converterá os 8 bits dados que você passa para o driver para UCS-2. Então não faça isso.

Estes dias eu ficaria surpreso se alguém ainda está usando drivers ANSI ODBC.