Open dveeden opened 3 years ago
/type compatibility
Different client versions behave differently. This might be because some of them might issue a SET NAMES utf8mb4
.
$ for m in ./opt/mysql/*/bin/mysql; do $m --version; $m -u root -h 127.0.0.1 -P 4000 -BNe "SELECT @@session.collation_connection"; done
./opt/mysql/5.1.73/bin/mysql Ver 14.14 Distrib 5.1.73, for unknown-linux-gnu (x86_64) using readline 5.1
utf8mb4_bin
./opt/mysql/5.7.31/bin/mysql Ver 14.14 Distrib 5.7.31, for linux-glibc2.12 (x86_64) using EditLine wrapper
utf8_general_ci
./opt/mysql/8.0.22/bin/mysql Ver 8.0.22 for Linux on x86_64 (MySQL Community Server - GPL)
utf8mb4_bin
./opt/mysql/8.0.26/bin/mysql Ver 8.0.26 for Linux on x86_64 (MySQL Community Server - GPL)
utf8mb4_bin
./opt/mysql/8.0.27/bin/mysql Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL)
utf8mb4_bin
I think it's documented in https://docs.pingcap.com/tidb/stable/mysql-compatibility#default-differences ?
It indeed is documented, but as this is causing problems for applications it would be good if we can change this to be more compatible.
But it will break backward compatibility, I think you can talk to our PM. It's not a technical problem, it's a product problem.
IMHO in order to archive 'default case-insensitive collation', we need to set new collation enabled by default firstly. @wjhuang2016 Are you interested in this work?
Bug Report
1. Minimal reproduce step (Required)
TiDB:
MySQL 8.0
MySQL 5.7:
2. What did you expect to see? (Required)
Similar behavior between TiDB and MySQL.
3. What did you see instead (Required)
The default collation behaves case sensitive (binary) for TiDB.
Workaround
Using
SET NAMES
and/or charset/collation settings in the connection properties when connecting.