MySQL：联合查询在 MySQL 5.5 上失败，适用于 MySQL 5.1答案

【问题标题】：MySQL: union query fails on MySQL 5.5, works on MySQL 5.1MySQL：联合查询在 MySQL 5.5 上失败，适用于 MySQL 5.1
【发布时间】：2012-02-08 23:25:25
【问题描述】：

我遇到了顽固的 MySQL 查询问题。这是一个相当长且复杂的查询，对此感到抱歉。我真的尽我所能自己找到它，但我可以在这里使用。

以下查询用于模拟 information_schema 中的列信息和名为 nexedit_schema 的表中的列信息的完全外连接。 PHP 变量 $db 包含包含后一个表的目标数据库。

查询实际上在我自己的服务器（MySQL 5.1 版）上成功运行，但在朋友的服务器（MySQL 5.5 版）上运行失败。它声称我在“ON（schema_tables.db_table ...”附近有语法错误

我可能忽略了一些非常愚蠢的事情。有好心人帮帮我吗？

SELECT information_schema.tables.table_name, schema_tables.db_table, schema_tables.ne_page
  FROM information_schema.tables
  LEFT JOIN (
    (SELECT DISTINCT db_table, ne_page FROM {$db}.nexedit_schema)
    AS schema_tables)
  ON (schema_tables.db_table = information_schema.tables.table_name
    COLLATE utf8_unicode_ci)
  WHERE information_schema.tables.table_schema = '{$db}'
    AND information_schema.tables.table_name NOT LIKE 'nexedit_%'

UNION

SELECT information_schema.tables.table_name, schema_tables.db_table, schema_tables.ne_page
  FROM information_schema.tables
  RIGHT JOIN (
    (SELECT DISTINCT db_table, ne_page FROM {$db}.nexedit_schema)
    AS schema_tables)
  ON (schema_tables.db_table = information_schema.tables.table_name
    COLLATE utf8_unicode_ci)
  WHERE information_schema.tables.table_schema IS NULL
    AND schema_tables.db_table NOT LIKE 'nexedit_%'

GROUP BY information_schema.tables.table_name,schema_tables.db_table;

【问题讨论】：

Re：“这是一个相当长且复杂的查询，对此感到抱歉”：不要为此道歉——修复它。您是否尝试过手动替换 $db 的值并在 MySQL 命令行中运行查询？您是否尝试过剪掉UNION 的一个分支并查看另一个分支是否触发了错误？
后面的建议我没试过，等有结果我再汇报。
@ruakh 我只是尝试通过 phpMyAdmin 分别运行 2 个联合查询。它们都按预期运行，因此问题似乎出在 UNION 命令本身。有趣的是，第二个查询在这种特定情况下不会（也不应该）返回任何结果（尽管在其他情况下是必要的），这会以任何方式影响 UNION 吗？
您是否尝试过以其他方式进行简化？如果在第二个查询中删除 group-by 会发生什么？如果您删除其中一个联接（并且只对依赖于联接的任何字段使用一些固定值，例如NULL），会发生什么情况？如果删除 COLLATE utf8_unicode_ci 会发生什么？如果删除一些不必要的括号对会发生什么？
（但要回答你的问题——如果 MySQL 抱怨语法错误，那么它还没有接近发现第二个查询是否返回任何行的点，所以不，那不是问题。）

标签： mysql join syntax union

【解决方案1】：

这里不需要)：AS schema_tables)应该在AS之前

【讨论】：

好吧，你不能只删除 ) 而不删除与之配对的 (。这里的结构是JOIN ((SELECT ...) AS ...) ON (...)：括号比必要的多，但它们都是完美平衡的。
我在调试查询时添加了额外的括号，因为它适用于大多数安装，所以我想在完成后将它们留在那里。正如@ruakh 提到的，它们是平衡的。如果我要删除一些额外的括号，那会使查询更稳定吗？从理论上讲，这应该无关紧要，但也许它确实会产生我不知道的差异。
其实，没关系。毕竟这解决了它。删除 SELECT DISTINCT 之前的“（”和 ON 之前的“）”之一就可以了。这就是(SELECT ...) AS ... ON (...)。非常感谢！