如何在MySQL中区分大小写进行数据查询
场景描述今天在将Hive表同步到MySQL之后，其中有一列是唯一列，但是在MySQL中查询的时候count与distinctcount查询出来的数值是不一样的，这么来看的话是有重复的数据（按理说不应该的，因为在Hive中，这两个数值是一样的），那么将重复的数据查出来看了一下，发现是大小写的问题，然后查了一下，发现MySQL数据库默认情况下，字符串字段的所有相关运算是大小写"不敏感"的。这一点与其它流行的数据库都不相同。解决办法1.查询时指定大小写敏感MySQL允许在查询的时候指定以大小写敏感方式，需要使用
场景描述
今天在将 Hive 表同步到 MySQL 之后，其中有一列是唯一列，但是在 MySQL 中查询的时候 count 与 distinct count 查询出来的数值是不一样的，这么来看的话是有重复的数据（按理说不应该的，因为在 Hive 中，这两个数值是一样的），那么将重复的数据查出来看了一下，发现是大小写的问题，然后查了一下，发现 MySQL 数据库默认情况下，字符串字段的所有相关运算是大小写"不敏感"的。
这一点与其它流行的数据库都不相同。
解决办法
1. 查询时指定大小写敏感
MySQL 允许在查询的时候指定以大小写敏感方式，需要使用关键字 BINARY，查询如下：
SELECT * FROM student WHERE BINARY name = 'ZhangSan'; --或者 SELECT * FROM student WHERE name = BINARY 'ZhangSan';
很多时候当发现 MySQL 数据库存在上述问题时，系统已经运行了一段时间，如果采用方法二或方法三的代价可能会很大。
使用此方法最大的好处便是可以快速实现功能。
但是这个方法也存在很大的限制：如此可能因为无法使用索引导致查询性能下降。
原因很好理解，因为此时针对查询字段的索引也是按照大小写不敏感方式建立的。
除非数据量不大，或者在你的应用中不在乎这点性能上的损失，那么只能选择方法二或方法三了。
2. 定义表结构时指定字段大小写敏感
在创建表时指定具体的字段大小写敏感，示例如下：
CREATE TABLE student ( ... name VARCHAR(64) BINARY NOT NULL, ... )
关键字 BINARY 指定 name 字段大小写敏感。
如此在查询时就算不使用 BINARY 关键字，查询语句也是大小写敏感的。
在此基础上创建的 name 相关的索引也是大小写敏感的，也就能够使用索引来提高性能。
MySQL 允许在大多数字符串类型上使用 BINARY 关键字，用于指明所有针对该字段的运算是大小写敏感的，更多信息请参见 MySQL 官方文档。
这种方法使得设计者可以精确地控制每个字段是否大小写敏感。不过在很多系统的设计中，期望大部分甚至所有的字段统一大小写敏感。MySQL 也提供了解决方案，这就要用到方法三。
3. 修改排序规则（COLLATE）
在 MySQL 中执行 show create table 指令，可以看到一张表的建表语句，example 如下：
CREATE TABLE `table1` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `field1` text COLLATE utf8_general_ci NOT NULL COMMENT '字段1', `field2` varchar(128) COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '字段2', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8_unicode_ci;
大部分字段我们都能看懂，但是今天要看的是 COLLATE 关键字。这个值后面对应的 utf8_general_ci 是什么意思呢？下面我们就来了解一下。
COLLATE是用来做什么的？
使用 Navicat 开发的可能会比较眼熟，因为其中的选项中已经给出了答案：
所谓 utf8_general_ci，其实是用来排序的规则。对于 MySQL 中那些字符类型的列，如VARCHAR，CHAR，TEXT 类型的列，都需要有一个 COLLATE 类型来告知 MySQL 如何对该列进行排序和比较。简而言之，COLLATE 会影响到 ORDER BY 语句的顺序，会影响到 WHERE 条件中大于小于号筛选出来的结果，会影响 DISTINCT、GROUP BY、HAVING 语句的查询结果。另外，MySQL 建索引的时候，如果索引列是字符类型，也会影响索引创建，只不过这种影响我们感知不到。总之，凡是涉及到字符类型比较或排序的地方，都会和 COLLATE 有关。
涉及字符串的各种运算其核心必然涉及到采用何种字符排序规则（COLLATE，也有翻译为"核对"）。本质上 MySQL 是通过 COLLATE 取值决定字符串运算是否大小写敏感。
utf8_general_ci 是一个具体的 COLLATE 取值。每个具体的 COLLATE 都对应唯一的字符集，可以看出该 COLLATE 对应字符集为 utf8。而与大小写敏感问题相关的是其后缀 _ci，MySQL 官方文档对其的解释是 Case Ignore 的缩写，即大小写不敏感。由于 MySQL 将 utf8_general_ci 指定作为字符集 utf8 的默认 COLLATE，这也就导致文章开头所说的现象。与此同时，MySQL 也提供了其它的 COLLATE 取值选项，utf8_bin 就是大小写敏感的。事实上所有大小写敏感的 COLLATE 都以 _bin或 _cs 为后缀，前者是 Binary 的缩写，后者是 Case Sensitive 的缩写。
各种COLLATE的区别
COLLATE 通常是和数据编码（CHARSET）相关的，一般来说每种 CHARSET 都有多种它所支持的 COLLATE，并且每种 CHARSET 都指定一种 COLLATE 为默认值。例如 Latin1 编码的默认 COLLATE 为 latin1_swedish_ci，GBK 编码的默认 COLLATE 为 gbk_chinese_ci，utf8mb4 编码的默认值为 utf8mb4_general_ci。
这里顺便讲个题外话，MySQL 中有 utf8 和 utf8mb4 两种编码，在 MySQL 中请大家忘记 utf8，永远使用 utf8mb4。这是 MySQL 的一个遗留问题，MySQL 中的 utf8 最多只能支持 3bytes 长度的字符编码，对于一些需要占据 4bytes 的文字，MySQL 的 utf8 就不支持了，要使用 utf8mb4 才行。
很多 COLLATE 都带有 _ci 字样，这是 Case Insensitive 的缩写，即大小写无关，也就是说 "A" 和 "a" 在排序和比较的时候是一视同仁的。selection * from table1 where field1="a" 同样可以把 field1 为 "A" 的值选出来。与此同时，对于那些 _cs 后缀的 COLLATE，则是 Case Sensitive，即大小写敏感的。
在 MySQL 中使用 show collation 指令可以查看到 MySQL 所支持的所有 COLLATE。以 utf8mb4 为例，该编码所支持的所有 COLLATE 如下图所示。
图中我们能看到很多国家的语言自己的排序规则。在国内比较常用的是 utf8mb4_general_ci（默认）、utf8mb4_unicode_ci、utf8mb4_bin 这三个。我们来探究一下这三个的区别：
首先 utf8mb4_bin 的比较方法其实就是直接将所有字符看作二进制串，然后从最高位往最低位比对。所以很显然它是区分大小写的。
而 utf8mb4_unicode_ci 和 utf8mb4_general_ci 对于中文和英文来说，其实是没有任何区别的。对于我们开发的国内使用的系统来说，随便选哪个都行。只是对于某些西方国家的字母来说，utf8mb4_unicode_ci 会比 utf8mb4_general_ci 更符合他们的语言习惯一些，general 是 MySQL 一个比较老的标准了。例如，德语字母 "ß"，在 utf8mb4_unicode_ci 中是等价于 "ss" 两个字母的（这是符合德国人习惯的做法），而在 utf8mb4_general_ci 中，它却和字母 "s" 等价。不过，这两种编码的那些微小的区别，对于正常的开发来说，很难感知到。本身我们也很少直接用文字字段去排序，退一步说，即使这个字母排错了一两个，真的能给系统带来灾难性后果么？从网上找的各种帖子讨论来说，更多人推荐使用 utf8mb4_unicode_ci，但是对于使用了默认值的系统，也并没有非常排斥，并不认为有什么大问题。结论：推荐使用 utf8mb4_unicode_ci，对于已经用了 utf8mb4_general_ci 的系统，也没有必要花时间改造。
另外需要注意的一点是，从 MySQL 8.0 开始，MySQL 默认的 CHARSET 已经不再是 Latin1 了，改为了 utf8mb4 （参考链接），并且默认的 COLLATE 也改为了 utf8mb4_0900_ai_ci。utf8mb4_0900_ai_ci 大体上就是 unicode 的进一步细分，0900 指代 unicode 比较算法的编号（ Unicode Collation Algorithm version），ai 表示 accent insensitive（发音无关），例如 e，è， é， ê 和 ë 是一视同仁的。相关参考链接1，相关参考链接2
COLLATE 设置级别及其优先级
MySQL 数据库允许在库、表 和 列 三个级别上指定 Collation。当同时指定时，优先关系是：列 > 表 > 库。
设置 COLLATE 可以在实例级别、库级别、表级别、列级别、以及 SQL 指定。当同时指定时，优先关系是：SQL 指定 > 列 > 表 > 库 > 实例级别。
实例级别的 COLLATE 设置就是 MySQL 配置文件或启动指令中的 collation_connection 系统变量。
库级别设置 COLLATE 的语句如下：
CREATE DATABASEDEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
如果库级别没有设置 CHARSET 和 COLLATE，则库级别默认的 CHARSET 和 COLLATE 使用实例级别的设置。在 MySQL 8.0 以下版本中，你如果什么都不修改，默认的 CHARSET 是 Latin1，默认的 COLLATE 是 latin1_swedish_ci。从 MySQL 8.0 开始，默认的 CHARSET 已经改为了 utf8mb4，默认的 COLLATE 改为了 utf8mb4_0900_ai_ci。
表级别的 COLLATE 设置，则是在 CREATE TABLE 的时候加上相关设置语句，例如：
CREATE TABLE table_name ( …… ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT = '表注释';
如果表级别没有设置 CHARSET 和 COLLATE，则表级别会继承库级别的 CHARSET 与 COLLATE。
列级别的设置，则在 CREATE TABLE 中声明列的时候指定，例如
CREATE TABLE ( `field1` VARCHAR（64） CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '' COMMENT '字段1', …… ) ……
如果列级别没有设置 CHARSET 和 COLATE，则列级别会继承表级别的 CHARSET 与 COLLATE。
最后，你也可以在写 SQL 查询的时候显示声明 COLLATE 来覆盖任何库表列的 COLLATE 设置，不太常用，了解即可：
SELECT DISTINCT field1 COLLATE utf8mb4_general_ci FROM table1; SELECT field1, field2 FROM table1 ORDER BY field1 COLLATE utf8mb4_unicode_ci;
如果全都显示设置了，那么优先级顺序是 SQL 语句 > 列级别设置 > 表级别设置 > 库级别设置 > 实例级别设置。
也就是说列上所指定的 COLLATE可以覆盖表上指定的 COLLATE，表上指定的 COLLATE 可以覆盖库级别的 COLLATE。如果没有指定，则继承下一级的设置。
即列上面没有指定 COLLATE，则该列的 COLLATE 和表上设置的一样。
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
