En primer lugar, debo decir que no uso MySQL, pero sé acerca de los controladores ODBC. En ODBC existen diferentes API para unicode y ansi. Las API ansi terminan en A y las API Unicode terminan en W (por ejemplo, SQLPrepareA y SQLPrepareW). Las API ansi aceptan bytes/octetos para cadenas de caracteres y, por lo tanto, solo pueden manejar chrs 0-255. Las API Unicode aceptan SQLWCHAR, que son puntos de código Unicode codificados en UCS-2 de 2 bytes (las versiones más recientes de MS SQL Server pueden manejar cadenas codificadas en UTF16) y, por lo tanto, pueden manejar aproximadamente los primeros 65000 puntos de código en Unicode.
Entonces, si necesita almacenar datos Unicode, no tiene elección sobre qué controlador usar.
No dejaría que los comentarios sobre la velocidad de Carnangel lo desanimen con el controlador Unicode y, en cualquier caso, sus comentarios no incluyen ningún hecho. Puede estar refiriéndose a:
Si almacena datos Unicode en MySQL, se codificarán en UTF-8 y se transferirán a través de su red como UTF-8. En el extremo del cliente, el controlador ODBC tendrá que convertir los datos codificados en UTF-8 en UCS-2, ya que esto es lo que necesita ODBC. Obviamente se aplica lo contrario.
Si escribe una aplicación ANSI ODBC (es decir, una que utiliza la API ODBC ansi) con un controlador ODBC Unicode, el administrador del controlador ODBC tendrá que convertir el UCS-2, el controlador vuelve a 8 bits (con pérdida) y convierte los 8 bits datos que pasa al controlador a UCS-2. Así que no hagas eso.
En estos días, me sorprendería si alguien todavía usa controladores ANSI ODBC.
