search 2013 adfgs
作者:Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接:http://isky000.com/database/2012dtcc-mysql-performance-tuning-practise | del.icio.us | Twitter it

上周受邀于 IT168,在 2012年度的 DTCC 大会上做了一个小的主题分享,内容主要是最近几年在 MySQL 数据库的性能调优过程中积累的一点点经验总结,希望能对大家有用。

其中部分内容在之前的 第二届华东地区数据库大会 上已经有过分享,这次是在当时分享内容的基础上增加了硬件和系统层面的内容,同时根据听众反馈对原有内容进行了部分优化改进。

以下就是这次分享的 PPT 内容(有更新):

, ,

已经有8个回复

  1. jedy Says @ 12-04-16 9:30 pm

    感谢你的分享。能够详细说明一下为什么单实例内存没有必要超过64GB吗?”CPU Core达到16最好双实例”应该是针对较老一些的版本吧,我记得较新的版本基本上解决了16核的性能回归问题。另外count(*)和count(1)是完全一样的,应该不存在性能差异。

  2. 朝阳 Says @ 12-04-16 9:51 pm

    内存并不是越大越好,对于InnoDB存储引擎来说,过大的buffer pool会导致过大的管理成本,当内存超过一定量,MySQL的性能并不会提升相反会慢慢下降,之前的测试经验大概在70GB左右会有这样的现象产生。CPU Core即使是目前最新版本的 MySQL,也最多也就只能利用上16个Core,而且从8到16只有很少比例的增加,所以如果你达到16个Core,建议用爽Instance,count(*)和count(1),只是在结果和性能一样而已,在这里,我也并没有说他不一样。

  3. 蓝白 Says @ 12-04-18 5:41 pm

    为什么select a,b from …比select a,b,c from …可以让数据库访问更少的数据量?
    因为数据是以row为基础存储的,如果a,b,c三个字段都不是索引,无论读取a,b,c哪个字段,都是读取row数据,所以访问的数据量应该都是一样的吧。

  4. Sky Says @ 12-04-19 9:16 am

    @蓝白,这里说的都是误区啊,误区部分千万别看错了,要不然会理解错误的。select a,b from … 不一定比 select a,b,c from … 访问更少数据。正如你下面说的,如果a,b,c在同一个组合索引中且查询又是他哦难过该组合索引完成的情况,则二者会访问相同数据,如果2个查询都无法通过索引直接完成,那二者也是访问相同数据。只有当第一个查询通过一个只含有a,b的组合索引直接完成的情况,才会出现第一条查询比第二条查询访问更少数据的情况。

  5. 蓝白 Says @ 12-04-19 10:33 am

    呵呵,谢了。是我看错了。

  6. Joshle Says @ 12-05-24 4:21 pm

    先分页再 join 是指?

  7. 鲁鲁 Says @ 12-05-25 2:18 pm

    PPT的41页
    query_cache Innodb无效
    是不是指在使用Innodb时 MySQL query_cache 不起作用?
    我在看MySQL文档时,看到
    8.6.3.1. How the Query Cache Operates
    http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html

    The query cache also works within transactions when using InnoDB tables.
    请问这个怎么回事?

  8. 朝阳 Says @ 12-07-10 1:00 pm

    就是说如果你的SQL语句存在Join,那么为了尽量减少参与Join的记录条数,尽量先将不必要的记录过滤掉,比如分页的SQL先将分页做好,再将分页后需要的那一页的记录进行Join,可以大大降低IO访问量

看完了要说点啥么?