join链式写法是唯一可靠方式，三张表以上必须平铺连续join，主表放from后逐级关联，中间表必须显式参与，所有on字段须建索引且避免select*。
JOIN 链式写法是唯一可靠方式，别指望子查询或嵌套视图能高效处理多级关联。
三张表以上必须用连续 JOIN，不能靠子查询拼接
常见错误是把两表关联结果当临时表再 JOIN 第三张表——MySQL 不支持 FROM 子句里直接写带 JOIN 的子查询（除非加括号和别名），而且性能极差。
正确做法是平铺所有 JOIN，按逻辑顺序从主表开始逐级连接：
• 主表（如 users）放 FROM 后
• 每个后续表用 JOIN ... ON 显式关联上一表或主表
• 所有 ON 条件只写字段匹配关系，不塞过滤条件
LEFT JOIN 多级时，每个 ON 必须独立写清关联路径
比如查用户 → 订单 → 商品 → 分类，容易误写成：LEFT JOIN products p ON o.product_id = p.id AND p.category_id = c.id —— 这会报错，因为 c 表还没引入。
必须分步：
• 先 LEFT JOIN orders o ON u.id = o.user_id
• 再 LEFT JOIN products p ON o.product_id = p.id
• 最后 LEFT JOIN categories c ON p.category_id = c.id
漏掉任一 ON 或错连字段，结果要么空，要么出现意外重复行。
中间表（多对多）必须显式出现在 JOIN 链中
学生选课这类场景，students 和 courses 不能直连，必须把中间表 student_course 当作一级实体参与连接：
• 错误：SELECT s.name, c.title FROM students s JOIN courses c ON ???（没路径）
• 正确：SELECT s.name, c.title FROM students s JOIN student_course sc ON s.id = sc.student_id JOIN courses c ON sc.course_id = c.id
中间表的两个外键字段（student_id、course_id）就是唯一连接枢纽，别试图绕过它。
性能崩溃点：没索引的关联字段 + SELECT *
四张表 JOIN 后数据量可能指数级膨胀，最容易卡死的两个地方：
• 所有 ON 字段（如 user_id、order_id、product_id）必须单独建索引，复合索引效果有限
• 绝对避免 SELECT *，尤其不要把大字段（TEXT、JSON）拖进结果集，它们不参与关联但会拖慢传输和内存占用
• 如果只查统计值（如订单数、平均金额），优先用 GROUP BY + 聚合函数，比全量 JOIN 再 COUNT 快得多
ON 条件的严格分层——少一个别名或错一层关联，MySQL 就会静默返回空结果或笛卡尔积，而不会报语法错。
