8.1 Optimization Overview

8.1 Optimization Overview

数据库的性能取决于数据库级别上的几个因素例如：表、查询和配置设置。这些软件构造导致在硬件级别上的 CPU 和 I/O 操作，你必须将这些操作最小化并尽可能的提高效率。在处理数据库性能时，首先要学习软件方面的高级规则和指导方针，并使用 wall-clock time 度量性能。当你成为专家时，你将了解更多关于数据库内部发生的事情，并开始度量诸如 CPU 周期和 I/O 操作之类的事情。

典型用户的目标是通过现有的软硬件配置获得最佳的数据库性能。高级用户寻找机会改进 MySQL 软件本身，或者开发自己的存储引擎和硬件设备，以扩展 MySQL 生态系统。

Optimizing at the Database Level

Optimizing at the Hardware Level

Balancing Portability and Performance

Optimizing at the Database Level

使数据库应用程序运行快速的最重要的因素是它的基本设计：

这些表的结构设计是否正确？特别是列是否具有正确的数据类型，每个表是否具有适合于该工作类型的列？例如：执行频繁更新的应用程序通常有很多表但是这些表所包含的列的数都比较的少，而分析大量数据的应用程序通常有很少的表，但是这些表通常有很多的列。

是否有适当的索引来提高查询的效率？

是否为每个表使用了合适的存储引擎，并充分利用了所使用的每个存储引擎的优点和特性？特别是选择事务性存储引擎如 InnoDB 或非事务性存储引擎如 MyISAM 对于性能和可伸缩性非常重要。

每个表是否使用适当的行格式？这个选择还取决于表使用的存储引擎。特别是压缩表使用更少的磁盘空间，因此读写数据所需的磁盘 I/O 更少。InnoDB 表和只读 MyISAM 表都可以使用压缩存储。

应用程序是否使用适当的锁定策略？例如在可能的情况下允许共享访问，以便数据库操作可以并发运行，在适当的情况下请求独占访问，以便关键操作获得最高优先级。同样存储引擎的选择也很重要。InnoDB 存储引擎可以在不需要人工过多参与的情况下处理大多数锁定问题，从而在数据库中实现更好的并发性，并减少了对代码的试验和调优。

所有用于缓存的内存区域大小是否正确？也就是说内存足够大，可以容纳频繁访问的数据，但是不能大到导致物理内存过载和分页。要配置的主要内存区域是 InnoDB 缓冲池和 MyISAM 键缓存。

Optimizing at the Hardware Level

随着数据库变得越来越繁忙，任何数据库应用程序最终都会遇到硬件限制。DBA 必须评估是否有可能调优应用程序或重新配置服务器以避免这些瓶颈，或者是否需要更多的硬件资源。系统瓶颈通常来自以下来源。

Disk Seeks 磁盘找到一段数据需要时间。使用现代磁盘，平均时间通常低于 10ms，所以我们在理论上可以做每秒大约 100 次。这段时间随着新磁盘的使用而缓慢改进，并且很难针对单个表进行优化。优化寻道时间的方法是将数据分布到多个磁盘上。

Disk Reading and Writing 当磁盘处于正常时，我们需要读取或写入数据。对于现代磁盘，至少提供 10-20MB/s 的吞吐量。这比 seeks 更容易优化，因为你可以从多个磁盘并行读取。

CPU 周期 当数据在主内存中时，我们必须对其进行处理才能得到结果。对于大型的表来说内存是最常见的限制因素。但是对于小表来说速度通常不是问题。

Memory bandwidth 当 CPU 需要超过 CPU 缓存容量的数据时，主内存带宽就会成为瓶颈。对于大多数系统来说，这是一个不常见的瓶颈，但是需要注意。

Balancing Portability and Performance

要在可移植的 MySQL 程序中使用面向性能的 SQL 扩展，可以将特定于 MySQL 的关键字封装在 /*! * / 注释分隔符中。其他 SQL 服务器忽略注释的关键字。