前言
这几天在做数据分析的时候，数据要自己从数据库里面拿(之前都是别人把数据库导出来给我的说)，心塞。还好之前学的SQL没有忘掉，咱连上数据库就开始写查询语句。之后就栽坑里了，执行的结果与预期的结果相差甚远，哭~。下面我把我栽坑的原因写下来，以帮助到可能会在此栽坑的开发人员。
正文
SQL作为一门的声明式语言，它的运行方式并不同于我们所熟知的命令式程序语言。
在此废话几句，解释下什么是声明式语言，什么是命令式语言。
声明式语言：告诉计算机我要什么结果，至于怎么做，那是它的事情。
命令式语言：告诉计算机怎么做，它会返回按照我要求做之后的结果。
执行顺序的坑
按照上面的解释，大概你也会了解一些为什么有些SQL编程出来的东西和你实际想要的结果是有些出入的，因为我们在潜意识中的行为动作是按照命令式编程的思维方式思考的。就好像用户在告诉计算机：“先执行第一步，再执行第二步，并在执行第二步之前先检查一下是否满足条件A 和条件B ”。例如，我们有时候会在SQL中用变量传参、使用循环语句、调用函数等等，会按照命令式编程的思维编写。然而，敲黑板， SQL恰恰没有按照这种命令式编程的思维方式来处理问题。另外还有一点， SQL的执行顺序并不参照语法顺序 。下面表格【1】能帮你理解到这一点。
执行命令编写顺序执行顺序SELECT18DISTINCT(等)29FROM31JOIN43ON52WHERE64GROUP BY75WITH86HAVING97ORDER BY1010LIMIT1111.........
也就是说在一个SQL语句开始执行的时候，最先执行的总是FROM操作，最后执行的是LIMIT操作，在执行过程中，每一个操作都会产生一张虚拟的表，每一个虚拟的表都会作为下一步处理的输入，直至最后一步操作前，这些虚拟的表对于用户都是透明的，最后一步的操作结果产生的表作为最终的输出返回给用户。
执行时使用的变量也有坑
在SQL中，用户不只是可以使用系统中提供的变量，用户也可以自定义一些变量以供快速开发使用。
对于一些语句中，比如SELECT，在使用用户自定义变量时会得到期望的效果，但是，这个是很不稳定的。比如下面的语句，按照命令式编程思想地会认为MySQL会在第一轮和第二轮查询的时候，会给 @b 附上值，之后 @b 显示的是 @a 前两次的数值，但是事实上， @b 会一直为0(不同的SQL解释器的运行机制不同，结果可能不同)：
SET @a = 0;
SET @b = 0;
SELECT
@b,
@b=@a,
@a:= @a + 1
FROM
sys.sys_config;
除此之外，还有另一个问题。变量的默认返回类型由语句开始时的类型决定的，正如下面的例子：
SET @a='test';
SELECT @a,(@a:=20) FROM tbl_name;
上述的SELECT语句中，MySQL会报告给客户端第一列的字段类型为字符串，同时将所有对@a变量的使用均转换为字符串处理，尽管在SELECT语句中将@a变量设置为数字类型。在SELECT语句执行后，@a变量才会在下一个语句中识别为数字类型。为了避免上述问题的发生，要么不在同一个语句中同时赋值并使用变量，要么在使用之前，将变量设置为0，0.0或者''，以确定它的数据类型。【2】
原文中有这样的一句话
In a SELECT statement, each select expression is evaluated only when sent to the client. This means that in a HAVING , GROUP BY , or ORDER BY clause, referring to a variable that is assigned a value in the select expression list does not work as expected.
译
在SELECT语句中，每个选择表达式仅在发送给客户端时才被计算。 这意味着在HAVING，GROUP BY或ORDER BY子句中，引用在选择表达式列表中指定值的用户自定义变量不能按预期工作。 也就是说用户自定义变量的值是在结果集发送到客户端后才计算的
这里有一种解释是：“MySQL优化器在某些场景下可能会将这些变量优化掉，这可能导致代码不按预想的方式运行。”
后记
关于用户自定义变量，如果运用的好，能够写出高效简洁的SQL语句，如果运用不当，也可能把自己给坑了(比如我? 哭~)。这个完全取决于使用它的人。
閱讀更多 Java高併發框架 的文章
