MySQL optimizer hint 怎样限定连接顺序

MySQL optimizer hint 限定连接顺序时，先决定要锁定多少关系：JOIN_ORDER 只约束列出表的相对次序，JOIN_PREFIX 固定开头，JOIN_SUFFIX 固定末尾，JOIN_FIXED_ORDER() 按当前查询块的 FROM 次序约束全部表。只确认部分关系时，不必直接固定整条连接链。

官方地址：https://www.mysql.com/

以下以 MySQL 8.4 为范围。表名、字段和参数为原创示例，假定现有 customers(id, region_code)、orders(id, customer_id) 和 order_lines(order_id, quantity)；请按自己的结构替换。本文未执行 SQL，不提供虚构计划或性能收益。

只限定有证据支持的连接关系

例如只希望客户表 c 在订单表 o 之前参与连接，明细表 l 的位置仍交给优化器，可以从下面的最小写法开始。提示写在 SELECT 后的特殊注释中，普通注释不具备同样含义。

-- 仅约束 c 与 o 的相对次序，不要求两者紧邻
EXPLAIN FORMAT=TRADITIONAL
SELECT /*+ JOIN_ORDER(c, o) */
  c.id, o.id AS order_id, l.quantity
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
JOIN order_lines AS l ON l.order_id = o.id
WHERE c.region_code = 'EAST';

-- 紧接上一个 EXPLAIN，查看提示使用信息
SHOW WARNINGS;

这里没有声称 c 必须是第一张表，也没有声称 l 必须排在最后。将 JOIN_ORDER 理解成“固定前缀”，会比原意多加约束。假如你实际只知道某个过滤条件有选择性，仍应先比较实际计划，不把假设写成结论。

四种提示各自保留多少选择空间

表中“通常”仍受 const 表和连接语义等限制。它们不是绕过 SQL 语义的强制执行器。JOIN_FIXED_ORDER 不列参数表名；不要把 JOIN_ORDER 的表列表直接搬进括号。

别名和查询块决定提示绑定对象

有别名就使用别名，不使用原表名；提示里的表名也不加库名前缀。查询块决定了这份约束属于哪一层 SELECT。下面使用 QB_NAME 给同一查询块命名，把提示对象写清楚：

-- 给当前查询块命名，并用别名指定同一块的前缀
EXPLAIN FORMAT=TRADITIONAL
SELECT /*+ QB_NAME(order_lookup) JOIN_PREFIX(@order_lookup c, o) */
  c.id, o.id AS order_id, l.quantity
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
JOIN order_lines AS l ON l.order_id = o.id
WHERE c.region_code = 'EAST';

-- 在同一连接立即读取扩展说明，不插入其他查询
SHOW WARNINGS;

命名不是保证子查询会合并、物化或转成某种结构。包含多层 SELECT 的业务查询，应先画清查询块归属，再引用对应别名。不要以为外层写一个提示就能任意排列内层所有表。

用最小范围的计划对照选择方案

先保存原 SQL，再一次只换一个提示，保持查询参数与比较环境一致。不要同时固定顺序、强制索引并修改过滤条件，否则即便计划变化，也很难判断由哪项改变引起。

上面明确采用 TRADITIONAL 格式：同一个简单查询块的表行顺序可以帮助观察连接次序。还要同时看 type、key、rows、filtered 和 Extra，而非只看谁排第一。rows 是估算值，不是本次查询已处理的真实行数；key 反映选中的索引，与连接顺序不是同一个维度。

SHOW WARNINGS 中的扩展 EXPLAIN 信息可以辅助识别采用的提示；其中可能含重写后的查询和内部表达。不要把它当作可直接回放的业务 SQL。保存计划与提示信息，是为了区分“写了提示”“提示被采用”“实际负载更合适”三个不同结论。

哪些语义限制不能靠提示越过

const 表仍会被放在前面；连接顺序提示不能改变它的位置。外连接也有语义依赖：不能为了符合希望的驱动顺序，随意把 LEFT JOIN 改成 INNER JOIN。这可能改变缺失匹配行的保留规则。

冲突提示、循环依赖或与连接类型不兼容的约束可能被忽略，而且不一定产生警告。“没有 warning”不能单独证明成功。每种前缀或后缀只应保留一份明确意图，不靠堆叠互相矛盾的提示碰运气。

对于真实优化，我建议把提示作为可移除的局部干预：记录使用理由、代表参数和撤销条件。数据分布改变、索引变更或版本升级后，原先合适的顺序也可能不再合适。这里给出的是采用策略，不是对读者数据库的性能保证。

连接顺序提示的采用速查

JOIN_ORDER 会固定结果行排序吗？

不会。连接顺序是优化器层面的表关系约束，结果排序应由 ORDER BY 表达，不能依赖碰巧观察到的返回顺序。

提示能同时指定要用的索引吗？

这四个提示讨论的是连接次序，不替代索引选择。需要研究索引时，应作为另一项独立对照，避免一次变更多个因素。

取消限制要改全局配置吗？

这些是语句内提示。保留原 SQL，撤销相应提示即可移除这次人为约束；若应用还叠加了其他提示，应单独追踪，不假定整个计划必然完全复原。

参考：MySQL 优化器提示、EXPLAIN 输出格式、扩展 EXPLAIN、嵌套连接优化。