没时间了ngu 置顶2019-01-30join这种用的多的，看完还是有很大收获的。像之前讲的锁之类，感觉好抽象，老是记不住，唉。作者回复: 嗯嗯，因为其实每个同学的只是背景不一样。
这45讲里，每个同学都能从部分文章感觉到有收获，我觉得也很好了😆
不过 锁其实用得也多的。。
我以前负责业务库的时候，被开发同学问最多的问题之一就是，为啥死锁了^_^ 15
2019-01-30老师好，回答本期问题：如果驱动表分段，那么被驱动表就被多次读，而被驱动表又是大表，循环读取的间隔肯定得超1秒，这就会导致上篇文章提到的：“数据页在LRU_old的存在时间超过1秒，就会移到young区”。最终结果就是把大部分热点数据都淘汰了，导致“Buffer pool hit rate”命中率极低，其他请求需要读磁盘，因此系统响应变慢，大部分请求阻塞。作者回复: 👍
4 77
2019-01-31因为 join_buffer 不够大，需要对被驱动表做多次全表扫描，也就造成了“长事务”。除了老师上节课提到的导致undo log 不能被回收，导致回滚段空间膨胀问题，还会出现：1. 长期占用DML锁，引发DDL拿不到锁堵慢连接池； 2. SQL执行socket_timeout超时后业务接口重复发起，导致实例IO负载上升出现雪崩；3. 实例异常后，DBA kill SQL因繁杂的回滚执行时间过长，不能快速恢复可用；4. 如果业务采用select *作为结果集返回，极大可能出现网络拥堵，整体拖慢服务端的处理；5. 冷数据污染buffer pool，block nested-loop多次扫描，其中间隔很有可能超过1s，从而污染到lru 头部，影响整体的查询体验。作者回复: 👍很赞
之前知识点的也都加进来啦 47
2019-01-30对被驱动表进行全表扫描，会把冷数据的page加入到buffer pool.,并且block nested-loop要扫描多次，两次扫描的时间可能会超过1秒，使lru的那个优化失效，把热点数据从buffer pool中淘汰掉，影响正常业务的查询效率作者回复: 漂亮👍
17
2019-01-30早上听老师一节课感觉获益匪浅作者回复: 好早呀🤝
12- 2019-01-30林老师，我没想清楚为什么会进入young区域。假设大表t大小是M页>old区域N页，由于Block Nested-Loop Join需要对t进行k次全表扫描。第一次扫描时，1~N页依次被放入old区域，访问N+1页时淘汰1页，放入N+1页，以此类推，第一次扫描结束后old区域存放的是M-N+1~M页。第二次扫描开始，访问1页，淘汰M-N+1页，放入1页。可以把M页想象成一个环，N页想象成在这个环上滑动的窗口，由于M>N，不管是哪次扫描，需要访问的页都不会在滑动窗口上，所以不会存在“被访问的时候数据页在 LRU 链表中存在的时间超过了 1 秒“而被放入young的情况。我能想到的会被放入young区域的情况是，在当次扫描中，由于一页上有多行数据，需要对该页访问多次，超过了1s，不管这种情况就和t大小没关系了，而是由于page size太大，而一行数据太少。
作者回复: 你说得对，分两类情况，
小于bp 3/8的情况会跑到young，
大于3/8的会影响young部分的更新 1 11 
2019-01-30这个专栏受益匪浅，老师再搞个内核源码专栏：） 9
2019-01-30年底了有一种想跳槽的冲动 身在武汉的我想出去看看 可一想到自身的能力和学历 又不敢去了 苦恼...作者回复: 今年这情况还是要先克制一下^_^
先把内功练起来😆 9
2019-01-30老师您好，left join 和 right join 会固定驱动表吗？作者回复: 不会强制，但是由于语义的关系，大概率上是按照语句上写的关系去驱动，效率是比较高的
8
2019-01-31explain select * from t1 straight_join t2 on (t1.a=t2.a) where t1.a < 50;
老师, 这条sql为什么t1.a的索引没有用上, t1还是走全表作者回复: 如果数据量不够多，并且满足a<50的行，占比比较高的话，优化器有可能会认为“还要回表，还不如直接扫主键id”
1 7- 2019-01-30join在热点表操作中，join查询是一次给两张表同时加锁吧，会不会增大锁冲突的几率？
业务中肯定要使用被驱动表的索引，通常我们是先在驱动表查出结果集，然后再通过in被驱动表索引字段，分两步查询，这样是否比直接join委托点？作者回复: join也是普通查询，都不需要加锁哦，参考下MVCC那篇；
就是我们文中说的，“分两步查询，先查驱动表，然后查多个in”，如果可以用上被驱动表的索引，我觉得可以用上Index Nested-Loop Join算法，其实效果是跟拆开写类似的 1 6 
2019-01-30业务逻辑关系，一个SQL中left join7，8个表。这我该怎么优化。每次看到这些脑壳就大！作者回复: 😓
Explain下，没用用index nested-loop 的全要优化 1 5
2019-03-03老师，想问一下，如果是“一对多”的多个表进行join的话，应该选择“多”的表作为驱动表，还是选择“一”的表作为驱动表呢？作者回复: 如果有严格的一对多，而且要join够快一般都会在join 字段上创建索引，
这时候应该选“一”为驱动表 4
2019-03-03老师，这边想请教一个困扰很久的问题，用mysql经常会制定这么一个规则，不允许多表join。从实际情况看，几乎不太可能遵守这个规则，有个交易的业务场景涉及 用户表 300W、订单表 900W、支付表 900W，每次需要查一个用户下面的订单信息可能就有点慢了，但是还能接受，如果是查询一个团体的订单信息，这个量就非常可观了,查询有时候根本返回不了结果。根本无法避免多表Join，所以想问问老师，在这种需要多表Join业务场景下，如何设计表，来提升性能？或者有这方面推荐的资料可以参考的作者回复: 我的建议就是用好NLJ和BKA算法😆
4
2019-02-19文中解释NLJ和BNL时间复杂度相同，都是M*N。但是对于BNL性能好于NLJ的原因只是提到:"BNL的判断是在内存中操作，速度上会快很多，性能也更好"。请问老师？这句话的言外之意是: NLJ的判断不是在内存中操作吗？不将数据加载到内存，CPU如何进行判断呢?作者回复: 这个我在答疑文章中展开哈，其实还是“内存数据是从哪里来的”的问题。
我们这里说的是BNL比Simple nested loop 快哈 1 4
2019-02-09用那个作为驱动表，mysql会自己优化么？作者回复: 会的
4
2019-07-23老师，既然MySQL会自己优化使用哪个表当驱动表，那程序员在写jion语句时就不用纠结该写A jion B还是B jion A了吧 2
2019-06-14老师好，对于大数据量的多表使用join连接查询，有好多and条件，and是来自不同的表，查询80万的数据量需要0.4s，怎么优化下呢？
Using union(PRIMARY,idx_secoo_order_id); Using where; Using filesort
我的sql语句最后都使用order by id了，但是为啥Extra还会出现Using filesort 2
2019-03-12专栏已经更新完毕，首先谢谢老师；有以下几个小问题，希望老师有时间能够看到。
1.普通的join查询是被执行器优化执行过的吧？但是优化执行是否做到最好呢？怎么验证一下优化过程用的是那种方式呢？是用两个表互换explain一下吗？
2.这种查询优化在Mysql哪个版本中做了较大的加强。
3.SELECT * FROM t1 STRAIGHT_JOIN t2 ON (t1.a=t2.b); （t1是以a为索引的100行数据，t2中b非索引1000条数据）t1做了驱动表，属于BNL情形；如果用t2作为驱动表，t1的a索引就可以用，属于NLJ情形，选择哪个表作为驱动表更好呢？作者回复: 1. 对，explai
2. 如果你写了STRAIGHT_JOIN，那没得选啦，就是t1做驱动表。
这种情况，如果你改用join，应该会选t2做驱动表 2- 2019-03-04如果我产品表有十条数据，订单表有一万条数据。
为什么我用订单表作为驱动表会比用产品表作为驱动表速度快呢？作者回复: 要看索引😓
2