8.1 Optimization Overview

数据库性能取决于数据库的几个因素,如表,查询和配置设置。这些软件的结构导致CPU和I/O 操作在软件层面，

你必须尽量减少和变的尽可能的有效。当你再数据库性能方面工作时,你开始学习高级的rules和软件方面的指导,

使用墙上时间来衡量。当你成为一个专家时,你会了解关于内部的更多事情,比如测量CPU 周期和I/O操作。

典型的用户目的是得到数据库最好的性能,基于其现有的软件和硬件配置。

高级用户寻找改善MySQL 软件本身的机会, 或开发他们自己的存储引擎和硬件应用来扩展MySQL的生态系统。

Optimizing at the Database Level (在数据库层面进行优化)

让数据库应用跑的快的最重要的因素是设计:

表结构是否正确? 特别是, 列是否有正确的数据类型,并且是否每个表有适当的列，例如,

1.应用执行频繁的更新有很多表的很少的列,而应用分析大量数据经常会是几个表的很多列。

2.是否有合适的索引以提高查询效率？

你是否对每个表使用了合适的引擎,并利用你所使用的存储引擎的优势和功能？特别是,

一个事务性存储引擎如InnoDB或非事务如MyISAM可以选择对性能和可伸缩性很重要。

注意:

在MySQL 5.5 和更高的版本,InnoDB 是默认的存储引擎。在实践中,InnoDB的性能优势意味着 InnoDB 表通常性能优于更简单的myISAM表,

尤其是在一个繁忙的数据库:

确保每个表使用了合适的行格式？这个选择也取决于表使用的存储引擎。特别的,

压缩表使用较少的磁盘空间,因此需要较少的磁盘I/O读写。压缩可用InnoDB表,和只读的MyISAM表。

应用程序使用一个合适的lock策略？比如,通过允许共享访问以便数据库可以并发访问,

在适当的时候请求排他访问, 重要的操作获得最高的权限。再次, 存储引擎的选择是重要的。

InnoDB 存储引擎处理大多数的锁定问题在没有侵犯你的情况下,

允许最大的并发在数据库。

硬件级的优化

任何数据库应用最后都会达到硬件的限制,当数据库变的越来越繁忙时。

一个DBA 必须评估是否可以调整应用或者重新配置服务器来避免这些瓶颈,

或者更多的硬件资源是需要的,系统瓶颈通常来自这些来源：

磁盘寻址, 找到一块数据需要时间。随着现代的磁盘,这意味着通常小于10ms，

所以我么理论上可以每秒做100个寻址。这个时间可以改善通过使用新的磁盘,但是对单个表优化很难。

优化查找时间的方法是将数据分发到多个磁盘上。

磁盘读写,当磁盘处于正确的位置, 当我们需要读写数据，随着现在的磁盘,

一个磁盘至少10-20M/s的吞吐量, 这个比寻址更容易,因为你可以从多个磁盘读取。

CPU 周期,当数据在主内存的时候, 我们必须处理它来得到我们需要的结果。

和大表相比,内存的总量是最常见的限制因素,但是对于小表,这通常不是问题。

内存带宽, 当CPU 需要更多的数据能够合适它的CPU cache，主内存带宽会变为一个瓶颈。

通常这不是一个寻常的瓶颈。