MySQL阅读笔记

什么是性能？
在这里不讨论这个问题，如果把查询看作是一个任务，那么它由一系列的子任务组成，每个子任务都会消耗一定的时间，那么优化 即：
1.消除子任务或者
2.减少子任务的执行次数，或者
3.让子任务运行的更快；

慢查询基础：
1.请求了不需要的数据 常见的 select *
2.是否扫描额外的记录：响应时间，扫描行数，响应行数；—使用索引覆盖扫描，重写sql，让优化器能够以更优化的方式去查询；使用单独的汇总表；

Mysql 从设计上让连接和断开连接都是很轻量级的，所以当有时候数据量很大我们可以将一个复杂查询分为多个简单查询；比如物理删除数据 定期清理大量数据时 如果用一个大的语句一次性完成的话 可能需要一次性锁住很多的数据耗尽系统资源 阻塞很多小但是很重要的查询，执行一下暂停一会，再执行下一次，将一个一次性的压力分散到一个很长的时间里，可以大大降低对系统的影响 同时减少锁的持有时间；

（注：Innodb的多版本并发控制 是基于两个隐藏的列中的系统版本号来比较的，锁则是每一次次独立操作锁住的资源 比如行 或者一个分片）

分解关联查询的好处：
让缓存的效率更改（Mysql 缓存） 因为对于关联查询来说某个表发生了变化那么 就无法使用查询缓存了；

同时这样相当于实现了哈希关联，而不是使用mysql的嵌套循环关联；在某些场景 哈希关联的效率要高很多；

MySQL执行一次查询到底做了些什么：

1.客户端发送一条查询给服务器；
2.服务器先检查缓存，如果命中，则返回缓存中的结果，否则进入下一阶段；
3.服务端将sql 解析生成一颗解析树解析时验证语法的正确性前后是否匹配，然后预处理进一步验证解析树是否合法比如名字别名是否歧义，再由优化器生成对应的执行计划比如重新定义关联表的顺序；
4.调用存储引擎的API 来执行查询；
5.将结果返回给客户端，同时将结果放入缓存；

需要注意的是上面这一个流程是”半双工“，即任意一个时刻要么由服务器向客户端发送数据，要么由客户端向服务端发起请求；

MySQL如何执行关联查询；
mysql的关联策略：对任何关联都执行嵌套循环关联操作；
即现在一个表中循环取出单条数据，然后再嵌套循环到下一个表中寻找匹配的行，依次下去，在最后一个行找到所有匹配的行，如果最后i一个行没有匹配到。则返回上一层关联表看看能否找到更多的关联记录；

基于这个理解给出mysql 的解析树，一颗左侧深度优化的树；

Mysql 的关联子查询
mysql的子查询实现的非常糟糕，最糟糕的是where条件包含in()的子查询，例如：

因为mysql对in()列表中的选项有专门的优化策略，mysql会将相关的外层表压到子查询中，它认为这样可以更高效率的查询，也就是说mysql 会被改写成下面的样子：
当外层表很大时性能就会特别糟糕，所以一般都使用inner join 代替 in()子查询

但是，并不是所有的关联子查询性能都会很差，有时候关联子查询会是性能很好的写法 如下：

注：exist not exist 终止算法，具体情况要视子查询表大小而看；·

查询优化器的提示： （暂时没看。。。）

优化count()函数；
count()函数的真正作用是什么？
count()有两种作用，可以统计某个列值的数量（非NULL），也可以统计行数，通常如果对值要求不精确我们会使用EXPLAIN 出来的优化器估算而非用count()去扫描全表；除此之外一般都是索引覆盖扫描；

Limit 分页