完全相同的 MySQL 表结构/数据，相同查询的不同结果

Question

这是我的情况。

我正在从一台服务器迁移到另一台服务器。 作为其中的一部分，我正在跨数据库数据移动。

迁移方法涉及在新服务器上运行相同的 CREATE TABLE 查询，然后使用一系列 INSERT 命令逐行插入数据。 这可能会导致不同的数据，但是，CHECKSUM 命令用于验证内容。 CHECKSUM 是在传输之后对整个表、在隔离了该行的新表上以及在应用 LEFT 运算符截断字符串之后进行的。 每次，新旧服务器的结果都是相同的，这表明原始数据在字节级别上应该完全相同。

CHECKSUM TABLE `test`

我检查了结构，它也完全一样。

SHOW CREATE TABLE `test`

这是结构：

CREATE TABLE test ( item varchar(32) COLLATE utf8_unicode_ci NOT NULL, amount mediumint(5) NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

该字段的类型为：

`item` varchar(32) COLLATE utf8_unicode_ci NOT NULL

这是我在 PHP 中的连接代码：

$sql = new mysqli($db_host, $db_user, $db_pass, $db_name);
if ($sql->connect_error) {
  die('Connect Error ('.$sql->connect_errno.') '.$sql->connect_error);
}

当我用一个简单的查询 go 检索 PHP 中的数据时：

SELECT * FROM `test`

数据显示如下：

§10

在旧服务器/主机上，我得到以下原始字节序列：

Decimal: -194-167-108-79-
HEX: -C2-A7-6C-4F-

在新服务器上，我在开头得到了几个额外的字节：

Decimal: -195-130-194-167-108-79-
HEX: -C3-82-C2-A7-6C-4F-

为什么完全相同的原始数据、表结构和查询会在两台服务器之间返回不同的结果？ 我应该怎么做才能确保结果在未来尽可能一致？

Answer 1

§lO是 §lO 的“ §lO ”。 我认为后者（3 个字符）是“正确的”？

原始数据看起来像这样（在两种情况下，当我显示它时）

是伪造的，因为用于显示它的技术可能与编码混淆。

由于 3 个字符变成 4，然后变成 6，你可能有“双重编码”。

这讨论了“双重编码”是如何发生的：UTF-8 字符出现问题； 我看到的不是我存储的

如果您提供更多信息（ CREATE TABLE 、十六进制、迁移数据的方法等），我们也许能够进一步解开您的混乱局面。

更多的

使用 mysqli 时，执行$sql->set_charset('utf8');

（HEX 证实了我的分析。）

迁移方法涉及在新服务器上运行相同的 CREATE TABLE 查询

它之前是否有一些字符集设置，如mysqldump ？

然后使用一系列 INSERT 命令逐行插入数据。

你能得到文件中一些重音字符的十六进制吗？

...校验和...

好的，相同的排除了一件事。

CHECKSUM 是在...一个新表上完成的，该行被隔离

你是怎么做到的？ SELECTing行可能会修改文本，从而使测试无效。

表明原始数据在字节级别应该完全相同。

为了检查表中的数据， SELECT HEX(col)...是绕过所有可能发生的字符集转换的唯一方法。 请为具有非 ascii 字符的某些列提供 HEX（例如给出的示例）。 并对 HEX output 进行校验和。

并提供SHOW VARIABLES LIKE 'char%';