优化查询语句的建议具体是什么

本文向您展示了优化查询语句的建议。内容简洁易懂，一定会让你眼前一亮。希望通过这篇文章的详细介绍，你能有所收获。

我想做两件事。首先，指出为什么这个列表如此糟糕。第二，列我的清单。我希望我的更好。继续看，无畏的读者们！

为什么这个名单很可怕？

他的力量不在正确的地方

我们应该遵循的规则之一是，如果你想优化代码，你应该首先找出瓶颈在哪里。然而，西尔弗顿先生的实力并不在合适的位置。我认为60%的优化是基于对SQL和数据库基础的清晰理解。您需要知道联接与子查询、列索引之间的区别，以及如何规范化数据等。另外35%的优化需要知道数据库选择的性能。例如，COUNT (*)可能很快，也可能很慢，这取决于您选择的数据库引擎。还有其他需要考虑的因素，比如什么时候不需要缓存数据库，什么时候数据库存在于硬盘上但不在内存中，什么时候数据库创建临时表等等。很少有人会满足剩下的5%，但西尔弗顿先生只是在这上面花了很多时间。我从来没有用过SQL_SAMLL_RESULT。

2.一个好问题，但是一个坏的解决方案。

西尔弗顿先生提出了一些好问题。MySQL将对可变长度的列使用动态行格式，例如TEXT或BLOB，这意味着排序将在硬盘上完成。我们的方法不是避免这些数据类型，而是将这些数据类型从原始表中分离出来，放在另一个表中。下面的模式可以说明这个想法：

双击代码全选。

一个

2

三

四

五

六

七

八

九

10

11创建表帖子(id int UNSIGNED NOT NULL AUTO _ INCREMENT，author_id int UNSIGNED NOT NULL，创建的时间戳NOT NULL，主键(id))；CREATE TABLE post _ data(post _ id int UNSIGNED NOT NULL。正文，PRIMAry KEY(post _ id))；3.有点奇怪。helliphellip

他的许多建议都非常令人惊讶，比如“去掉不必要的括号”。无论您是从(author _ id=5且published=1)的帖子中编写select *还是从author _ id=5且published=1的帖子中编写select *都没有关系。任何好的数据库管理系统都会自动识别和处理它。这种细节就像是我是更快还是我用C语言更快。真的，如果你把所有的精力都花在这上面，那么你就不用写代码了。

我的列表

让我们看看我的清单是否更好。我从最常见的开始。

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

　 　上面的 schema 是对读数据进行的优化。经常要访问的数据存在一个表中，那些不经常访问的数据放在另一个。被拆分后，不经常访问的数据占据更少的内存。你也可以优化写数 据，经常更新的数据放在一个表，不经常更新的放在另一个表。这可以使缓存更高效，因为 MySQL 不需要让没有更新过的数据移出缓存。
　　5. 不要过度使用 artificial primary key
　 　artificial primary key 非常棒，因为他们使得 schema 更少的变化。如果我们将地理信息存在以美国邮编为基础的表中，如果邮编系统突然改变了，那我们就会有大麻烦了。另一方面，采用 natural key 有时候也很棒，譬如我们需要 join 多对多的关系表时，我们不应该这样：

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

　　6. 学习索引
　 　你选择的索引的好坏很重要，不好的话可能破坏数据库。对那些还没有在数据库学习很深入的人来说，索引可以看作是就是 hash 排序。例如如果我们用查询语句 SELECT * FROM users WHERE last_name = ‘Goldstein’，而 last_name 没有索引的话，那么 DBMS 将会查询每一行，看看是否等于“Goldstein”。索引通常是B-tree(还有其他的类型)，可以加快比较的速度。
　　你需要给你要 select,group,order,join 的列加上索引。显然每个索引所需的空间正比于表的行数，所以越多的索引将会占用更多的内存。而且写数据时，索引也会有影响，因为每次写数据时都会更新对应 的索引。你需要取一个平衡点，取决每个系统和实施代码的需要。

上述内容就是优化查询语句的建议具体是什么，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。