查询一张表的数据是否存在于另一张表中
第一写法就是用in或者not in
例如
优缺点
优化后10秒内可以跑完.
思路 通过临时表创建索引用 空间换时间避免频繁读取原表信息
mysql删除原则
not exist 比not in执行效率高 （线上项目保持正确性,没有尝试网上有人推荐使用 not exist 由于改动大没有尝试）
truncate 比 delete执行效率高
在开始演示之前,我们先介绍下两个概念.
概念一,数据的可选择性基数,也就是常说的cardinality值.
查询优化器在生成各种执行计划之前,得先从统计信息中取得相关数据,这样才能估算每步操作所涉及到的记录数,而这个相关数据就是cardinality.简单来说,就是每个值在每个字段中的唯一值分布状态.
比如表t1有100行记录,其中一列为f1.f1中唯一值的个数可以是100个,也可以是1个,当然也可以是1到100之间的任何一个数字.这里唯一值越的多少,就是这个列的可选择基数.
那看到这里我们就明白了,为什么要在基数高的字段上建立索引,而基数低的的字段建立索引反而没有全表扫描来的快.当然这个只是一方面,至于更深入的探讨就不在我这篇探讨的范围了.
概念二,关于HINT的使用.
这里我来说下HINT是什么,在什么时候用.
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作,使她生成最优的执行计划.一般来说,优化器的执行计划都是最优化的,不过在某些特定场景下,执行计划可能不是最优化.
比如：表t1经过大量的频繁更新操作,（UPDATE,DELETE,INSERT）,cardinality已经很不准确了,这时候刚好执行了一条SQL,那么有可能这条SQL的执行计划就不是最优的.为什么说有可能呢?
来看下具体演示
譬如,以下两条SQL,
A：
B：
这里顺带说下,MySQL提供了自动更新和手动更新表cardinality值的方法,因篇幅有限,需要的可以查阅手册.
示例表结构：
表记录数：
这里我们两条经典的SQL：
SQL C：
SQL D：
那我们来看SQL C的查询计划.
我们加上hint给相同的查询,再次看看查询计划.
我们再看下SQL D的计划：
不加HINT,
加了HINT,
对比下以上两个,加了HINT的比不加HINT的cost小了100倍.
总结下,就是说表的cardinality值影响这张的查询计划,如果这个值没有正常更新的话,就需要手工加HINT了.相信MySQL未来的版本会带来更多的HINT.
你这涉及到union all,or 和in 及索引字段的,,,,
①.、对于索引列来最好使用union all,因复杂的查询【包含运算等】将使or、in放弃索引而全表扫描,除非你能确定or、in会使用索引.
上面都说的是单表的情况,所以你这个问题你给出语句信息,
并不能简单的说谁比in快的,,,,要看索引字段情况的
子查询优化策略
对于不同类型的子查询,优化器会选择不同的策略.
① 对于 IN、=ANY 子查询,优化器有如下策略选择：
semijoin
Materialization
exists
将派生表物化为内部临时表,再用于外部查询.
注意：update 和 delete 语句中子查询不能使用 semijoin、materialization 优化策略