8.1 Optimization Overview 优化概述

8.1 Optimization Overview 优化概述

数据库性能取决于几个方面的因素, 比如表,查询和配置设置。这些软件组成引起CPU和I/O操作在硬件层次,

你比虚尽可能最小化和尽可能的有效, 当你在数据库性能方面工作时,你开始学习高级别规则和软件方面的指导原则,

使用墙上时间还衡量性能, 当你成为专家,你了解更多的内部发生的事情,冰洁开始衡量CPU周期和I/O操作的事情。

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

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

Optimizing at the Database Level 在数据库层面优化:

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

表结果是否正确?特别的, 列是否有正确的数据类型,是否每个表的相应的列列工作类型？

例如, 应用执行频繁的更新经常有许多表的很少的列, 而应用分析大量数据可能是很少的表的很多列。

2.是否有合适的索引使查询效率更高?

3.你是否使用相应的存储引擎为每一个表, 并利用每个存储引擎的有点和功能？

特别的, 一个事务型传统引擎的选项 比如InnoDB 或者非事务的比如MyISAM 对于性能和扩展很重要

注意:

在MySQL 5.5或者更高版本,InnoDB 是默认的存储引擎对于新的表,实际上,InnoDB 的性能特点是InnoDB表

经常好过更简单的myisam表,特别是对于一个繁忙的数据库

是否每个表使用合适的row format呢？ 这个选择依赖表使用的存储引擎。特别是, 压缩表使用更少的磁盘

和需要更少的磁盘I/O 来读取和写入数据。压缩是可用于所有种类InnoDB表的负载,也用于只读的MyIAM表。

应用程序是否可以使用相应的锁定策略呢？比如,通过允许共享访问,以便在适当的情况下 数据库可以并发操作.

并在适当的情况下请求独占访问,以获得最高权限的紧急的操作。

再次,操作引擎的选择是重要的,InnoDB 存储引擎处理大多数锁定文件没有侵犯你,允许更多的并发。

是否所有的内存使用的区域用于正确的缓存大小呢？也就是,足够大 保留经常访问的数据,

但不能太大 以至于它们使用过多的内存,导致内存分页。 主要的内存区域配置为InnoDB 的buffer pool，

MyISAM 的key cache,MySQL query cache

硬件层面优化:

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

一个DBA必须评估 是否应该优化应用或者重新配置server来避免那些瓶颈,或者是否更多的额硬件资源是需要的,

系统瓶颈通常来自这些来源:

1. 磁盘寻址, 它花费时间来查找一块数据。随着现代磁盘的发展,这意味着通常小于10ms，

所以我们在里约上可以一秒做100次寻址。这个时间用新的磁盘来改善,优化单个表时难的。

优化寻址时间的方法是分散数据到多个磁盘。

2.磁盘读写,当磁盘处于正确的位置, 我们需要读或者写数据。随着现代磁盘,一个磁盘提供至少10-20MB/s的吞吐量。

3.CPU 周期, 当数据在主内存,我们必须处理它来得到我们需要的结果。有大表下相比，内存总是最常见的限制因素。

但是使用小表, 通常不是问题。