jvmpoko对《高性能MySQL》的笔记(6)

jvmpoko
jvmpoko (\液/#^_^#)

在读 高性能MySQL

高性能MySQL
  • 书名: 高性能MySQL
  • 作者: 施瓦茨 (Baron Schwartz)/扎伊采夫 (Peter Zaitsev)/特卡琴科 (Vadim Tkachenko)
  • 副标题: 第3版
  • 页数: 764
  • 出版社: 电子工业出版社
  • 出版年: 2013-5-1
  • 第179页
    尽量扩展已有的索引的而不是创建新索引
    2014-12-21 20:10:01 回应
  • 第181页
    冗余索引降低性能,解决:删除。
    删除未使用的索引。
    2014-12-21 20:14:10 回应
  • 第199页
    最简单衡量查询的开销:
    响应时间
    扫描行数
    返回的行数
    如果查询需要扫描大量的行但只返回少量的行那么怎么解决,书中给出了三个方法:
    看起来简单,但是这就是工业解决手段
    1.使用索引覆盖扫描,但是等到查询时候再加索引会不会太早?
    2.改变库表结构
    3。重写这个复杂的查询
    当我们解决问题的时候应该按照312的顺序进行解决。
    2014-12-22 23:01:53 回应
  • 第203页
    在优化有问题的查询的时候,目标应该是找到一个更优的方法获得实际需要的结果而不是一定总是需要从mysql获取一样的结果集
    很多时候是我们的关注点错了,而错了不需要一错到底,思维定势。
    时代变迁让以前理所当然的事情在硬件软件都快速发达的今天并不适用,比如查询使用复杂语句来代替多个简单语句。
    当然在一个独立查询能完成的操作分成多个查询就不明智了。
    书中举了个删除数据的例子,
    每次删除数据后,都暂停下再做下次删除,这样可以将服务器上原本一次性的压力分散到一个很长的时间段里,就可以大大降低对服务器的影响
    分解关联查询的几个好处。
    2014-12-22 23:28:29 回应
  • 第205页
    用户向mysql做出请求之后,mysql发生了什么。
    mysql服务端与客户端通信协议
    之间的通信协议是:“半双工”。
    一旦客户端发送了请求,它能做的事情只能是等待结果了
    客户端从服务器端拉数据,实际上是一个接收数据的过程。这是被动的,就算你粗暴的断开连接也无法阻止这一过程。
    使用第三方程序库来读取数据,一般是一股脑儿将数据缓存在内存中,然后从内存中解析数据,这对于一般大小的数据来说降低了mysql服务器的压力趁早读完可以做其他任务,但是对于数据量太大的结果集,这对内存和解析的时间都有压力。
    不过还有第三方库一般也都有方法来解决这一问题。书中举了一个php和c的例子。
    (ps:今天面试了一个PHP外包,都忘记问问php与mysql连接了,pdo之类的)
    2014-12-22 23:28:53 回应
  • 查询执行的基础
    其他数据库对于IN完全等同于多个OR条件的子句,因为这两者是完全等价的,在MySQL中这点是不成立的,MySQL对于in的数据先进行排序然后二分查找的方式来判断是否符合条件,这样做的复杂度是O(logn),而OR操作是O(n)
    MySQL并不会生成查询字节码来执行查询,MySQL生成查询的一颗指令树,然后通过存储引擎执行完成这颗指令树并返回结果
    重新定义关联的顺序是优化器一项非常重要的功能,不过也可以人为干预顺序,绝大多数情况,优化器做出的选择逗比普通人的判断要更准确
    优化器对关联表的复杂度是关联n个表对应的顺序是n!
    排序是一个成本很高的操作,应该尽可能避免。
    一旦服务器处理完最后一个关联表,开始生成第一个结果时,MySQL就可以开始向客户端逐步返回结果集了
    结果集汇总的每一行都会一个满足MySQL客户端服务端通信协议的封包发送,再通过TCP协议进行传输,在TCP的传输过程中,可能对MySQL的封包进行缓存然后批量传输。
    2014-12-23 22:06:57 回应