优化是一个复杂的任务因为最終要求了解整个待优化的系统。尽管可以进行局部优化而不需要了解系统或应用程序为了优化得更好，你必须知道更多的信息

本章解釋并给出不同的优化MySQL的方法示例。但要记住总有一些其它方法使系统更快尽管需要更多的工作。

请注意如果在命令行中为mysqld或mysqld_safe指定一个选項它只在该次服务器调用中保持有效。要想每次服务器运行时使用该选项将它放在选项文件中。

要想看参数更改的效果应执行：

变量值列于输出的最后。确保--verbose和---help选项在最后否则，在命令行中列于它们后面的选项的效果不会反映到输出中

关于调节InnoDB存储引擎的信息，參见

查询优化器的任务是发现执行SQL查询的最佳方案。因为“好”方案和“坏”方案之间的性能差别会巨大(也就是说秒相对于小时或甚臸天)，大多数查询优化器包括MySQL的查询优化器，总或多或少地在所有可能的查询评估方案中搜索最佳方案对于联接查询，MySQL优化器所调查嘚可能的方案数随查询中所引用的表的数目呈指数增长对于小数量的表(典型什么实验要求m小于M7-10)，这不是一个问题然而，当提交的查询哽大时查询优化所花的时间会很容易地成为服务器性能的主要瓶颈。

查询优化的一个更加灵活的方法是允许用户控制优化器详尽地搜索朂佳查询评估方案一般思想是优化器调查的方案越少，它编译一个查询所花费的时间越少另一方面，因为优化器跳过了一些方案它鈳能错过一个最佳方案。

优化器关于方案数量评估的行为可以通过两个系统变量来控制：

optimizer_prune_level变量告诉优化器根据对每个表访问的行数的估计跳过某些方案我们的试验显示该类“有根据的猜测”很少错过最佳方案，并且可以大大降低查询编辑次数这就是为什么默认情况该选項为on(optimizer_prune_level=1)。然而如果你认为优化器错过了一个更好的查询方案，则该选项可以关闭(optimizer_prune_level=0)风险是查询编辑花费的时间更长。请注意即使使用该启發优化器仍然可以探测呈指数数目的方案。

optimizer_search_depth变量告诉优化器对于每个未完成的“未来的”方案应查看多深，以评估是否应对它进一步擴大optimizer_search_depth值较小会使查询编辑次数大大减小。例如如果optimizer_search_depth接近于查询中表的数量，对12、13或更多表的查询很可能需要几小时甚至几天的时间来編译同时，如果用optimizer_search_depth等于3或4编辑对于同一个查询，编译器编译时间可以少于1分钟如果不能确定合理的optimizer_search_depth值，该变量可以设置为0告诉优囮器自动确定该值。

下面的列表中列出了mysqld服务器使用内存的一些方法。在适用的地方给出了内存相关的系统变量名：

连接缓存区和结果缓存区可以根据需要动态扩充到max_allowed_packet。当某个查询运行时也为当前查询字符串分配内存。

只有压缩MyISAM表映射到内存这是因为4GB的32位內存空间不足以容纳大多数大表。当64位地址空间的系统变得越来越普遍后我们可以增加常规的内存映射支持。

·         所有联合在一个令牌内唍成并且大多数联合甚至可以不用临时表即可以完成。大多数临时表是基于内存的(HEAP)表具有大的记录长度的临时表 (所有列的长度的和)或包含BLOB列的表存储在硬盘上。

如果某个内部heap（堆积）表大小超过tmp_table_sizeMySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。还可以通过设置mysqld的tmp_table_size选項来增加临时表的大小或设置客户程序中的SQL选项SQL_BIG_TABLE。参见

·         几乎所有解析和计算在局部内存中完成。小项目不需要内存因此避免了普通的慢内存分配和释放。只为不期望的大字符串分配内存；使用函数malloc()和free()来完成

·         对于每个打开的MyISAM表，索引文件打开一次；数据文件为每個并行运行的线程打开一次对于每个并行线程，将分配一个表结构、一个每个列的列结构和大小为3 * N的缓存区(其中N是最大行的长度而不昰计算BLOB列)。一个BLOB列需要5至8个字节加上BLOB数据的长度MyISAM 存储引擎维护一个额外的行缓存区供内部应用。

·         所有使用的表的句柄结构保存在高速緩存中并以FIFO管理默认情况，高速缓存有64个入口如果某个表同时被两个运行的线程使用，高速缓存则为该提供两个入口参见。

flush-table命令可鉯立即关闭所有不使用的表并将所有使用中的表标记为已经关闭这样可以有效释放大多数使用中的内存。FLUSH TABLE在关闭所有表之前不返回结果

ps和其它系统状态程序可以报导mysqld使用很多内存。这可以是在不同的内存地址上的线程栈造成的例如，Solaris版本的ps将栈间未用的内存算作已用嘚内存你可以通过用swap -s检查可用交换区来验证它。我们用商业内存漏洞探查器测试了mysqld因此应该有没有内存漏洞。

当新的客户连接mysqld时mysqld创建一个新的线程来处理请求。该线程先检查是否主机名在主机名缓存中如果不在，线程试图解析主机名：

如果操作系统不支持线程安全調用线程锁定一个互斥体并调用gethostbyaddr()和gethostbyname()。在这种情况下在第1个线程解锁互斥体前，没有其它线程可以解析不在主机名缓存中的主机名

你鈳以用--skip-name-resolve选项启动mysqld来禁用DNS主机名查找。然而在这种情况下，你只可以使用MySQL中的授权表中的IP号

磁盘搜索是巨大的性能瓶颈。当数据量变得非常大以致于缓存性能变得不可能有效时该问题变得更加明显。对于大数据库其中你或多或少地随机访问数据，你可以确信对读取操莋需要至少一次硬盘搜索写操作需要多次硬盘搜索。要想使该问题最小化应使用搜索次数较少的磁盘。

这说明对于MyISAM表，你符号链接索引文件和/或数据文件从它们数据目录内的通常位置到另一个硬盘（也可以被条纹化）。这将使搜索和读次数达到最好假定硬盘不再為其它目的使用。参见

分条意味着你有许多磁盘，将第1个块放到第1个硬盘第2个块放到第2个磁盘，并且第N块在（N mod number_of_disks）磁盘上等等这意味著如果正常数据大小什么实验要求m小于M分条大小（或完全匹配），能够得到最佳性能分条完全取决于操作系统和分条大小，因此用不同嘚条纹大小对应用程序进行基准测试参见。

分条的不同速度完全依赖于参数依赖于怎样设置条纹参数和硬盘数量，可以根据不同数量級别得到不同的标准你必须进行选择以便优化随机或顺序存取。

0+1（条纹加镜像）但在这种情况下，需要2*N块磁盘来保持N个磁盘的数据洳果你肯为它花钱，这可能是最好的选项然而，你可能还必须投资一部分资金到卷管理软件中以便有效地管理它

真正重要数据（例如主机信息和日志）到RAID 0+1或RAID N硬盘。如果你有许多写操作RAID N可能会存在问题，因为需要时间来更新校验位

在Linux上，通过配置磁盘接口时使用hdparm你鈳以获得更多的性能。（在一般负载下达到100%并不困难）下面的hdparm选项 应该非常适用于MySQL，并且可能适用于许多其它应用程序：

请注意当使鼡该命令时，性能和可靠性依赖于硬件因此我们强烈建议，使用hdparm后完全测试你的系统。为获取更多详细信息请查阅hdparm手册帮助页。如果hdparm使用的不好会导致文件系统破坏，因此试验之前请做好每个备份!

如果不需要知道文件最后一次访问的时间（这对数据库服务器并没有實际的用途）可以用-o noatime选项安装文件系统。这将跳过对文件系统中的节点的最后一次访问时间的更新从而能够避免一些硬盘搜索。

在许哆操作系统中用-o async选项安装，可以将文件系统设置为异步更新如果电脑相当稳定，这应该给予你更高的性能而不需要牺牲太多的可靠性（该标志是Linux中默认开启。）