规范上说避免使用JOIN

避免使用JOIN和子查询的建议旨在提高数据库性能并改进设计。
两者要谨慎使用，主要有以下两个原因：第一，合理的数据库设计应该保证业务需求不需要JOIN或者子查询。
其次，如果您确实需要使用它，您应该探索是否有替代方案来减少对JOIN和子查询的依赖。
JOIN和子查询被弃用的主要原因是性能问题。
具体分析如下：使用JOIN时，性能差异比较显着，具体取决于有向表是否使用索引。
如果有向表使用索引，则执行过程涉及N+N*2*log2M次操作，其中N为有向表行数，M为有向表行数。
如果不指定驱动表，MySQL会自动选择它，但不能保证100%最优选择。
使用JOIN时，性能通常优于多个表的强制分区。
扫描的总行数不变，但客户端与MySQL的交互增加，数据需要自行处理。
如果向量表不使用索引，使用JOIN会降低性能。
MySQL将JOIN_BUFFER中的数据读取到内存中进行比较。
复杂度是N+M次检查和M*N次内存判断，如果JOIN_BUFFER无法容纳数据，就会被分割多次，增加整体复杂度。
子查询分为链接子查询和不相关子查询。
执行链接子查询的过程涉及两级循环，总共查询次数为m*n；不相关子查询的执行顺序是先子查询，再外层查询，不依赖于外层查询的结果。
JOIN和子查询在执行过程中都会涉及大量的扫描和比较操作，导致性能较差。
子查询可能需要创建临时表，这会影响性能。
可以通过EXPLAIN命令观察子查询对临时表的使用情况。
总之，生产环境中应该避免JOIN和子查询。
如果您需要选择两者之一，通常建议使用JOIN。
使用JOIN时，一定要使用小表作为驱动表，并使用有向表的索引，但需要评估是否会增加数据库的负担，避免对环境造成负面影响。
الإنتاج.

那个mysql子查询和连接查询一般常用哪个谁效率高些

子查询优化策略

对于不同类型的子查询，优化器会选择不同的策略。

1.对于IN,=ANY子查询，优化器有以下策略选项：

半连接

创建

存在

2.对于NOTIN和<>ALL子查询，优化器有以下策略选项：

M放大

存在

3.对于派生的派生表，优化器有以下策略选项：

merge_results，将派生表合并到外部查询中（5.7中引入）；

将派生表Materialize到内部临时表中，然后将其用于外部查询。

注意：update和delete语句中的子查询不能使用半连接和创建优化策略