【发布时间】：2010-11-01 17:10:15
【问题描述】：
我们使用 varchar(255) 在 mysql 中存储“关键字”。我们面临一个问题，mysql 忽略所有尾随空格以用于“=”中的比较目的。它确实尊重“like”比较中的尾随空格，但如果它有一个“UNIQUE”索引，它不允许我们在 varchar 列中存储带有和不带有尾随空格的相同单词。
因此，我们正在考虑改用 varbinary。当列值中有多字节字符时，任何人都可以提出什么含义吗？
【问题讨论】：
【发布时间】：2010-11-01 17:10:15
【问题描述】：
安多马尔，
我们使用版本 5.0.5。所有 mysql 版本都忽略尾随空格进行比较。来自手册：
所有 MySQL 排序规则都是类型 空间。这意味着所有 CHAR 和 比较 MySQL 中的 VARCHAR 值 不考虑任何尾随空格。 这适用于所有 MySQL 版本， 是否 您的版本修剪尾随空格 从存储前的 VARCHAR 值 他们
此外，mysql 认为索引中带有/不带有尾随空格的文本重复：
对于尾随填充的情况 字符被剥离或比较 如果列有索引，则忽略它们 需要唯一值，插入 进入不同的列值 仅在尾随垫的数量 字符将导致 重复键错误。例如，如果一个 表包含“a”，尝试 store 'a ' 导致重复键 错误。
而且，我们绝对需要一个关键字索引。 所以，我想我们有两个选择：varbinary 或 text。我们将评估“文本”的性能，以及 varbinary 的多字节功能。
【讨论】：
这就是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。只要您的所有客户端都使用相同的编码，这对于多字节字符就可以正常工作。请使用不同的区域设置测试您的客户:)
【讨论】：
-
这个答案有点误导，因为它完全忽略了 UNIQUE 索引的后果。有关更多信息，请参阅 ashweta 自己的答案
除了尾随空格问题之外，您在 MySQL 中的 UNIQUE INDEX 将被限制为 767 字节（对于 3 字节 UTF8，这使得 767/3 ~= 255）。另见：
【讨论】：