MySQL字符集变更后性能测试方法及标准化变更测试流程咨询

你这次故障基本可以确定是跨表字符集不匹配触发隐式转换导致索引失效，没有其他可能性：

• 改字符集本身不会带来数据库性能损耗，只有当关联查询的两张表JOIN字段字符集/排序规则（collation）不匹配时，MySQL会自动逐行对其中一侧字段做字符转码，完全无法命中原有B+树索引，原本毫秒级的索引查询会退化为全表扫描，高并发下很快打满数据库CPU、IO资源，表现为整库运行缓慢。
• 这类问题不会在变更后立刻触发，只有对应业务查询被实际调用时才会出现，因此往往在变更后流量逐步爬升、甚至次日业务全量运行时才爆发，和你描述的故障特征完全吻合。

完全不需要逐条核对数千条查询，按以下步骤操作即可覆盖所有风险点：

• 第一步：缩小排查范围。从全量SQL审计日志、慢查询日志中拉取最近7天所有涉及本次3张变更表的SQL即可，不涉及这3张表的查询完全不会受本次变更影响，排查范围可以直接缩小90%以上。
• 第二步：执行计划校验。对捞取出的所有SQL执行EXPLAIN，重点核查两个风险点：一是JOIN关联字段是否存在字符集、collation不匹配的情况；二是执行计划中type列是否从ref/range退化为ALL（全表扫描）、key列是否显示为NULL（未命中索引），命中上述特征的SQL就是性能风险点，要么统一关联表的字符集，要么在SQL中显式指定字符集规避隐式转换。
• 第三步：等比压测验证。预发环境不要用少量测试数据验证，需灌入线上脱敏后的真实业务数据，数据量至少和线上持平，将捞取的SQL按线上真实并发比例做压测，对比变更前后的QPS、SQL响应时间、数据库CPU/IO负载，只要指标波动超过10%就定位对应SQL做调整。
• 第四步：数据正确性校验。随机抽取变更表中的中文、特殊字符、emoji等字段内容，对比字符集转换前后的内容是否一致，避免转码导致乱码、数据截断问题。

所有数据库变更（含字符集调整、索引变更、表结构修改、参数调整、版本升级）都可以套用以下流程，最大程度降低性能异常、服务中断风险：

1. 变更前前置准备 #

• 提前留存至少7天的全量SQL审计日志、慢查询日志，明确性能基线：包括数据库CPU/内存/IO/连接数基准值、核心SQL平均响应时间、QPS、核心业务接口成功率基准，避免故障发生时无参考依据。
• 预发环境必须同步和线上一致的表结构、数据量级（核心表要求1:1脱敏同步，非核心表数据量不低于线上的30%），所有变更先在预发完成全流程演练。
• 提前编写并验证回滚脚本，明确硬回滚阈值：比如CPU使用率超过80%持续5分钟、慢查询量较基线上涨200%、核心接口成功率低于99.9%，达到阈值立刻回滚，禁止在线上排查问题扩大故障影响。

2. 变更中灰度验证 #

• 禁止全量一把梭变更，优先在从库执行变更，观察从库复制延迟、查询性能无异常后，先切10%的读流量到变更后实例，观察15分钟无异常再推进主库变更。
• 主库变更完成后，先执行核心业务冒烟用例（覆盖登录、下单、支付等核心路径），确认核心功能正常后再逐步放开全量流量。

3. 变更后持续观测 #

• 变更后1小时内安排专人值守，实时观测慢查询数量、数据库负载、核心接口响应时间、错误率指标，触发回滚阈值立刻操作。
• 变更后24小时内做同时间段指标对比，核查是否存在新增慢查询、隐式转换导致的索引失效问题。
• 变更后3天内完成一轮全量SQL执行计划比对，把所有涉及变更表的SQL执行计划和变更前做对比，提前发现潜在的索引失效风险。

4. 风险兜底机制 #

• 所有数据库变更统一安排在业务低峰期执行，避开大促、工作日业务高峰时段，缩小故障影响半径。
• 对核心业务SQL提前打指纹标记，配置性能波动告警，只要核心SQL响应时间、错误率超过阈值就自动触发告警，缩短故障发现时间。

内容的提问来源于stack exchange，提问作者user3411972