以淘宝商品搜索漫谈查询条件的排序对效率的影响(SQL查询性能优化,附调优(性能诊断)DMV)

　有时候一个念头或想法在不经意间蹦出——就像是一段美好的邂逅，让人淡然而有些欣喜。写这篇博客的由来也是如此，——“查询条件的排序的不同可能会对查询效率有影响”的想法突然出现在我的脑海里，而且我饶有兴致的细想了下，经过测试，但无奈的是我本地只有2w多的数据量，数据量太小，无法测试出其真实的结果，这也是为何这篇博客的标题中说是'漫谈'的原因;'漫谈'很可能就是乱弹，我所说的只是我想当然的，未经证实；但我仍想也感觉有必要把所考虑的跟大家分享交流下，就是板儿砖满天飞也无所谓，以求正解！

　　

　　  如上图，就是淘宝网的商品搜索页，我所要说的会直截了当的围绕上图谈起——只用看上图中绿色框部分，对于搜索功能的sql查询，分别是 价格和分类 这两个查询(where)条件，单就(where)条件的拼接有以下两种写法（以下sql只是为了辅助说明我的想法而已，非淘宝真实实现）：

　　  1.select * from product where price>=45 and price<=138 and category='恒源祥'

　　  2.select * from product where category='恒源祥' and price>=45 and price<=138

　　  两条sql看起来一样，最后查询到的结果也相同，只是查询条件价格和分类的顺序不同。以SQL Server为例，我不清楚数据库sql查询分析引擎是否会对查询sql语句进行优化或其它处理——排除这点，我认为第二条sql的执行效率会更高、查询速度会更快，理由是：在淘宝网海量的商品数据中进行上面的搜索查询，如果sql语句是(查询条件)分段处理的话，第一条sql的第一个条件(price>=45 and price<=138)肯定要比第二条sql的第一个条件(category='恒源祥')返回的数据要多，因为基本上每种分类中都可能存在(price>=45 and price<=138)的商品信息，这样从第一个条件返回的结果中进行第二个条件的筛选——相当于是分别从1000w和10w记录数的两个表中进行数据查询，数据量少的相对而言查询速度会更快，于是，第二条sql的整体查询速度会更快。

　　 如果我以上的设想或考虑成立，我倒是感觉为了提高查询效率，应该在每个项目的后台管理中可以动态根据不同时期或情况设置数据查询各个条件的排序。

　　 此文就写到这里，提出两个问题，希望知道的朋友能不吝赐教！

       Q1：数据库sql查询分析引擎是否会对查询sql语句进行优化或其它处理？

　　 Q2：本文所说的观点是否正确？

　　 最后，附上SQL Server调优(性能诊断)DMV查询SQL，希望对需要的朋友有所帮助。

 1 set transaction isolation level read uncommitted
 2 
 3 select top 20
 4 CAST(qs.total_elapsed_time/1000000.0 as decimal(28,2))
 5 as [Total Elapsed Duration (s)]
 6 ,qs.execution_count
 7 ,SUBSTRING(qt.text,(qs.statement_start_offset/2)+1,
 8 ((Case when qs.statement_end_offset=-1
 9 Then len(CONVERT(Nvarchar(max),qt.text))*2
10 else
11 qs.statement_end_offset
12 end - qs.statement_start_offset)/2)+1) as [Individual Query]
13 ,qt.text as [Parent Query]
14 ,DB_NAME(qt.dbid) as databseName
15 ,qp.query_plan
16 from sys.dm_exec_query_stats qs
17 cross apply sys.dm_exec_sql_text(qs.sql_handle) qt
18 cross apply sys.dm_exec_query_plan(qs.plan_handle) qp
19 
20 order by total_elapsed_time desc

　　查询结果如下：

　　

      通过以上查询可以得到最消耗性能的前20条SQL语句，并对其进行优化处理！

 

分类: 数据库

标签: 软件开发, 淘宝技术分析, SQL查询性能优化, 查询性能优化, 数据库优化   http://www.cnblogs.com/know/archive/2012/12/26/2834324.html