MySQL在使用HAVING子句时规定，HAVING必须配合GROUP BY子句使用，因此在没有GROUP BY子句的情况下使用HAVING子句是不符合SQL标准的。但MySQL为了灵活处理某些特殊场景，会自动将没有GROUP BY子句的SQL语句重写，增加一个虚拟的GROUP BY NULL子句，这样做可以让HAVING子句在形式上符合SQL标准。但是，这种做法其实只是在内部进行处理，结果等同于在查询结果中只返回一行数据，即结果集的第一行。
当对聚合函数MIN或MAX的使用进行探索时，可以发现一些有趣的现象。例如，在无GROUP BY的情况下，使用HAVING id=MIN(id)可以返回一行数据，而HAVING id=MAX(id)则返回空集。通过试验可以发现，MySQL在这种情况下实际上是把GROUP BY NULL当作LIMIT 1来处理，因此结果只返回了表中的第一条记录。
进一步测试中，我们可以尝试对其他字段使用MAX和MIN函数。比如上述例子中，若表t2中的字段a初始值为1和3，使用HAVING a=MAX(a)却能返回数据，而使用HAVING a=MIN(a)则返回空集。这看起来似乎与字段a的值本身有关。然而，从MySQL重写SQL语句的内部机制来看，这其实是一个由MySQL优化器在处理聚合函数时所展现的特定行为，并不是一个规则的错误。
HAVING子句应该在GROUP BY子句后使用，这样才能按照SQL标准对每个分组进行筛选。如果没有GROUP BY子句，MySQL会默认将结果集视为一个整体的单一分组，这时使用HAVING子句实际上就是对这个唯一分组的结果进行过滤。在使用MIN或MAX等聚合函数时，MySQL内部可能会根据函数的性质和字段值的不同来返回不同的结果，这通常是优化器为了提高查询效率而进行的优化策略。
由于这种行为在MySQL中并不是明确的特性，而是优化器根据SQL语句的上下文环境在后台进行的一些处理，因此在编写SQL查询时，强烈建议遵守标准SQL的规范，确保在使用HAVING子句时，前面加上GROUP BY子句，这样可以保证查询逻辑的正确性，并提高代码的可移植性。
对于 MySQL 中 HAVING 子句和 GROUP BY 子句的使用，还要注意以下几点：
1. 当使用 GROUP BY 子句时，如果没有在 SELECT 语句中明确列出所有非聚合列，查询可能会返回错误。这是因为 MySQL 需要确保每个分组中的非聚合列值都是一致的，否则结果集会不明确。
2. 使用聚合函数时，如 AVG、SUM、MIN、MAX、COUNT 等，可以将结果与某个聚合值进行比较。
3. 在使用 HAVING 子句时，应当确保正确理解分组的概念，以及分组内部进行聚合运算后进行过滤的逻辑。
在实际的数据库设计和SQL编写中，应当避免无意义的使用HAVING子句，特别是避免在没有GROUP BY子句的情况下使用HAVING子句，以保证查询的规范性和可维护性。如果仅仅需要进行行过滤，应当使用 WHERE 子句，这样可以提高查询性能，避免不必要的复杂度和潜在的逻辑错误。
