作者回复: 发条橙子同学的问题:
问题1:你回答得比我回复的答案还好!👍🏿
问题2:这个后面我们展开哈,要配图才能说得清😄
问题3:回答得也很好,需要注意的是255这个边界。小于255都需要一个字节记录长度,超过255就需要两个字节
你的问题:#好问题_#
1. 排序相关的内存在排序后就free掉还给系统了
2. 读的时候加了写锁的
3. 堆排序要读所有行的,只读一次,我估计你已经理解对了😄
作者回复:
不仅对,而且非常好!👍👍
把两个知识点连起来了。是的:
1. rows_examined就是“server层调用引擎取一行的时候”加1;
2. 引擎内部自己调用,读取行,不加1;
再补充一个例子:
加索引的时候,也要扫描全表,但如果是inplace DDL(@第13篇),你会看到扫描行数是0,也是因为这些扫描动作都是引擎内部自己调用的。
作者回复: 是的。
这个我也盲点了。
但是细想MySQL 选择这个策略又是合理的。
我需要再更新一下专栏内容
作者回复: 最怕的回答“历史原因”、“大家都这么做的所以…”、“别人要求的” 😄
作者回复: 从业务上砍掉功能,这个意识很好👌👍🏿
作者回复: 👍🏿
作者回复: 你是说图14这里对吧,
这里update语句自己是当前读,但是它没有更新数据;
所以之后的查询还是看不到(1,3)这个版本。
好问题👍
作者回复: 嗯 where和 order都会共同影响哦,今天这篇你要再看看最后加了联合索引以后,语句的执行逻辑
Analyze table 立功啦😄
作者回复: 1. 需要的字段的定义大小的和
2. 好问题。首先取决于使用的算法。
a) 如果是全字段排序就是select字段+where字段+order by字段,
b) 如果是row_id排序,就是order by字段+row_id
作者回复: !!!
你说的对
我验证的是statement格式。
MySQL 看来选了不错吧路径。
这个我之前真不知道😓
多谢
作者回复: 分页这个再考虑考虑哈😄
作者回复: 1. 为什么这么说呢?
2. 对的
作者回复: 你说的这样场景,加上create_time索引的话,是可以加速的呀,
语句是这样吗?select * from t order by create_time desk limit 100? 如果是这样,创建索引有用的。
问题二后面会有文章会说哈
问题三 嗯,这个也会安排文章说到
作者回复: 好问题,明天见 😁
(明天的一篇也是跟排序有关的哦)
作者回复: 要是排序就结果不符合order by 的语义逻辑了…