MySQL 8.0 参考手册  / 第8章优化  /  8.1 优化概述

8.1 优化概述

数据库性能取决于数据库级别的多个因素,例如表、查询和配置设置。这些软件结构会导致硬件级别的 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 服务器忽略注释的关键字。有关编写评论的信息,请参阅第 9.7 节,“评论”