我们使用varchar（255）在mysql中存储“关键字”。我们面临一个问题，即mysql忽略所有尾随空格以便在“=”中进行比较。它确实在“like”比较中尊重尾随空格，但是如果它有一个“UNIQUE”索引，它不会让我们在varchar列中存储和不存在尾随空格的相同单词。
所以，我们正在考虑切换到varbinary。当列值中有多字节字符时，有人会建议可能会有什么影响吗？
答案 0 :(得分：2)
Andomar，
我们使用5.0.5版。所有mysql版本都忽略尾随空格进行比较。从手册：
所有MySQL排序规则都是类型 PADSPACE。这意味着所有CHAR和 比较MySQL中的VARCHAR值 不考虑任何尾随空格。 这适用于所有MySQL版本， 它是否没有区别 你的版本修剪尾随空格 来自存储之前的VARCHAR值 它们
此外，mysql认为带有/不带尾随空格的文本在索引中重复：
对于那些尾随垫的情况 字符被剥离或比较 如果列具有索引，则忽略它们 这需要唯一的值，插入 进入不同的列值 仅在尾随垫的数量 字符将导致a 重复键错误。例如，如果是 表包含'a'，尝试 store'a'会导致重复键 错误。
而且，我们绝对需要关键字索引。 所以，我想我们有两个选择：varbinary或text。我们将评估“text”的性能，以及varbinary的多字节功能。
答案 1 :(得分：0)
这是MySQL manual关于尾随空格的内容：
处理尾随空格是 版本依赖性。从MySQL 5.0.3开始， 尾随空格保留时 值存储和检索，在 符合标准SQL。之前 MySQL 5.0.3，尾随空格是 从值中删除 存储在VARCHAR列中;这个 意味着空间也不存在 从检索到的值。
由于你的问题是MySQL没有重复跟踪尾随空格，我认为你的版本低于5.0.3。考虑为您的列使用TEXT类型;这些保留了尾随空间。 TEXT将为您处理字符串的encoding and decoding，因此您不必担心多字节字符。
TEXT的执行速度比VARBINARY慢。如果实际数据显示性能不可接受，则可能必须选择VARBINARY（或BLOB）。在这种情况下，您可以将字符串存储在特定编码中，如UTF-8。只要所有客户端使用相同的编码，这对于多字节字符都可以正常工作。使用不同的区域设置测试您的客户：）
答案 2 :(得分：0)
除了尾随空间问题之外，MySQL中的UNIQUE INDEX将限制为767字节（对于3字节UTF8，这使得767 / 3~ = 255）。另见：