Oracle迁移至GreatSQL过程中因排序规则调整导致的字符编码问题解析与应对策略

未分类 2个月前程序员胖胖胖虎阿

65 0 0

背景概述

在将传统Oracle数据库系统向GreatSQL平台迁移的过程中，初期阶段（包括存储过程、表结构和基础数据的转移）进展顺利。然而在进行第二阶段数据迁移时，系统出现了主键冲突的异常情况：原Oracle环境中存在A和a两个主键字段（在忽略大小写的情况下被视为相同值），而GreatSQL默认采用的utf8mb4_0900_ai_ci排序规则同样不区分大小写，导致主键冲突。
为解决此问题，技术团队将排序规则调整为utf8mb4_0900_bin以实现大小写区分。但这一调整却引发了新的问题：Java应用程序在读取中文字段时出现乱码现象（例如"好"字显示为"å¥½"），严重影响了业务功能的正常运行。本文将从环境适配性、驱动程序版本、字符编码转换机制等多个维度深入剖析问题根源，并提供三种切实可行的解决方案。

运行环境与问题背景

关键系统组件信息：
组件 | 版本信息 | 说明
---|---|---
数据库系统 | GreatSQL 8.0.32-26 | 默认字符编码为utf8mb4
Java开发工具包 | JDK 1.7.0_80 | 历史版本，升级难度较大
数据库连接驱动 | mysql-connector-java 5.1.46 | 官方已停止维护更新
字符编码设置 | utf8mb4 | 未作改动
排序规则 | 由utf8mb4_0900_ai_ci改为utf8mb4_0900_bin | 变更后出现乱码问题
核心矛盾点分析
* 业务需求层面：必须采用utf8mb4_0900_bin排序规则来解决主键冲突问题
* 技术限制层面：旧版JDK 1.7与低版本驱动程序（5.1.46）存在兼容性问题，无法正确解析新的排序规则

问题重现过程

1. 测试环境搭建与数据准备

greatsql> CREATE TABLE test.t1(id int PRIMARY KEY, cname varchar(10))
DEFAULT charset=utf8mb4 collate=utf8mb4_0900_ai_ci;
执行成功，影响0行（耗时0.02秒）
greatsql> INSERT INTO test.t1 VALUES(1, '好');
执行成功，影响1行（耗时0.00秒）

验证Java运行环境版本

$ javac -version
javac 1.7.0_80
$ java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

创建数据库查询程序SimpleDBQuery.java：

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
public class SimpleDBQuery {
public static void main(String[] args) {
String connectionUrl = "jdbc:mysql://172.17.134.66:3301/test?characterEncoding=UTF-8&useSSL=false";
String dbUser = "bing";
String dbPassword = "abc123";
Connection dbConnection = null;
Statement sqlStatement = null;
ResultSet queryResult = null;
try {
Class.forName("com.mysql.jdbc.Driver");
dbConnection = DriverManager.getConnection(connectionUrl, dbUser, dbPassword);
String querySql = "SELECT cname FROM t1 LIMIT 1";
sqlStatement = dbConnection.createStatement();
queryResult = sqlStatement.executeQuery(querySql);
if (queryResult.next()) {
String resultValue = queryResult.getString("cname");
System.out.println("查询输出: " + resultValue);
}
} catch (Exception ex) {
ex.printStackTrace();
} finally {
try {
if (queryResult != null) queryResult.close();
if (sqlStatement != null) sqlStatement.close();
if (dbConnection != null) dbConnection.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
}

2. 初始数据读取测试（正常情况）

$ javac -cp .:mysql-connector-java-5.1.46.jar SimpleDBQuery.java
$ java -cp .:mysql-connector-java-5.1.46.jar SimpleDBQuery
查询输出: 好

3. 排序规则修改后的异常重现

greatsql> ALTER TABLE test.t1 CONVERT TO charset utf8mb4 COLLATE utf8mb4_0900_bin;
执行成功，影响0行（耗时0.04秒）
记录数: 0  重复数: 0  警告数: 0

再次通过Java程序查询中文数据时出现乱码:

$ java -cp .:mysql-connector-java-5.1.46.jar SimpleDBQuery
查询输出: å¥½

问题诊断与分析

1. 数据库端验证

确认表中数据存储正常，仅排序规则发生变更，字符集保持原样。

greatsql> SHOW CREATE TABLE test.t1 \G
*************************** 1. row ***************************
表名: t1
创建语句: CREATE TABLE `t1` (
`id` int NOT NULL,
`cname` varchar(10) COLLATE utf8mb4_0900_bin DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_bin
查询到1行（耗时0.00秒）
greatsql> SELECT * FROM test.t1;
+----+-------+
| id | cname |
+----+-------+
|  1 | 好    |
+----+-------+
查询到1行（耗时0.01秒）

2. 驱动程序源码审查

检查驱动5.1.46版本仅支持utf8mb4_0900_ai_ci，未包含utf8mb4_0900_bin的定义。

$ grep -inr 'utf8mb4_0900_ai_ci' *
com/mysql/jdbc/CharsetMapping.java:489:        collation[255] = new Collation(255, "utf8mb4_0900_ai_ci", 0, MYSQL_CHARSET_NAME_utf8mb4);
$ grep -inr 'utf8mb4_0900_bin' *
$ pwd
/opt/software/jdbc_test/mysql-connector-java-5.1.46/src

3. 字符解码机制分析

当驱动程序无法识别特定排序规则时，默认采用latin1解码方案，导致UTF-8字节流被错误解析
Oracle迁移至GreatSQL过程中因排序规则调整导致的字符编码问题解析与应对策略

4. 网络数据包分析

通过抓包工具对比分析发现，无论是utf8mb4_0900_ai_ci还是utf8mb4_0900_bin，返回的十六进制数据均为e5 a5 bd
Oracle迁移至GreatSQL过程中因排序规则调整导致的字符编码问题解析与应对策略

5. 数据包内容验证

当使用默认的latin1字符集进行解码时，将e5 a5 bd按照latin1解码，结果与查询乱码完全一致。
通过在线编码转换工具验证，按latin1解码结果与乱码现象相符：
Oracle迁移至GreatSQL过程中因排序规则调整导致的字符编码问题解析与应对策略
通过同一工具按utf8解码，能够正确显示"好"字：

根本原因总结

问题本质：旧版驱动程序（5.1.46）未能适配GreatSQL 8.0.32的utf8mb4_0900_bin排序规则，触发默认的latin1解码机制，造成UTF-8字节流被错误转换。

解决方案建议

方案一：强制指定JDBC连接字符集参数（推荐方案）
在数据库连接字符串中明确指定编码解码规则：

String url = "jdbc:mysql://10.191.81.31:3307/test?useUnicode=true&characterSetResults=utf8&characterEncoding=utf8&useSSL=false";

参数说明：
* characterSetResults=utf8：强制服务端返回UTF-8编码数据
* characterEncoding=utf8：客户端使用UTF-8编码发送请求

优势：无需系统升级，修改简单，兼容性良好
方案二：采用兼容的排序规则替代方案
将排序规则改为utf8mb4_bin（而非utf8mb4_0900_bin），该规则在驱动5.1.46版本中已支持，且同样具备大小写区分功能。

ALTER TABLE test.t1 CONVERT TO CHARSET utf8mb4 COLLATE utf8mb4_bin;

方案三：升级驱动程序至8.0.x版本
使用mysql-connector-java-8.0.32，该版本完全支持utf8mb4_0900_bin排序规则。

// 引入新版驱动依赖
dependencies {
implementation 'mysql:mysql-connector-java:8.0.32'
}

注意事项：需全面测试JDK 1.7与新版本驱动的兼容性，部分API接口可能需要调整

总结与建议

通过问题重现、系统排查和根源分析三个关键步骤，我们准确定位了乱码问题的本质在于驱动程序版本与数据库排序规则之间的兼容性问题。提出的三种解决方案各具特点：
1. 快速修复方案：调整JDBC连接参数，强制使用UTF-8编解码机制
2. 保守调整方案：采用兼容的utf8mb4_bin排序规则
3. 技术升级方案：将驱动程序升级至8.0.x版本
建议根据实际运行环境和业务需求选择最适合的解决方案，并在实施变更后进行全面的功能测试，确保数据完整性和业务连续性。

GreatSQL让数据库管理更高效 ?

GreatSQL简介

GreatSQL是一款面向金融级应用场景的国产开源数据库系统，具有高性能、高可靠性、易用性强、安全性高等核心特性，可作为MySQL或Percona Server的替代选择，适用于生产环境部署，完全免费且保持与MySQL/Percona Server的良好兼容性。
相关资源： GreatSQL技术社区代码托管平台Gitee GitHub仓库视频教程平台