前几天参加了一个公司的面试，到了后面面试官出了一个SQL相关的题目：
创新互联建站专注于企业成都营销网站建设、网站重做改版、长安网站定制设计、自适应品牌网站建设、成都h5网站建设、商城网站定制开发、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为长安等各大城市提供网站开发制作服务。
数据的形式类似于以下这样（表名为views）：
当时为了稳妥起见，我的第一反应是使用窗口函数，
然后面试官问：“还有没有什么简便的方法么？”
很明显他的意思是要用传统的groupby来完成这个查询，确实我之前的查询又是用窗口函数又是加了distinct确实是复杂一些。
于是我用group by再写了一遍。
看完我的查询之后，面试官又问了一句：“可以不需要使用嵌套查询吗？”
当时我的回答是”应该不行，如果不使用嵌套而直接在group by后面加having的话sql会报错，就和where如果使用别名查询就会报错一样“
后面面试完想了一下，发现自己当时回答得不好，不是正确的但也不完全错，不是正确的原因是按照sql的规则having后面是可以拿聚合函数做判断的，但是不完全错的原因是如果having用的是像我之前设置的别名来判断的话，确实是会出错的。（虽然mysql在5.6之后基于sql的规则对group by进行拓展，支持这种写法。但在其它sql上面用别名having还是不行的）
我们可以从SQL运行时各部分的执行顺序来进行分析，当我们选择执行一个SQL语句的时候，它会按照以下的顺序来进行操作，
这个执行顺序的设计是很巧妙的，我说一下我自己对于上述顺序的理解，
1. FROM
顾名思义，当执行查询语句的时候，首先需要知道的是它需要哪些表，正如我们去一个地方需要知道它的具体位置一样。如果需要多个表的话在这一部分也需要按照一定的顺序进行表的join操作。
2. WHERE
当确定我们需要读取哪一张表（或者多张表）的数据之后，我们就需要进行where的filter操作，根据filter尽量减少读取的数据数量。
那么问题来了，为什么where的优先级要比group by，having, select之类的要高呢？
第一个原因是可以减少不必要的查询量，加快执行语句的速度，类似于Apache Spark在对查询语句进行逻辑优化时需要用到的谓词下推类似的道理。举个栗子，比如我们可能需要userid从100到300的用户对于某一个页面的浏览次数，那么如果先执行group by再执行where的话，userid小于100的用户的数据也会被汇总进去，但实际上这些部分的数据是完全不需要的，计算它们完全是浪费系统资源（而且group by操作本身就是很耗资源的操作）
3. GROUP BY
在完成where操作的过滤之后，如果语句中有group by的话则会对过滤后的数据进行聚合操作，聚合操作是多对一的转换，因此在聚合操作过后，除了用于group by的字段之外，其它字段的原始数据将会丢失，只能得到它们相应的聚合结果（比如sum（）， avg（）这样）
在完成聚合操作之后，参与group by的字段以及其它字段对应的聚合值已经处于已知状态，后续的操作可以直接使用它们。
4. HAVING
HAVING操作主要做的是对group by之后的分组结果进行过滤，可以根据参与group by的字段进行过滤，也可以根据其它字段的聚合值进行过滤。（因为聚合值在这里已经算是已知数据）因此这里是可以拿聚合函数做判断的，比如最开始的那个查询的例子，可以直接写成以下的形式，
HAVING并不是一定要和group by成对出现的，它也可以单独存在，在没有group by的时候，此时默认只有一个组，但是需要注意的是这时having里面参与过滤的字段需要在select里面存在，不然having会不知道这是分组里面的内容而导致报错。
5. SELECT
选取结果集中相对应的字段，在select中为字段设置的别名在此阶段及之后的操作中生效。
6. DISTINCT
去重操作，放在select之后有个原因是去重操作是要根据select里面所选字段来进行的。
7. ORDER BY
对得到的结果按照特定字段顺序进行排列，这里可以使用别名
8. LIMIT
设置显示结果集中的几条数据
通过分析MySQL中各部分的执行顺序，我们就不难理解为什么where不能有别名，而having可以用聚合函数来判断的原因，而且借此机会重新温习一遍SQL各部分对应的功能，加深理解，可以说是一举两得。
当同一台主机搭建多个mysql实例，在利用service mysql start时候，会因为读取/etc/my.cnf导致启动报错。而网上说的/etc/my.cnf - /etc/mysql/my.cnf - /usr/local/mysql/etc/my.cnf - ~/.my.cnf顺序并没有鸟用，有时会花费很长时间定位，现从启动脚本分析mysql的启动原理。
一、我的环境共存在三台3台mysql
1）、第一台为rpm包装的mysql（一般系统会自带mysql就是rpm安装的），默认安装路径为/usr/local,默认的配置文件为/etc/my.cnf。
2）、其他两台新增mysql安装路径分别为：/home/mysql-5.7.21、/home/mysql-5.7.21_two，配置文件分别为：/home/mysql-5.7.21/my.cnf、/home/mysql-5.7.21_two/my.cnf
3）、启动脚本：我的习惯是将$MYSQL_HOME/support-files/mysql.server复制到/etc/init.d/下面，并重命名，如下图：mysql1和mysql2分别为两台新增mysql的启动脚本，可利用service mysql1 start和service mysql2 start启动(分别修改了--basedir和--datadir)。
二、以/etc/init.d/mysql1分析启动脚本
1）、启动脚本的核心思想是，先利用（parse_server_arguments `$print_defaults $extra_args mysqld server mysql_server mysql.server`）语句获取配置文件中的参数。然后利用（$bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args /dev/null ）启动mysql实例。
2）、问题的关键点就在$print_defaults $extra_args mysqld server mysql_server mysql.server
故我的获取配置文件的参数实际是通过如下语句获取：
但是此时存在一个问题：
脚本的执行结果显示，不仅读取到了/home/mysql-5.7.21/my.cnf中的内容，还读取到了/etc/my.cnf中的参数。那么mysql1脚本只修改--basedir和datadir显然不行，仍然会由于/etc/my.cnf导致问题。其实如果~/.my.cnf如果也存在的话，~/.my.cnf中的参数也会被读取出。
这时候就需要用到"--defaults-file"参数
再回到$extra_args参数的获取脚本，会发现只要$basedir/my.cnf存在就会被同时读取，而我们的目的是只读取这个配置文件。
所以：我们可以修改下这个脚本，将extra_args的值变为 --defaults-file =$basedir/my.cnf，这样煤气启动就只读取这个配置文件，如果$basedir/my.cnf不存在或没有可读权限，直接提示报错。
三、$bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args /dev/null 启动时
1）、新的问题：
我的$basedir/my.cnf中明明没有ndb-connectstring=172.16.31.111参数，怎么会提示这个变量无法识别呢？
查看/etc/my.cnf发现这个参数确实存在，funk！！！但上面明明只读取$basedir/my.cnf中配置文件了啊！
2）、查看mysqld_safe的使用方法
也就是，需要在利用mysqld_safe启动时候再指定下配置，让其只读取$basedir/my.cnf。故在启动行加入--defaults-file="$basedir/my.cnf"
总结：在将mysql.server复制到/etc/init.d后，有删除需要配置修改，到此为止新增的mysql已经能够读取指定配置文件启动
遗留问题：
为什么读取指定配置文件后，$bindir/mysqld_safe还是读取/etc/my.cnf？故，还需对mysqld_safe做出debug分析，待补充，欢迎到时查看！
ocate my.cnf; 看看你的linux上有多少个my.cnf，一般都配置为/etc/my.cnf 然后再用show variables，看看 strace -e stat64 mysqld --print-defaults 这样子也行
