MySQL 8.4 发行说明
数据库性能取决于数据库级别的几个因素，例如表、查询和配置设置。这些软件结构会导致硬件级别的 CPU 和 I/O 操作，您必须尽量减少这些操作并使其尽可能高效。在处理数据库性能时，您首先要学习软件方面的基本规则和指南，并使用挂钟时间来衡量性能。随着您成为专家，您将更多地了解内部发生的事情，并开始测量 CPU 周期和 I/O 操作等内容。
典型用户的目标是从其现有的软件和硬件配置中获得最佳数据库性能。高级用户则寻求改进 MySQL 软件本身的机会，或者开发自己的存储引擎和硬件设备来扩展 MySQL 生态系统。
使数据库应用程序快速运行的最重要因素是其基本设计。
表的结构是否合理？特别是，列的数据类型是否正确，每个表是否具有适合工作类型的列？例如，执行频繁更新的应用程序通常具有许多列数较少的表，而分析大量数据的应用程序通常具有少量列数较多的表。
是否已建立正确的 索引 以提高查询效率？
您是否为每个表使用了适当的存储引擎，并利用了您使用的每个存储引擎的优势和功能？特别是，选择事务性存储引擎（如
InnoDB）还是非事务性存储引擎（如MyISAM）对于性能和可伸缩性非常重要。注意InnoDB是新表的默认存储引擎。实际上，InnoDB的高级性能功能意味着InnoDB表的性能通常优于更简单的MyISAM表，尤其是在繁忙的数据库中。每个表是否使用适当的行格式？此选择还取决于用于表的存储引擎。特别是，压缩表使用的磁盘空间较少，因此读取和写入数据所需的磁盘 I/O 较少。压缩可用于
InnoDB表的所有类型工作负载，以及只读MyISAM表。应用程序是否使用适当的 锁定策略？例如，尽可能允许共享访问，以便数据库操作可以并发运行，并在适当时请求独占访问，以便关键操作获得最高优先级。同样，存储引擎的选择也很重要。
InnoDB存储引擎无需您的参与即可处理大多数锁定问题，从而在数据库中实现更好的并发性，并减少代码的实验和调整量。是否已正确调整用于 缓存 的所有内存区域的大小？也就是说，它们的大小是否足以容纳经常访问的数据，但又不会过大以至于使物理内存过载并导致页面调度？要配置的主要内存区域是
InnoDB缓冲池和MyISAM键缓存。
随着数据库变得越来越繁忙，任何数据库应用程序最终都会遇到硬件限制。DBA 必须评估是否有可能调整应用程序或重新配置服务器以避免这些 瓶颈，或者是否需要更多硬件资源。系统瓶颈通常来自以下来源：
磁盘寻道。磁盘查找一块数据需要时间。对于现代磁盘，此操作的平均时间通常低于 10 毫秒，因此理论上我们每秒可以执行大约 100 次寻道。随着新磁盘的出现，这一时间正在缓慢缩短，并且对于单个表来说很难优化。优化寻道时间的方法是将数据分布到多个磁盘上。
磁盘读取和写入。当磁盘位于正确位置时，我们需要读取或写入数据。使用现代磁盘，一个磁盘至少可以提供 10-20MB/s 的吞吐量。这比寻道更容易优化，因为您可以从多个磁盘并行读取。
CPU 周期。当数据位于主内存中时，我们必须对其进行处理才能获得结果。与内存量相比，拥有大表是最常见的限制因素。但对于小表，速度通常不是问题。
内存带宽。当 CPU 需要的数据超过 CPU 缓存容量时，主内存带宽就会成为瓶颈。对于大多数系统来说，这不是一个常见的瓶颈，但需要注意。
要在可移植的 MySQL 程序中使用面向性能的 SQL 扩展，您可以将特定于 MySQL 的关键字包装在 /*! */ 注释分隔符内的语句中。其他 SQL 服务器会忽略注释掉的关键字。有关编写注释的信息，请参阅第 11.7 节“注释”。