4

我们使用 varchar(255) 在 mysql 中存储“关键字”。我们面临一个问题,mysql 忽略所有尾随空格以用于“=”中的比较目的。它确实尊重“like”比较中的尾随空格,但如果它有一个“UNIQUE”索引,它不允许我们在 varchar 列中存储带有和不带有尾随空格的相同单词。

因此,我们正在考虑切换到 varbinary。当列值中存在多字节字符时,任何人都可以建议可能会产生什么影响吗?

4

3 回答 3

2

安多马尔,

我们使用版本 5.0.5。所有 mysql 版本都忽略尾随空格进行比较。从手册:

所有 MySQL 排序规则都是 PADSPACE 类型。这意味着比较 MySQL 中的所有 CHAR 和 VARCHAR 值,而不考虑任何尾随空格。这适用于所有 MySQL 版本,您的版本是否在存储 VARCHAR 值之前修剪尾随空格并没有区别

此外,mysql认为索引中带有/不带尾随空格的文本重复:

对于去除尾随填充字符或比较忽略它们的情况,如果列具有需要唯一值的索引,则将仅在尾随填充字符数量上不同的值插入到列中将导致重复键错误。例如,如果表包含“a”,则尝试存储“a”会导致重复键错误。

而且,我们绝对需要一个关键字索引。所以,我想我们有两个选择:varbinary 或 text。我们将评估“文本”的性能,以及 varbinary 的多字节功能。

于 2009-06-17T07:03:25.520 回答
0

除了尾随空格问题之外,您在 MySQL 中的 UNIQUE INDEX 将被限制为 767 字节(对于 3 字节 UTF8,这使得 767/3 ~= 255)。也可以看看:

于 2011-05-11T18:39:49.390 回答
0

这是MySQL 手册中关于尾随空格的说明:

尾随空格的处理取决于版本。从 MySQL 5.0.3 开始,按照标准 SQL,在存储和检索值时保留尾随空格。在 MySQL 5.0.3 之前,当值存储到 VARCHAR 列中时,它们会从值中删除尾随空格;这意味着检索到的值中也没有空格。

由于您的问题说 MySQL 不代表尾随空格,我假设您的版本低于 5.0.3。考虑为您的列使用 TEXT 类型;这些保留尾随空格。TEXT 将为您处理字符串的编码和解码,因此您不必担心多字节字符。

TEXT 的执行速度确实比 VARBINARY 慢。如果实际数据显示性能不可接受,您可能必须选择 VARBINARY(或 BLOB)。在这种情况下,您可以将字符串存储为特定编码,如UTF-8。只要您的所有客户端都使用相同的编码,这对于多字节字符就可以正常工作。用不同的区域设置测试你的客户:)

于 2009-06-10T08:16:17.497 回答