技术笔记：MySQL 字符集排序规则与大小写敏感性问题解决方案

MySQL 字符集排序规则与大小写敏感性问题解决方案

1. 背景问题

在处理电商、搜索词或社交数据时，常会遇到同一个业务主键存在"大小写异体"的情况。例如：业务主键由 platform_id + keyword + event_date 构成。

数据 A：{'platform_id': 1, 'keyword': 'Python', 'event_date': '2023-10-01'}
数据 B：{'platform_id': 1, 'keyword': 'python', 'event_date': '2023-10-01'}

痛点：

在默认的 utf8mb4_unicode_ci 排序规则下，'Python' 与 'python' 被视为相同，导致主键冲突，无法同时存入。
线上现有查询依赖默认排序规则，不能轻易更改字段字符集（怕引起 Illegal mix of collations 报错）。
自动化数据工具（如 RPA 工具）在写入时会强行给所有字段传值，导致"生成列"等数据库方案失效。

2. 关键概念：`_ci` vs `_bin`

_ci (Case Insensitive) ：大小写不敏感。数据库将 A 和 a 视为相等。
_bin (Binary) ：二进制比较。数据库将字符转为二进制，A (0x41) 与 a (0x61) 不同。

3. 常见失败方案回顾 (MySQL 5.7 局限)

方案 A：增加基于 _bin 的冗余生成列

失败原因 ：自动化工具写入时，会试图往该只读列写入 NULL 或空串，MySQL 报错 Column '...' is generated and cannot be modified。

方案 B：冗余列 + 触发器填充

失败原因 ：在执行 INSERT ... ON DUPLICATE KEY UPDATE 时，如果工具传入该冗余列的值为 NULL，MySQL 的冲突检查会认为 NULL 不等于库中的任何值，从而跳过更新直接执行插入。待触发器填值后，库中已产生两条重复数据。

4. 最佳实践方案：应用层哈希指纹法 (Code-Level Fingerprint)

该方案通过在应用层（如 Python）预生成唯一标识符，将业务主键的校验逻辑从数据库层面转移到逻辑层面。

方案核心逻辑：

数据库层 ：保持原业务字段字符集不变（确保兼容性）；新增一个 data_fingerprint 字段作为物理主键。
应用层：写入前，将业务关键字段拼合后进行 MD5 摘要，生成 32 位哈希码。MD5 天然区分大小写。

实施步骤：

第一步：Python 代码预处理

在数据存入数据库的 DataFrame 中，新增一列特征指纹。

python 复制代码

import hashlib

def generate_row_fingerprint(row):
    """
    拼凑所有构成唯一性的业务字段，并计算MD5
    MD5 对大小写敏感，能完美区分 'Apple' 和 'apple'
    """
    unique_elements = [
        str(row['store_id']),
        str(row['main_keyword']),
        str(row['report_date']),
        str(row['category_name'])
    ]
    # 拼接业务字段
    raw_key = "_".join(unique_elements)
    return hashlib.md5(raw_key.encode('utf-8')).hexdigest()

# 在数据 DataFrame 中应用
df['data_fingerprint'] = df.apply(generate_row_fingerprint, axis=1)

第二步：SQL 表结构升级

调整数据库，将原有联合主键升级为指纹列。

sql 复制代码

-- 1. 新增指纹列，设置为二进制编码
ALTER TABLE `t_business_data_info` 
ADD COLUMN `data_fingerprint` CHAR(32) COLLATE utf8mb4_bin NOT NULL COMMENT '系统生成唯一指纹';

-- 2. 切换主键：将物理主键替换为指纹列
ALTER TABLE `t_business_data_info` 
DROP PRIMARY KEY,
ADD PRIMARY KEY (`data_fingerprint`);

-- 3. (可选) 给原业务字段加普通索引，方便按 keyword 查询
ALTER TABLE `t_business_data_info` 
ADD INDEX `idx_keyword` (`main_keyword`);

5. 方案总结与优势

维度	效果评价
大小写支持	完美。MD5 结果不同，允许大小写异体词并存。
防重复写入	完美。相同数据生成的指纹一致，`ON DUPLICATE KEY` 能精准触发更新逻辑。
查询兼容性	高。业务字段保持 CI 编码，线上程序无需修改 SQL 关联语句。
代码无侵入	中。仅需在数据写入前的工具脚本中添加几行逻辑，对外部系统透明。

核心感悟

在旧版本数据库（如 MySQL 5.7）中，当数据库约束（Constraint）与上游工具产生兼容性冲突时，"逻辑前置"（即在应用层解决索引匹配逻辑）是最稳健的工业级方案。它牺牲了少量的磁盘空间（多一列 Hash 字段），换取了业务的绝对正确和系统的高稳定性。