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，主内存带宽会变为一个瓶颈。
通常这不是一个寻常的瓶颈。