MySQL优化（一）.docVIP

MySQL 优化MySQL文档翻译 译者：叶金荣（Email:），来源：MySQL手册版本 5.0.20，转载请注明译者和出处，并且不能用于商业用途，违者必究。 7 MySQL 优化 数据库优化是一项很复杂的工作，因为这最终需要对系统优化的很好理解才行。尽管对系统或应用系统的了解不多的情况下优化效果还不错，但是如果想优化的效果更好，那么就需要对它了解更多才行。 本章主要讲解了几种优化MySQL的方法，并且给出了例子。记着，总有各种办法能让系统运行的更快，当然了，这需要更多的努力。 7.1 优化概述 让系统运行得快得最重要因素是数据库基本的设计。并且还必须清楚您的系统要用来做什么，以及存在的瓶颈。 最常见的系统瓶颈有以下几种： 磁盘搜索。它慢慢地在磁盘中搜索数据块。对现代磁盘来说，平时的搜索时间基本上小于10毫秒，因此理论上每秒钟可以做100次磁盘搜索。这个时间对于全新的新磁盘来说提高的不多，并且对于只有一个表的情况也是如此。加快搜索时间的方法是将数据分开存放到多个磁盘中。 磁盘读/写。当磁盘在正确的位置上时，就需要读取数据。对现代磁盘来说，磁盘吞吐量至少是10-20MB/秒。这比磁盘搜索的优化更容易，因为可以从多个媒介中并行地读取数据。 CPU周期。数据存储在主内存中（或者它已经在主内存中了），这就需要处理这些数据以得到想要的结果。 内存带宽。当CPU要将更多的数据存放在CPU缓存中时，主内存的带宽就是瓶颈了。在大多数系统中，这不是常见的瓶颈，不过也是要注意的一个因素。 7.1.1 MySQL 设计的局限性 当使用MyISAM存储引擎时，MySQL会使用一个快速数据表锁以允许同时多个读取和一个写入。这种存储引擎的最大问题是发生在一个单一的表上同时做稳定的更新操作及慢速查询。如果这种情况在某个表中存在，可以使用另一种表类型。详情请看15 MySQL Storage Engines and Table Types。MySQL可以同时在事务及非事务表下工作。为了能够平滑的使用非事务表（发生错误时不能回滚），有以下几条规则： 所有的字段都有默认值 如果字段中插入了一个错误的值，比如在数字类型字段中插入过大数值，那么MySQL会将该字段值置为最可能的值而不是给出一个错误。数字类型的值是0，最小或者最大的可能值。字符串类型，不是空字符串就是字段所能存储的最大长度。 所有的计算表达式都会返回一个值而报告条件错误，例如 1/0 返回 NULL。 这些规则隐含的意思是，不能使用MySQL来检查字段内容。相反地，必须在存储到数据库前在应用程序中来检查。详情请看1.8.6 How MySQL Deals with Constraints 和 14.1.4 INSERT Syntax。 7.1.2 应用设计的可移植性 由于各种不同的数据库实现了各自的SQL标准，这就需要我们尽量使用可移植的SQL应用。查询和插入操作很容易就能做到可移植，不过由于更多的约束条件的要求就越发困难。想要让一个应用在各种数据库系统上快速运行，就变得更困难了。 为了能让一个复杂的应用做到可移植，就要先看这个应用运行于哪种数据库系统之上，然后看这些数据库系统都支持哪些特性。 每个数据库系统都有某些不足。也就是说，由于设计上的一些妥协，导致了性能上的差异。 可以用MySQL的 crash-me 程序来看选定的数据库服务器上可以使用的函数，类型，限制等。crash-me 不会检查各种可能存在的特性，不过这仍然是合乎情理的理解，大约做了450次测试。 一个 crash-me 的信息类型的例子就是，它会告诉您如果想使用Informix 或 DB2的话，就不能使字段名长度超过18个字符。 crash-me 程序和MySQL基准使每个准数据库都实现了的。可以通过阅读这些基准程序是怎么写的，自己就大概有怎样做才能让程序独立于各种数据库这方面的想法了。这些程序可以在MySQL源代码的 `sql-bench 目录下找到。他们大部分都是用Perl写的，并且使用DBI接口。由于它提供了独立于数据库的各种访问方式，因此用DBI来解决各种移植性的问题。 想要看到 crash-me 的结果，可以访问：/tech-resources/crash-me.php. 访问 /tech-resources/benchmarks 可以看到基准的结果。 如果您想努力做到独立于数据库，这就需要对各种SQL服务器的瓶颈都有一些很好的想法。例如，MySQL对于 MyISAM 类型的表在检索以及更新记录时非常快，但是在有并发的慢速读取及写入记录时却有一定的问题。作为Oracle来说，它在访问刚刚被更新的记录时有很大的问题（直到结果被刷新到磁盘中）。事务数据库一般地在从日志表中生成摘要表这方面的表现不怎么好，因为