SHOW CREATE TABLE
to see if it really set the CHARACTER SET
and COLLATION
on the columns, not just the defaults.
What was the CHARACTER SET
before the ALTERs
?
Do SELECT col, HEX(col) ...
for some field that should have utf8 in it. This will help us determine if you really have utf8 in the table. The encoding for characters is different based on CHARACTER SET
; the HEX
helps discover such.
The ordering (WHERE
, ORDER BY
, etc) is controlled by COLLATION
. The indexes probably had to be rebuilt based on your ALTER TABLE
. Did big tables with indexes take a 'long' time to convert?
To actually see the difference between utf8_general_ci
and utf8_unicode_ci
, you need a "combining accent" or, more simply, the German ß
versus ss
:
mysql> SELECT 'ß' = 'ss' COLLATE utf8_general_ci,
'ß' = 'ss' COLLATE utf8_unicode_ci;
+-------------------------------------+-------------------------------------+
| 'ß' = 'ss' COLLATE utf8_general_ci | 'ß' = 'ss' COLLATE utf8_unicode_ci |
+-------------------------------------+-------------------------------------+
| 0 | 1 |
+-------------------------------------+-------------------------------------+
However, to test that in your tables, you would need to store those values and use WHERE
or GROUP_CONCAT
or something else to determine the equality.
What 'proof' do you have that the ALTERs
failed to achieve the collation change?
(Addressing other comments: REPAIR
should be irrelevant. CONVERT TO
tells the ALTER
to actually modify the data, so it should have done the desired action.)