数据库性能取决于数据库级别的几个因素，例如表、查询和配置设置。这些软件结构导致了硬件级别的 CPU 和 I/O 操作，您必须将其最小化并尽可能提高效率。在研究数据库性能时，首先要学习软件端的高级规则和准则，然后使用墙上的时钟时间来测量性能。当您成为专家时，您将了解更多关于内部发生的事情，并开始衡量 CPU 周期和 I/O 操作等事情。

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

• 在数据库级别进行优化
• 在硬件级别进行优化
• 平衡可移植性和性能

在数据库级别进行优化

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

• 表的结构是否正确？特别是，列是否具有正确的数据类型，每个表是否具有适合工作类型的列？例如，执行频繁更新的应用程序通常有很多表，但列很少，而分析大量数据的应用程序往往只有很少的表，且列很多。

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

• 您是否为每个表使用了适当的存储引擎，并利用了所使用的每个存储引擎的优势和功能？特别是，选择事务存储引擎（如 InnoDB ） 或非事务存储引擎，如 MyISAM ， 对于性能和可扩展性非常重要。

  注意
  InnoDB 是新表默认的存储引擎。在实践中，高级的 InnoDB 性能特性意味着 InnoDB 表通常优于简单的 MyISAM 表，尤其是在繁忙的数据库中。

• 每张表是否使用了适当的行格式？选择结果还依赖于为表所选的存储引擎。特别是，压缩表使用更少的磁盘空间，因此需要更少的磁盘 IO 来读写数据。压缩表适用于 InnoDB 表和只读 MyISAM 表的各种工作负载。

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

• 用于缓存的内存区域 大小是否正确？即大到足够保存频繁访问的数据，却又没有大到超过物理内存大小导致分页。需要配置的主内存区域是 InnoDB Buffer Pool 和 MyISAM Key Cache。

在硬件级别进行优化

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

• 磁盘查找。磁盘查找一块数据需要时间。对于现代磁盘，这一过程的平均时间通常低于 10ms， 因此理论上我们可以每秒进行 100 次寻道。这一时间随着新磁盘的使用而缓慢提高，很难针对单个表进行优化。优化寻道时间的方法是将数据分配到多个磁盘上。
• 磁盘读写。当磁盘位于正确位置时，我们需要读取或写入数据。对于现代磁盘，一个磁盘至少提供 10–20MB/s 的吞吐量。这比查找更容易优化，因为您可以从多个磁盘并行读取。
• CPU 周期。当数据在主内存中时，我们必须对其进行处理以获得结果。与内存总量相比，拥有较大的表是最常见的限制因素。但对于小表，速度通常不是问题。
• 内存带宽。当 CPU 需要的数据超过 CPU 缓存的容量时，主内存带宽就会成为瓶颈。对于大多数系统来说，这是一个不常见的瓶颈，但需要注意。

平衡可移植性和性能

要在可移植的 MySQL 程序中使用面向性能的 SQL 扩展，可以将 MySQL 特定的关键字包装在 /*！*/ 中的语句中注释分隔符。其他 SQL 服务器忽略注释的关键字。有关撰写注释的信息，请参见 第 9.7 节 “注释” 。