我的项目需要从用户开始输入,左边的间距和单词右边的间距,例如'apple'.如果用户键入"apple"或"apple",无论是单词的左侧还是右侧是一个空格还是多个空格,我都需要以这种方式存储它.
此字段具有Unique属性,但我尝试在左侧插入带间距的单词,并且它可以正常工作.但是当我尝试在右边插入带有间距的单词时,它会修剪单词右边的所有间距.
所以我想在间距之后在单词的右边添加一个特殊字符.但我希望有一个更好的解决方案来解决这个问题.
CREATE TABLE strings
( id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
string varchar(255) COLLATE utf8_bin NOT NULL,
created_ts timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id), UNIQUE KEY string (string) )
ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
Cle*_*aar 11
问题是MySQL在进行字符串比较时会忽略尾随空格.请参阅 http://dev.mysql.com/doc/refman/5.7/en/char.html
所有MySQL排序规则都是PADSPACE类型.这意味着MySQL中的所有CHAR,VARCHAR和TEXT值都会进行比较,而不考虑任何尾随空格.
...
对于剥离尾随填充字符或比较忽略它们的情况,如果列具有需要唯一值的索引,则插入仅在尾随填充字符数量上不同的列值将导致重复键错误.例如,如果表包含"a",则尝试存储"a"会导致重复键错误.
(此信息适用于5.7;对于8.0,此信息已更改,请参见下文)
like运算符的部分给出了此行为的示例(并显示了like确实遵循尾随空格):
mysql> SELECT 'a' = 'a ', 'a' LIKE 'a ';
+------------+---------------+
| 'a' = 'a ' | 'a' LIKE 'a ' |
+------------+---------------+
| 1 | 0 |
+------------+---------------+
1 row in set (0.00 sec)
不幸的是,UNIQUE索引似乎使用标准的字符串比较来检查是否已经存在这样的值,因此忽略了尾随空格.这与使用无关,VARCHAR或者CHAR在两种情况下都拒绝插入,因为唯一检查失败.如果有一种方法使用like语义进行UNIQUE检查,那么我不知道.
你可以做的是将值存储为VARBINARY:
mysql> create table test_ws ( `value` varbinary(255) UNIQUE );
Query OK, 0 rows affected (0.13 sec)
mysql> insert into test_ws (`value`) VALUES ('a');
Query OK, 1 row affected (0.08 sec)
mysql> insert into test_ws (`value`) VALUES ('a ');
Query OK, 1 row affected (0.06 sec)
mysql> SELECT CONCAT( '(', value, ')' ) FROM test_ws;
+---------------------------+
| CONCAT( '(', value, ')' ) |
+---------------------------+
| (a) |
| (a ) |
+---------------------------+
2 rows in set (0.00 sec)
您最好不要在此列上按字母顺序排序,因为排序将发生在字节值上,而不是用户期望的(大多数用户,无论如何).
另一种方法是修补MySQL并编写自己的归类,类型为NO PAD.不确定是否有人想这样做,但如果你这样做,请告诉我;)
编辑:同时根据https://dev.mysql.com/doc/refman/8.0/en/char.html,MySQL具有NO PAD类型的排序规则:
大多数MySQL排序规则都具有PAD SPACE的pad属性.例外情况是基于UCA 9.0.0及更高版本的Unicode排序规则,其pad属性为NO PAD.
和https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html
基于超过4.0.0的UCA版本的Unicode排序规则包括排序规则名称中的版本.因此,utf8mb4_unicode_520_ci基于UCA 5.2.0权重键,而utf8mb4_0900_ai_ci基于UCA 9.0.0权重键.
所以,如果你尝试:
create table test_ws ( `value` varbinary(255) UNIQUE )
character set utf8mb4 collate utf8mb4_0900_ai_ci;
您可以插入带有和不带尾随空格的值
您可以找到所有可用的NO PAD排序规则:
show collation where Pad_attribute='NO PAD';
这不是关于 CHAR 与 VARCHAR 的问题。SQL Server 在进行字符串比较时不考虑尾随空格，这在检查唯一键约束时也适用。所以并不是说你不能插入带有尾随空格的值，而是一旦插入，你就不能插入另一个带有更多或更少空格的值。
作为问题的解决方案，您可以添加一个保留字符串长度的列，并将长度和字符串值作为复合唯一键约束。
在SQL Server 2012中，您甚至可以将长度列设置为计算列，这样您就不必担心该值了。有关 SQL Server 2012 的示例，请参阅http://sqlfiddle.com/#!6/32e94 。（我敢打赌 MySQL 中也可能有类似的情况。）
您可能需要了解 VARCHAR 和 CHAR 类型之间的差异。
存储 CHAR 值时，会在右侧用空格填充到指定的长度。检索 CHAR 值时，除非启用 PAD_CHAR_TO_FULL_LENGTH SQL 模式，否则将删除尾随空格。
对于 VARCHAR 列，无论使用何种 SQL 模式，超出列长度的尾随空格都会在插入之前被截断并生成警告。对于 CHAR 列，无论 SQL 模式如何，都会以静默方式截断插入值中多余的尾随空格。
VARCHAR 值在存储时不会被填充。存储和检索值时会保留尾随空格，符合标准 SQL。
结论：如果要保留文本字符串右侧的空格，请使用 CHAR 类型（而不是 VARCHAR）。