Jaslabs的Justin Silverton列出了十条有关优化MySQL查询的语句，我不得不对此发表言论，因为这个清单非常非常糟糕。另外一个Mike也同样意识到了。所以在这个博客中，我要做两件事情，第一，指出为什么这个清单很糟糕，第二，列出我的清单，希望我的比较好些。继续看吧，无畏的读者们！

为什么那个清单很糟糕

1.他的力气没使对地方

我们要遵循的一个准则就是如果你要优化代码时，应该先找出瓶颈在哪。然而Silverton先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基础的。你需要知道join和子查询的区别，列索引，以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现，例如COUNT(*)可能很快也可能很慢，要看你选用什么数据库引擎。还有一些其他要考虑的因素，例如数据库在什么时候不用缓存，什么时候存在硬盘上而不存在内存中，什么时候数据库创建临时表等等。剩下的5%就很少会有人碰到了，但Silverton先生恰好在这上面花了大量的时间。我从来就没用过SQL_SAMLL_RESULT。

2.很好的问题，但是很糟糕的解决方法

Silverton先生提出了一些很好的问题。MySQL针对长度可变的列如TEXT或BLOB，将会使用动态行格式(dynamic row format)，这意味着排序将在硬盘上进行。我们的方法不是要回避这些数据类型，而是将这些数据类型从原来的表中分离开，放入另外一个表中。下面的schema可以说明这个想法：

CREATE TABLE posts (
    id int UNSIGNED NOT NULL AUTO_INCREMENT,
    author_id int UNSIGNED NOT NULL,
    created timestamp NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE posts_data (
    post_id int UNSIGNED NOT NULL.
    body text,
    PRIMARY KEY(post_id)
);

3. 有点匪夷所思……

他的许多建议都是让人非常吃惊的，譬如“移除不必要的括号”。你这样写SELECT * FROM posts WHERE (author_id = 5 AND published = 1)，还是这样写SELECT * FROM posts WHERE author_id = 5 AND published = 1 ，都不重要。任何比较好的DBMS都会自动进行识别做出处理。这种细节就好像C语言中是i++快些还是++i快些。真的，如果你把精力都花在这上面了，那就不用写代码了。

我的列表

看看我的列表是不是更好吧。我先从最普遍的开始。

1.建立基准，建立基准，建立基准！

如果需要做决定的话，我们需要数据说话。什么样的查询是最糟的？瓶颈在哪？我什么情况下会写出糟糕的查询？基准测试可以让你模拟高压情况，然后借助性能测评工具，可以让你发现数据库配置中的错误。这样的工具有supersmack, ab, SysBench。这些工具可以直接测试你的数据库(譬如supersmack)，或者模拟网络流量（譬如ab）。

2.性能测试，性能测试，性能测试!

那么，当你能够建立一些高压情况之后，你需要找出配置中的错误。这就是性能测评工具可以帮你做的了。它可以帮你发现配置中的瓶颈，不论是在内存中，CPU中，网络中，硬盘I/O，或者是以上皆有。

你要做的第一件事就是开启慢查询日志(slow query log)，装上mtop。这样你就能获取那些恶意的入侵者的信息了。有需要运行10秒的查询语句正在破坏你的应用程序吗？这些家伙会展示给你看他的查询语句是怎么写的。

在你发现那些很慢的查询语句后，你需要用MySQL自带的工具，如EXPLAIN，SHOW STATUS，SHOW PROCESSLIST。它们会告诉你资源都消耗在哪了，查询语句的缺陷在哪，譬如一个有三次join子查询的查询语句是否在内存中进行排序，还是在硬盘上进行。当然你也应该使用测评工具如top，procinfo，vmstat等等获取更多系统性能信息。

3.减小你的schema

在你开始写查询语句之前，你需要设计schema。记住将一个表装入内存所需要的空间大概是行数*一行的大小。除非你觉得世界上的每个人都会在你的网站注册2兆8000亿次的话，否则你不需要采用BITINT作为你的user_id。同样的，如果一个文本列是固定大小的话（譬如US邮编，通常是”XXXXX-XXXX”的形式），采用VARCHAR的话会给每行增加多余的字节。

有些人对数据库规范化不以为意，他们说这样会形成相当复杂的schema。然而适当的规范化会减少化冗余数据。（适当的规范化）就意味着牺牲少许性能，换取整体上更少的footprint，这种性能换取内存在计算机科学中是很常见的。最好的方法是IMO，就是开始先规范化，之后如果性能需要的话，再反规范化。你的数据库将会更逻辑化，你也不用过早的进行优化。（译者注，这一段我不是很理解，可能翻译错了，欢迎纠正。）

4.拆分你的表

通常有些表只有一些列你是经常需要更新的。例如对于一个博客，你需要在许多不同地方显示标题（如最近的文章列表），只在某个特定页显示概要或者全文。水平垂直拆分是很有帮助的：

CREATE TABLE posts (
    id int UNSIGNED NOT NULL AUTO_INCREMENT,
    author_id int UNSIGNED NOT NULL,
    title varchar(128),
    created timestamp NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE posts_data (
    post_id int UNSIGNED NOT NULL,
    teaser text,
    body text,
    PRIMARY KEY(post_id)
);

上面的schema是对读数据进行的优化。经常要访问的数据存在一个表中，那些不经常访问的数据放在另一个。被拆分后，不经常访问的数据占据更少的内存。你也可以优化写数据，经常更新的数据放在一个表，不经常更新的放在另一个表。这可以使缓存更高效，因为MySQL不需要让没有更新过的数据移出缓存。

5.不要过度使用artificial primary key

artificial primary key非常棒，因为他们使得schema更少的变化。如果我们将地理信息存在以美国邮编为基础的表中，如果邮编系统突然改变了，那我们就会有大麻烦了。另一方面，采用natural key有时候也很棒，譬如我们需要join多对多的关系表时，我们不应该这样：

CREATE TABLE posts_tags (
    relation_id int UNSIGNED NOT NULL AUTO_INCREMENT,
    post_id int UNSIGNED NOT NULL,
    tag_id int UNSIGNED NOT NULL,
    PRIMARY KEY(relation_id),
    UNIQUE INDEX(post_id, tag_id)
);

artificial key完全是多余的，而且post-tag关系的数量将会受到整形数据的系统最大值的限制。

CREATE TABLE posts_tags (
    post_id int UNSIGNED NOT NULL,
    tag_id int UNSIGNED NOT NULL,
    PRIMARY KEY(post_id, tag_id)
);

6.学习索引

你选择的索引的好坏很重要，不好的话可能破坏数据库。对那些还没有在数据库学习很深入的人来说，索引可以看作是就是hash排序。例如如果我们用查询语句SELECT * FROM users WHERE last_name = ‘Goldstein’，而last_name没有索引的话，那么DBMS将会查询每一行，看看是否等于“Goldstein”。索引通常是B-tree（还有其他的类型），可以加快比较的速度。

你需要给你要select,group,order,join的列加上索引。显然每个索引所需的空间正比于表的行数，所以越多的索引将会占用更多的内存。而且写数据时，索引也会有影响，因为每次写数据时都会更新对应的索引。你需要取一个平衡点，取决每个系统和实施代码的需要。

7.SQL不是C

C是经典的过程语言，对于一个程序员来说，C语言也是个陷阱，使你错误的以为SQL也是一种过程语言（当然SQL也不是功能语言也不是面向对象的）。你不要想象对数据进行操作，而是要想象有一组数据，以及它们之间的关系。经常使用子查询时会出现错误的用法。

SELECT a.id,
    (SELECT MAX(created)
    FROM posts
    WHERE author_id = a.id)
AS latest_post
FROM authors a

因为这个子查询是耦合的，子查询要使用外部查询的信息，我们应该使用join来代替。

SELECT a.id, MAX(p.created) AS latest_post
FROM authors a
INNER JOIN posts p
    ON (a.id = p.author_id)
GROUP BY a.id

8.理解你的引擎

MySQL有两种存储引擎：MyISAM和InnoDB。它们分别有自己的性能特点和考虑因素。总体来讲，MyISAM适合读数据很多的情况，InnoDB适合写数据很多的情况，但也有很多情况下正好相反。最大的区别是它们如何处理COUNT函数。

MyISAM缓存有表meta-data，如行数。这就意味着，COUNT(*)对于一个结构很好的查询是不需要消耗多少资源的。然后对于InnoDB来说，就没有这种缓存。举个例子，我们要对一个查询来分页，假设你有这样一个语句SELECT * FROM users LIMIT 5,10，而运行SELECT COUNT(*) FROM users LIMIT 5,10 时，对于MyISAM很快完成，而对InnoDB就需要和第一个语句相同的时间。MySQL有个SQL_CALC_FOUND_ROWS选项，可以告诉InnoDB运行查询语句时就计算行数，之后再从SELECT FOUND_ROWS()来获取。这是MySQL特有的。但使用InnoDB有时候是非常必要的，你可以获得一些功能（如行锁定，stord procedure等）。

9.MySQL特定的快捷键

MySQL提供了许多扩展，方便使用。譬如INSERT … SELECT, INSERT … ON DUPLICATE KEY UPDATE, 以及REPLACE。

我能用到它们时是毫不犹豫的，因为它们很方便，能在许多情况下发挥不错的效果。但是MySQL也有一些危险的关键字，应该少用。例如INSERT DELAYED,它告诉MySQL不需要立即插入数据(例如在写日志的时候)。但问题是如果在很高数据量的情况下，插入可能会被无限期延迟，导致插入队列爆满。你也可以使用MySQL的索引提示来指出哪些索引是需要使用的。MySQL大部分时间运行是不错的，但如果schema设计不好的话或语句写得不好的话，MySQL的表现可能很糟糕。

10.到这里为止吧

最后，如果你关心MySQL性能优化的话，请阅读Peter Zaitsev的关于MySQL性能的博客，他写了许多关于数据库管理和优化的博客。

原文链接：20bits.com   编译：伯乐在线?- 唐小娟

您可能也喜欢：
关于Mysql的Qcache优化	mysql limit查询优化	用mysql中的join来优化查询	MySQL性能优化的最佳20+条经验
无觅

官方解释如下：

Description:
Since upgrading MySQL from version 4.0.xx to 4.1.11, when trying to place data into a
record it can fail with the error "#1030 - Got error 139 from storage engine". The problem
appears to be if the data reaches a certain size. I first found the problem when trying to
import a dump created by phpMyAdmin for one of my tables.

I am using the "Standard" install package from MySQL Web site. Running Apple Mac/MacOS X
10.3.9. PHP is version 4.3.10 (client API is 3.23.49).

I use phpMyAdmin to administer the DB, but I have run tests using PHP and the problem
still occurs.

I have also performed tests on my ISP's server (UNIX based) and the problem also occurs,
they are using MySQL client API of 4.1.11.

I still have access to a 4.0 server and can import the dump with no problems at all, even
using a dump from MySQL 4.1.11 using the "backward compatibility" option in phpMyAdmin.

How to repeat:
Create an InnoDB table with 1 INT field and 11 TEXT fields. 

Create an index on the INT field of type "PRIMARY". 

In the first 10 text fields, enter as many "a" characters as phpMyAdmin will allow. This
is 32000 characters in each field. Leave the last text field empty. Click "Go" to save the
changes. This should save without any problems. 

Then copy/paste field 10 to field 11 and click "Go". This results in a "#1030 - Got error
139 from storage engine" error.

If I remove the characters little by little at some point it will work, suggesting a size
problem. 

Please let me know if you need any additional information.

Hi!

In 4.1, to support at least 256-character UTF-8 column prefix indexes, InnoDB stores at
least 768 bytes of each column 'internally' to the record. With 11 TEXT fields you will
run over the 8000 byte record len limit.

./include/dict0mem.h:159:#define DICT_MAX_COL_PREFIX_LEN        768

I probably need to update the manual.

Thank you,

Heikki

Hi Heikki

Many thanks for the reply.

I read what you wrote several times, but a lot of it still went over my head, so apologies
if what I  write below is irrelevant  

Is this 8000 byte limit you mention the same one mentioned in section 15.17 of the manual,
i.e. because of the 16k database page size?

After reading the manual, section 15.17, I know:

1. The Database Page Size is set as standard as 16k - server needs recompiling to use a
new limit. From what I can see this setting affects the maximum row length for NON TEXT
and BLOB fields. If I set this limit to 64k I would expect to get a maximum of 41 TEXT
columns before this error occured?

2. Maximum Row Length for TEXT and BLOB columns is not mentioned, but 4GB limit is
mentioned for LONGTEXT and LONGBLOB columns.

3. Total Row Length cannot exceed 4GB.

4. "The internal maximum key length is 3500 bytes, but MySQL itself restricts this to 1024
bytes." - Not sure what this means  

You mentioned "column prefix indexes", not sure if the index I created is the same thing
so I removed this as well as the INT field and the problem still occurs. I.e. I had a
record with 11 TEXT fields only.

As a standard build, I find it hard to believe MySQL/InnoDB cannot support 11 TEXT fields
in one table. An 8000 byte limit for "internal" information about column prefix indexes
seems very small.

Are there any links I can read to help my confusion about what limits apply and when. More
importantly what changes can I make to help me solve this problem.

Many thanks for your time.

另外一篇介绍文章：http://www.cnblogs.com/analytics/archive/2010/10/05/1844262.html

您可能也喜欢：
优化MySQL语句的十个建议	mysql各种HA方案	深入Mysql字符集设置	MySQL传输二进制日志原理
无觅

00 – 背景知识

- B-Tree & B+Tree

http://en.wikipedia.org/wiki/B%2B_tree
http://en.wikipedia.org/wiki/B-tree

- 折半查找(Binary Search)

http://en.wikipedia.org/wiki/Binary_search_algorithm

- 数据库的性能问题

A. 磁盘IO性能非常低，严重的影响数据库系统的性能。
B. 磁盘顺序读写比随机读写的性能高很多。

- 数据的基本存储结构

A. 磁盘空间被划分为许多大小相同的块（Block）或者页(Page).
B. 一个表的这些数据块以链表的方式串联在一起。
C. 数据是以行（Row）为单位一行一行的存放在磁盘上的块中,如图所示.
D. 在访问数据时，一次从磁盘中读出或者写入至少一个完整的Block。

                   Fig. 1

01 – 数据基本操作的实现

基本操作包括：INSERT、UPDATE、DELETE、SELECT。

- SELECT

A. 定位数据
B. 读出数据所在的块，对数据加工
C. 返回数据给用户

- UPDATE、DELETE

A. 定位数据
B. 读出数据所在的块，修改数据
C. 写回磁盘

- INSERT

A. 定位数据要插入的页（如果数据需要排序）
B. 读出要插入的数据页，插入数据.
C. 写回磁盘

如何定位数据？
- 表扫描(Table Scan)

A. 从磁盘中依次读出所有的数据块，一行一行的进行数据匹配。
B. 时间复杂度 是O(n)， 如果所有的数据占用了100个块。尽管只查询一行数据，
也需要读出所有100个块的数据。
C. 需要大量的磁盘IO操作，极大的影响了数据定位的性能。

因为数据定位操作是所有数据操作必须的操作，数据定位操作的效率会直接影响所有的数据操作的效率。
因此我们开始思考，如何来减少磁盘的IO？
- 减少磁盘IO

A. 减少数据占用的磁盘空间
压缩算法、优化数据存储结构
B. 减少访问数据的总量
读出或写入的数据中，有一部分是数据操作所必须的，这部分称作有效数据。剩余的
部分则不是数据操作必须的数据，称为无效数据。例如，查询姓名是‘张三’的记录。
那么这条记录是有效记录，其他记录则是无效记录。我们要努力减少无效数据的访问。

02 – 索引的产生

- 键(Key)

首先，我们发现在多数情况下，定位操作并不需要匹配整行数据。而是很规律的只匹配某一个
或几个列的值。 例如，图中第1列就可以用来确定一条记录。这些用来确定一条数据的列，统
称为键(Key).

        Fig. 2

- Dense Index

根据减少无效数据访问的原则，我们将键的值拿过来存放到独立的块中。并且为每一个键值添
加一个指针， 指向原来的数据块。如图所示,

            Fig. 3

  这就是‘索引’的祖先Dense Index. 当进行定位操作时，不再进行表扫描。而是进行
  索引扫描(Index Scan)，依次读出所有的索引块，进行键值的匹配。当找到匹配的键值后，
根据该行的指针直接读取对应的数据块，进行操作。假设一个块中能存储100行数据，
10,000,000行的数据需要100,000个块的存储空间。假设键值列（+指针）占用一行数据
1/10的空间。那么大约需要10,000个块来存储Dense索引。因此我们用大约1/10的额外存储
空间换来了大约全表扫描10倍的定位效率。

03 – 索引的进化

  在实际的应用中，这样的定位效率仍然不能满足需求。很多人可能已经想到了，通过排序和查找
  算法来减少IO的访问。因此我们开始尝试对Dense Index进行排序存储,并且期望利用排序查
  找算法来减少磁盘IO。

- 折半块查找

A. 对Dense Index排序
B. 需要一个数组按顺序存储索引块地址。以块为单位，不存储所有的行的地址。
C. 这个索引块地址数组，也要存储到磁盘上。将其单独存放在一个或多个连续的块中，如下图所示。
D. 折半查找的时间复杂度是O(logN)。在上面的列子中，dense索引总共有10,000个块。假设1个块
能存储2000个指针，需要5个块来存储这个数组。通过折半查找，我们最多只需要读取
5（数组块）+100（索引块）+1（数据块）=106个块。

                    Fig. 4

- Sparse Index

实现基于块的折半查找时发现，读出每个块后只需要和第一行的键值匹配，就可以决定下一个块
的位置（方向）。 因此有效数据是每个块（最后一个块除外）的第一行的数据。还是根据减少无
效数据IO的原则，将每一个块的第一行的数据单独拿出来，和索引数组的地址放到一起。这样就
可以直接在这个数组上进行折半查找了。如下图所示，这个数组就进化成了Sparse Index。

                    Fig. 5

  因为Sparse Index和Dense Index的存储结构是相同的，所以占用的空间也相同。大约需
要10个块来存储10000个Dense Index块的地址和首行键值。通过Sparse索引，仅需要读
取10(Sparse块)+1(Dense块)+1(数据块)=12个块.

- 多层Sparse Index

因为Sparse Index本身是有序的，所以可以为Sparse Index再建sparse Index。通过
这个方法，一层一层的建立 Sparse Indexes,直到最上层的Sparse Index只占用一个块
为止,如下图所示.

                   Fig. 6

  A. 这个最上层的Sparse Index称作整个索引树的根(root).
B. 每次进行定位操作时，都从根开始查找。
C. 每层索引只需要读出一个块。
D. 最底层的Dense Index或数据称作叶子(leaf).
E. 每次查找都必须要搜索到叶子节点，才能定位到数据。
F. 索引的层数称作索引树的高度(height).
G. 索引的IO性能和索引树的高度密切相关。索引树越高，磁盘IO越多。

在我们的例子中的Sparse Index，只有10个块，因此我们只需要再建立一个Sparse Index.
通过两层Sparse Index和一层Dense Index查找时，只需读取1+1+1+1=4个块。

- Dense Index和Sparse Index的区别

A. Dense Index包含所有数据的键值，但是Sparse Index仅包含部分键值。
Sparse Index占用更少的磁盘空间。
B. Dense Index指向的数据可以是无序的，但是Sparse Index的数据必须是有序的。
C. Sparse Index 可以用来做索引的索引，但是Dense Index不可以。
D. 在数据是有序的时候，Sparse Index更有效。因此Dense Index仅用于无序的数据。

- 簇索引(Clustered Index)和辅助索引(Secondary Index)

如果数据本身是基于某个Key来排序的，那么可以直接在数据上建立sparse索引，
而不需要建立一个dense索引层。 如下图所示：

                Fig. 7

  这个索引就是我们常说的“Clustered Index”,而用来排序数据的键叫做主键Primary Key.

A. 一个表只能有一个Clustered Index,因为数据只能根据一个键排序.
B. 用其他的键来建立索引树时，必须要先建立一个dense索引层，在dense索引层上对此键的值
进行排序。这样的索引树称作Secondary Index.
C. 一个表上可以有多个Secondary Index.

- 范围搜索(Range Search)

由于键值是有序的，因此可以进行范围查找。只需要将数据块、Dense Index块分别以双向链表
的方式进行连接， 就可以实现高效的范围查找。如下图所示：

               Fig. 8

  范围查找的过程：

  A. 选择一个合适的边界值，定位该值数据所在的块

  B. 然后选择合适的方向，在数据块（或Dense Index块）链中进行遍历。

  C. 直到数据不满足另一个边界值，结束范围查找。

是不是看着这个索引树很眼熟？换个角度看看这个图吧！

Fig. 9

这分明就是传说中的B+Tree.

- 索引上的操作

  A. 插入键值

  B. 删除键值

  C. 分裂一个节点

  D. 合并两个节点

这些操作在教科书上都有介绍，这里就不介绍了。

先写到这吧，实在写不动了，想明白容易，写明白就难了。下一篇里，打算谈谈标准B+Tree的几个问题，以及在

实现过程中，B+Tree的一些变形。

很多知识来自于下面这两本书。

“Database Systems: The Complete Book (2nd Edition) ”
“Transaction Processing: Concepts and Techniques”

您可能也喜欢：
MySQL索引的索引长度问题	查看mysql索引使用情况	MySQL索引分析和优化（转）	MongoDB 索引数据类型优化，节省60％内存
无觅

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。
2. 从库运行"IO线程"（Slave IO Thread）读取主库的二进制日志。
3. 从库运行"SQL线程"（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。
2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。
3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。

相关教程:

MySQL传输二进制日志原理:http://blog.haohtml.com/archives/12094

您可能也喜欢：
图解”How MySQL Replication Works”	Mysql中出现的＂MySQL Got error 139 from storage engine＂的原因	优化MySQL语句的十个建议	深入Mysql字符集设置
无觅

MySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication，本文将通过二进制日志相关源代码的主要接口来解释：“MySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？”。

在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图：

在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；

新日志在产生后，只需一次广播和网络就会立刻（<1ms）向发送到备库，如果主备之间网络较好的话（例如RTT<1ms），备库端的日志也就小于2ms了。所以，一般的（依赖于RTT），备库的实时性都非常好。

参考：

1. MySQL Replication Manual

2. 图解"How MySQL Replication Works"

您可能也喜欢：
优化MySQL语句的十个建议	使用MySQL Proxy和MySQL Replication实现读写分离	MySQL远程访问时非常慢的解决办法	Mysql中出现的＂MySQL Got error 139 from storage engine＂的原因
无觅

这是本系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化

数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化：

• query_cache_size/query_cache_type （global）

Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求（未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache），MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤（如 SQL语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。

当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。

Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有显示要求才使用query cache（使用sql_cache）。

• binlog_cache_size （global）

Binlog Cache 用于在打开了二进制日志（binlog）记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。

一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件（binlog_cache_disk_use）来缓存了。

• key_buffer_size （global）

Key Buffer 可能是大家最为熟悉的一个 MySQL 缓存参数了，尤其是在 MySQL 没有更换默认存储引擎的时候，很多朋友可能会发现，默认的 MySQL 配置文件中设置最大的一个内存参数就是这个参数了。key_buffer_size 参数用来设置用于缓存 MyISAM存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。

此外，当我们在使用MyISAM 存储的时候有一个及其重要的点需要注意，由于 MyISAM 引擎的特性限制了他仅仅只会缓存索引块到内存中，而不会缓存表数据库块。所以，我们的 SQL 一定要尽可能让过滤条件都在索引中，以便让缓存帮助我们提高查询效率。

• bulk_insert_buffer_size （thread）

和key_buffer_size一样，这个参数同样也仅作用于使用 MyISAM存储引擎，用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候，会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件：

insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表)

• innodb_buffer_pool_size（global）

当我们使用InnoDB存储引擎的时候，innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了，他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小，类似于 MyISAM 存储引擎的 key_buffer_size 参数，当然，可能更像是 Oracle 的 db_cache_size。简单来说，当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。

和key_buffer_size 对于 MyISAM 引擎一样，innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小，直接关系到 InnoDB存储引擎的性能，所以如果我们有足够的内存，尽可将该参数设置到足够打，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。

我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。

• innodb_additional_mem_pool_size（global）

这个参数我们平时调整的可能不是太多，很多人都使用了默认值，可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。

这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。

• innodb_log_buffer_size （global）

这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。

此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。

• innodb_max_dirty_pages_pct （global）

这个参数和上面的各个参数不同，他不是用来设置用于缓存某种数据的内存大小的一个参数，而是用来控制在 InnoDB Buffer Pool 中可以不用写入数据文件中的Dirty Page 的比例（已经被修但还没有从内存中写入到数据文件的脏数据）。这个比例值越大，从内存到磁盘的写入操作就会相对减少，所以能够一定程度下减少写入操作的磁盘IO。

但是，如果这个比例值过大，当数据库 Crash 之后重启的时间可能就会很长，因为会有大量的事务数据需要从日志文件恢复出来写入数据文件中。同时，过大的比例值同时可能也会造成在达到比例设定上限后的 flush 操作“过猛”而导致性能波动很大。

您可能也喜欢：
优化MySQL语句的十个建议	mysql limit查询优化	MySQL性能优化的最佳20+条经验	mysql优化-缓存篇
无觅

innodb_data_file_path=datafile_spec1[;datafile_spec2]...

[mysqld]
innodb_data_file_path = /db/ibdata1:2000M;/dr2/db/ibdata2:2000M:autoextend

mysql> show variables like 'innodb_file_per_table'\G;
*************************** 1. row ***************************
Variable_name: innodb_file_per_table
Value: ON
1 row in set (0.00 sec)

mysql> system ls -lh /usr/local/mysql/data/member/*
-rw-r-----  1 mysql mysql 8.7K 2009-02-24  /usr/local/mysql/data/member/ Profile.frm
-rw-r-----  1 mysql mysql 1.7G  9月 25 11:13 /usr/local/mysql/data/member/ Profile.ibd
-rw-rw----  1 mysql mysql 8.7K  9月 27 13:38 /usr/local/mysql/data/member/t1.frm
-rw-rw----  1 mysql mysql  17M  9月 27 13:40 /usr/local/mysql/data/member/t1.ibd
-rw-rw----  1 mysql mysql 8.7K  9月 27 15:42 /usr/local/mysql/data/member/t2.frm
-rw-rw----  1 mysql mysql  17M  9月 27 15:54 /usr/local/mysql/data/member/t2.ibd

mysql> show variables like 'innodb%log%'\G;
*************************** 1. row ***************************
Variable_name: innodb_flush_log_at_trx_commit
Value: 1
*************************** 2. row ***************************
Variable_name: innodb_locks_unsafe_for_binlog
Value: OFF
*************************** 3. row ***************************
Variable_name: innodb_log_buffer_size
Value: 8388608
*************************** 4. row ***************************
Variable_name: innodb_log_file_size
Value: 5242880
*************************** 5. row ***************************
Variable_name: innodb_log_files_in_group
Value: 2
*************************** 6. row ***************************
Variable_name: innodb_log_group_home_dir
Value: ./
*************************** 7. row ***************************
Variable_name: innodb_mirrored_log_groups
Value: 1
7 rows in set (0.00 sec)

090924 11:39:44  InnoDB: ERROR: the age of the last checkpoint is 9433712,

InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
090924 11:40:00  InnoDB: ERROR: the age of the last checkpoint is 9433823,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
090924 11:40:16  InnoDB: ERROR: the age of the last checkpoint is 9433645,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

您可能也喜欢：
mysql中使用InnoDB还是MyISAM ?	优化MySQL语句的十个建议	Mysql中出现的＂MySQL Got error 139 from storage engine＂的原因	mysql各种HA方案
无觅

并不是所有MySQL都运行在Linux下，windows下也需要做例行备份，下面是用bat脚本做自动化备份的例子，大家可以参考下。

rem
rem C:\Program Files\WinRAR 需要放到 path 下，才能调用rar cli工具
rem
rem 跳转到工作目录下
f:
cd f:\DBBAK
rem 设置变量：备份文件名
SET BAK_FILE=MY_DBBAK_%date:~0,-4%.sql
rem 设置变量：日志文件名
SET LOG_FILE=MY_DBBAK.log
rem 记录日志
echo "%date%" >> %LOG_FILE%
rem 开始做备份
mysqldump --default-character-set=utf8 -hlocalhost -uroot -R --triggers --single-transaction -B mydb > %BAK_FILE%
rem 压缩备份文件
rar a %BAK_FILE%.rar %BAK_FILE%
rem 删除源文件
del /F %BAK_FILE%
echo "%date%" >> %LOG_FILE%
echo "" >> %LOG_FILE%

部署完脚本后，剩下的就是在系统中添加“计划任务”项目了。

您可能也喜欢：
使用MySQL Proxy和MySQL Replication实现读写分离	优化MySQL语句的十个建议	图解"How MySQL Replication Works"	Mysql中出现的＂MySQL Got error 139 from storage engine＂的原因
无觅

mysqladmin -uroot -proot kill xxxxx

如果是系统里的mysql进程的话,可以参考:http://www.chengyongxu.com/blog/%E6%89%B9%E9%87%8F%E6%9D%80%E6%AD%BBmysql%E8%BF%9B%E7%A8%8B/

您可能也喜欢：
优化MySQL语句的十个建议	使用mysql-proxy实现mysql读写分离	mysql各种HA方案	使用MySQL Proxy和MySQL Replication实现读写分离
无觅