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