Bei der Installation einer meiner Anwendungen bin ich auf die folgende Fehlermeldung gestoßen:
PDOStatement: Specified key was too long; max key length is 767 bytes
Lag schlussendlich daran, dass meine Standartkodierung der Datenbank utf8mb4 war, und ich bei dieser Kodierung andere Limits habe, als unter utf8. Das ist im Nachhinein auch logisch.
Die Erklärung fand ich in diesem Stackoverflow-Thread.
When you hit the limit. Set the following.
- INNODB
utf8VARCHAR(255)- INNODB
utf8mb4VARCHAR(191)
Anschließend habe ich mich ein wenig mit utf8 beschäftigt, um den genauen unterschied zwischen utf8_general_ci utf8_binary und utf8_unicode_ci herauszufinden.
Die Antwort dafür ist hier:
In general, utf8_general_ci is faster than utf8_unicode_ci, but less correct.
Here is the difference:
For any Unicode character set, operations performed using the _general_ci collation are faster than those for the _unicode_ci collation. For example, comparisons for the utf8_general_ci collation are faster, but slightly less correct, than comparisons for utf8_unicode_ci. The reason for this is that utf8_unicode_ci supports mappings such as expansions; that is, when one character compares as equal to combinations of other characters. For example, in German and some other languages “ß” is equal to “ss”. utf8_unicode_ci also supports contractions and ignorable characters. utf8_general_ci is a legacy collation that does not support expansions, contractions, or ignorable characters. It can make only one-to-one comparisons between characters.
Quoted from: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
For more detailed explanation, please read the following post from MySQL forums: http://forums.mysql.com/read.php?103,187048,188748
As for utf8_bin: Both utf8_general_ci and utf8_unicode_ci perform case-insensitive comparison. In constrast, utf8_bin is case-sensitive (among other differences), because it compares the binary values of the characters.
