Troubleshooting “Illegal mix of collations” error in mysql

Question

Am getting the below error when trying to do a select through a stored procedure in MySQL.

Illegal mix of collations (latin1_general_cs,IMPLICIT) and

Answer 1

Sometimes it can be dangerous to convert charsets, specially on databases with huge amounts of data. I think the best option is to use the "binary" operator:

e.g : WHERE binary table1.column1 = binary table2.column1

Answer 2

One another source of the issue with collations is mysql.proc table. Check collations of your storage procedures and functions:

SELECT
  p.db, p.db_collation, p.type, COUNT(*) cnt
FROM mysql.proc p
GROUP BY p.db, p.db_collation, p.type;

Also pay attention to mysql.proc.collation_connection and mysql.proc.character_set_client columns.

Answer 3

You can try this script, that converts all of your databases and tables to utf8.

Answer 4

Adding my 2c to the discussion for future googlers.

I was investigating a similar issue where I got the following error when using custom functions that recieved a varchar parameter:

Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and 
(utf8_general_ci,IMPLICIT) for operation '='

Using the following query:

mysql> show variables like "collation_database";
    +--------------------+-----------------+
    | Variable_name      | Value           |
    +--------------------+-----------------+
    | collation_database | utf8_general_ci |
    +--------------------+-----------------+

I was able to tell that the DB was using utf8_general_ci, while the tables were defined using utf8_unicode_ci:

mysql> show table status;
    +--------------+-----------------+
    | Name         | Collation       |
    +--------------+-----------------+
    | my_view      | NULL            |
    | my_table     | utf8_unicode_ci |
    ...

Notice that the views have NULL collation. It appears that views and functions have collation definitions even though this query shows null for one view. The collation used is the DB collation that was defined when the view/function were created.

The sad solution was to both change the db collation and recreate the views/functions to force them to use the current collation.

• Changing the db's collation:

  ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;
  

• Changing the table collation:

  ALTER TABLE mydb CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
  

I hope this will help someone.

Answer 5

If the columns that you are having trouble with are "hashes", then consider the following...

If the "hash" is a binary string, you should really use BINARY(...) datatype.

If the "hash" is a hex string, you do not need utf8, and should avoid such because of character checks, etc. For example, MySQL's MD5(...) yields a fixed-length 32-byte hex string. SHA1(...) gives a 40-byte hex string. This could be stored into CHAR(32) CHARACTER SET ascii (or 40 for sha1).

Or, better yet, store UNHEX(MD5(...)) into BINARY(16). This cuts in half the size of the column. (It does, however, make it rather unprintable.) SELECT HEX(hash) ... if you want it readable.

Comparing two BINARY columns has no collation issues.

Answer 6

A possible solution is to convert the entire database to UTF8 (see also this question).