优化mysql语句的几个绝招

《优化mysql语句的几个绝招》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、优化MySQL语句的几个绝招Jaslabs的JustinSilverton列出了十条有关优化MySQL查询的语句，我不得不对此发表言论，因为这个清单非常非常糟糕。另外一个Mike也同样意识到了。所以在这个博客中，我要做两件事情，第一，指出为什么这个清单很糟糕，第二，列出我的清单，希望我的比较好些。继续看吧，无畏的读者们！为什么那个清单很糟糕 1.很好的问题，但是很糟糕的解决方法Silverton先生提出了一些很好的问题。MySQL针对长度可变的列如TEXT或BLOB，将会使用动态行格式(dynamicrowformat)，这意味着

2、排序将在硬盘上进行。我们的方法不是要回避这些数据类型，而是将这些数据类型从原来的表中分离开，放入另外一个表中。下面的schema可以说明这个想法：1.CREATETABLEposts(2.idintUNSIGNEDNOTNULLAUTO_INCREMENT,3.author_idintUNSIGNEDNOTNULL,4.createdtimestampNOTNULL,5.PRIMARYKEY(id)6.);7. 8.CREATETABLEposts_data(9.post_idintUNSIGNEDNOTNULL.10.bodyt

3、ext,11.PRIMARYKEY(post_id)12.);2.他的力气没使对地方我们要遵循的一个准则就是如果你要优化代码时，应该先找出瓶颈在哪。然而Silverton先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基础的。你需要知道join和子查询的区别，列索引，以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现，例如COUNT(*)可能很快也可能很慢，要看你选用什么数据库引擎。还有一些其他要考虑的因素，例如数据库在什么时候不用缓存，什么时候存在硬盘上而不存在内存中，什么时候数据

4、库创建临时表等等。剩下的5%就很少会有人碰到了，但Silverton先生恰好在这上面花了大量的时间。我从来就没用过SQL_SAMLL_RESULT。3.有点匪夷所思……他的许多建议都是让人非常吃惊的，譬如“移除不必要的括号”。你这样写SELECT*FROMpostsWHERE(author_id=5ANDpublished=1)，还是这样写SELECT*FROMpostsWHEREauthor_id=5ANDpublished=1，都不重要。任何比较好的DBMS都会自动进行识别做出处理。这种细节就好像C语言中是i++快些还是++i

5、快些。真的，如果你把精力都花在这上面了，那就不用写代码了。 我的列表看看我的列表是不是更好吧。我先从最普遍的开始。 1.减小你的schema在你开始写查询语句之前，你需要设计schema。记住将一个表装入内存所需要的空间大概是行数*一行的大小。除非你觉得世界上的每个人都会在你的网站注册2兆8000亿次的话，否则你不需要采用BITINT作为你的user_id。同样的，如果一个文本列是固定大小的话（譬如US邮编，通常是”XXXXX-XXXX”的形式），采用VARCHAR的话会给每行增加多余的字节。有些人对数据库规范化不以为意，他们说这

6、样会形成相当复杂的schema。然而适当的规范化会减少化冗余数据。（适当的规范化）就意味着牺牲少许性能，换取整体上更少的footprint，这种性能换取内存在计算机科学中是很常见的。最好的方法是IMO，就是开始先规范化，之后如果性能需要的话，再反规范化。你的数据库将会更逻辑化，你也不用过早的进行优化。（译者注，这一段我不是很理解，可能翻译错了，欢迎纠正。）2.拆分你的表通常有些表只有一些列你是经常需要更新的。例如对于一个博客，你需要在许多不同地方显示标题（如最近的文章列表），只在某个特定页显示概要或者全文。水平垂直拆分是很有帮助的

7、：1.CREATETABLEposts_tags(2.relation_idintUNSIGNEDNOTNULLAUTO_INCREMENT,3.post_idintUNSIGNEDNOTNULL,4.tag_idintUNSIGNEDNOTNULL,5.PRIMARYKEY(relation_id),6.UNIQUEINDEX(post_id,tag_id)7.);artificialkey完全是多余的，而且post-tag关系的数量将会受到整形数据的系统最大值的限制。1.CREATETABLEposts_tags(2.post

8、_idintUNSIGNEDNOTNULL,3.tag_idintUNSIGNEDNOTNULL,4.PRIMARYKEY(post_id,tag_id)5.);3.学习索引你选择的索引的好坏很重要，不好的话可能破坏数据库。对那些还没有在数据库学习