MySQL三种用户变量赋值语法差异解析：为何仅第三种生效？

嘿，我来帮你理清楚这三种写法为什么表现不同～

1. 完全报错的写法：SET赋值含关键字的变量 #

这种写法的问题出在变量名@delimiter上：

SET @N = 3; -- 取第3个单词
SET @delimiter = ' ';
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(`sentence`, @delimiter, @N), @delimiter, -1) FROM `test`;

DELIMITER是MySQL的保留关键字（用来修改语句分隔符的命令），当你直接写SET @delimiter = ' '时，MySQL的语法解析器会误把delimiter当成命令关键字，而非用户变量的一部分，从而抛出语法错误。如果要让这个写法生效，需要给变量名中的关键字部分加上反引号：

SET @N = 3;
SET @`delimiter` = ' '; -- 给变量名里的关键字加反引号
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(`sentence`, @`delimiter`, @N), @`delimiter`, -1) FROM `test`;

2. 不符合预期的写法：SELECT := 赋值 #

SELECT @N := 3;
SELECT @delimiter := ' ';
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(`sentence`, @delimiter, @N), @delimiter, -1) FROM `test`;

核心还是@delimiter的关键字问题：虽然这个写法不会直接报错，但MySQL解析时并没有正确完成赋值（把delimiter当成了关键字，忽略了变量赋值逻辑），最终@delimiter的值为NULL。当SUBSTRING_INDEX的分隔符参数是NULL时，函数会返回整个字符串，自然不符合“取第3个单词”的预期。

另外补充个小细节：就算变量名不含关键字，SELECT :=赋值也有潜在风险——如果SELECT语句没有返回任何行，变量不会被赋值（会保留之前的旧值），而SET和SELECT ... INTO则不会有这个问题。

3. 正常工作的写法：SELECT ... INTO 赋值 #

SELECT 3 INTO @N;
SELECT ' ' INTO @delimiter;
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(`sentence`, @delimiter, @N), @delimiter, -1) FROM `test`;

SELECT ... INTO是MySQL专门用来将查询结果赋值给用户变量的语法，它的解析逻辑更明确：MySQL会直接把@delimiter识别为用户变量，不会把delimiter当成关键字处理，因此能成功完成赋值。同时这种写法也避免了SELECT :=赋值时“无返回行则不赋值”的问题，所以能稳定得到预期结果。

内容的提问来源于stack exchange，提问作者Revious