本篇文章为大家展示了优化查询语句的建议具体是什么,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。
我要做两件事情,第,一指出为什么这个清单很糟糕,第二,列出我的清单,希望我的比较好些。继续看吧,无畏的读者们!
为什么那个清单很糟糕
1。他的力气没使对地方
我们要遵循的一个准则就是如果你要优化代码时,应该先找出瓶颈在哪。然西弗敦而先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基础的。你需要知道连接和子查询的区别,列索引,以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现,例如COUNT(*)可能很快也可能很慢,要看你选用什么数据库引擎。还有一些其他要考虑的因素,例如数据库在什么时候不用缓存,什么时候存在硬盘上而不存在内存中,什么时候数据库创建临时表等等。剩下的5%就很少会有人碰到了,但西弗敦先生恰好在这上面花了大量的时间。我从来就没用过SQL_SAMLL_RESULT。
2。很好的问题,但是很糟糕的解决方法西弗敦
,先生提出了一些很好的问题.MySQL针对长度可变的列如文本或BLOB,将会使用动态行格式(动态行格式),这意味着排序将在硬盘上进行。我们的方法不是要回避这些数据类型,而是将这些数据类型从原来的表中分离开,放入另外一个表中。下面的模式可以说明这个想法:
3。有点匪夷所思,白马王子,白马王子
他的许多建议都是让人非常吃惊的,譬如“移除不必要的括号”。你这样写SELECT *从文章(author_id=5和出版=1),还是这样写SELECT * FROM帖子author_id=5和出版=1,都不重要。任何比较好的DBMS都会自动进行识别做出处理。这种细节就好像C语言中是我+ +快些还是+ +我快些。真的,如果你把精力都花在这上面了,那就不用写代码了。
我的列表
看看我的列表是不是更好吧。我先从最普遍的开始。
1。建立基准,建立基准,建立基准!
如果需要做决定的话,我们需要数据说话。什么样的查询是最糟的?瓶颈在哪?我什么情况下会写出糟糕的查询吗?基准测试可以让你模拟高压情况,然后借助性能测评工具,可以让你发现数据库配置中的错误。这样的工具有supersmack, ab, SysBench。这些工具可以直接测试你的数据库(譬如supersmack),或者模拟网络流量(譬如ab)。
2。性能测试,性能测试,性能测试!
那么,当你能够建立一些高压情况之后,你需要找出配置中的错误。这就是性能测评工具可以帮你做的了。它可以帮你发现配置中的瓶颈,不论是在内存中,CPU中,网络中,硬盘I/O,或者是以上皆有。
你要做的第一件事就是开启慢查询日志(慢速查询日志),装上mtop。支持这样你就能获取那些恶意的入侵者的信息了。有需要运行10秒的查询语句正在破坏你的应用程序吗?这些家伙会展示给你看他的查询语句是怎么写的。
在你发现那些很慢的查询语句后,你需要用MySQL自带的工具,如解释,显示状态,显示PROCESSLIST。它们会告诉你资源都消耗在哪了,查询语句的缺陷在哪,譬如一个有三次加入子查询的查询语句是否在内存中进行排序,还是在硬盘上进行。当然你也应该使用测评工具如,procinfo, vmstat等等获取更多系统性能信息。
3。减小你的模式
在你开始写查询语句之前,你需要设计模式。记住将一个表装入内存所需要的空间大概是行数*一行的大小。除非你觉得世界上的每个人都会在你的网站注册2兆亿8000次的话,否则你不需要采用BITINT作为你的user_id。同样的,如果一个文本列是固定大小的话(譬如我们邮编,通常是“XXXXX-XXXX”的形式),采用VARCHAR的话会给每行增加多余的字节。
