栏目： MySQL优化设计

二 28

量化InnoDB group commit的效果

发布时间： 发布者：

InnoDB的redo log的group commit历史比较悠久了(有别于binlog的group commit)。如果设置为1，每次事务提交都至少需要写一次redolog。这对IOPS冲击严重，尤其是在HDD上，直接成为性能瓶颈。Group commit的基本想法是将多个并发线程对redo的fsync操作合并成1个。

继续阅读全文 →

一 08

淘宝商品库MySQL优化实践的学习

发布时间： 发布者：

以下内容整理自淘宝的演讲，演讲内容包括淘宝商品库硬件的选型决策，安全性和性能的平衡，特别是创新引入PCI-E Flash卡和Flashcache作为Cache提高IO性能，在保证安全性的前提下就包括MySQL、InnoDB引擎、文件系统、系统Page Cache、 IO调度算法、DM层(Flashcache)、Raid卡、设备驱动在内的整条IO路径的Cache进行优化，进一步挖掘了系统IO的潜能，重点介绍优化过程中的一些经验教训、测量手段和工具。

继续阅读全文 →

一 08

MySQL数据库的字符集和copy_and_convert 字符集不同导致CPU资源额外消耗

发布时间： 发布者：

在对MySQL做业务压力测试的时候，我们在perf结果中发现 copy_and_convert 是一个耗费cpu的操作。这个函数的意思，就是在字符集之间做内容转换。
如果源和目标的字符集相同，就可以直接用memcpy，这显然比做字符集转换（按字节或字长拷贝更快，和节省cpu）
当整个系统是CPU瓶颈时，我们希望能够减少这种cpu消耗。

继续阅读全文 →

十二 05

MySQL优化 之 Discuz论坛MySQL通用优化

发布时间： 发布者：

今日帮朋友优化号称日均500PV，100UV的论坛，后台DB采用R710(16G Ram，PERC 6/i 256MB BBU，4块 15K RPM SAS盘做raid 1+0，ext3文件系统，E5620 * 2)，这个配置看似也不错了，不过压力仍然较大，大量的请求处于：sending data和statistics状态。
经过分析，确认瓶颈主要在：
1. IO读，IO写倒还好，不算高；因为数据表都是MyISAM，需要产生较高的物理读，不能通过内存有效缓冲；
2. 使用的MySQL是官方5.1版本，InnoDB队列请求排队较严重(部分表已经先转成InnoDB了)；
3. 部分未转换成InnoDB的表MyISAM表级锁比较严重；

继续阅读全文 →

十二 04

MySQL数据库性能优化之存储引擎选择

发布时间： 发布者：

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了，不仅可以同时使用多种存储引擎，而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。由于各存储引擎功能特性差异较大，这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。

继续阅读全文 →