日期:2014-05-16  浏览次数:20932 次

MySQL语句的优化
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.拆分你的表

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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)
);