1.根据提供的查询和执行计划可以推断出： 表cat的catid字段上建有UNIQUE的索引，因此的你的查询可以简化成：SELECT d.catid,d.catname,COUNT(a.info_id) AS info_count FROM cnsb_product a WITH(NOLOCK) --LEFT JOIN cat b WITH(NOLOCK) ON a.cat_parentid = b.catid --LEFT JOIN cat c WITH(NOLOCK) ON a.cat_childid = c.catid LEFT JOIN cat d WITH(NOLOCK) ON a.cat_rootid = d.catid --LEFT JOIN cat e WITH(NOLOCK) ON a.order4 = e.catid WHERE ...... GROUP BY d.catid,d.catname2.你说的慢n倍，是如何比较的，只是单纯的比较完成查询所需要的时间嘛？ 比较的环境是否一致？热缓存还是冷缓存？3.开启 SET STATISTICS IO ON 对比分析一下两个查询的输出4.sp_helpindex cnsb_product 提供该结果集，进一步分析5.并对所使用的关键索引输出DBCC SHOW_STATISTICS结果
请提供：
1、索引情况
2、cnsb_product记录量，cat_childid= 5889的记录量，数据密度、分布情况怀疑因索引只得执行全表扫描，计划只能执行嵌套迭代，而一旦发生嵌套迭代时联结的表内层或外层的顺序对磁盘I/O开销及顶部输入的行数影响匹配次数
1、索引不合理
2、重建索引试试查询优化器会首先考虑Nested Loop和Sort-Merge的，而且只有两个集合量量大且没有合适的索引或无序时，才会考虑使用Hash Join。
把cat_childid上面的索引去掉然後再帖一次执行计划.
(文字形式)
parentid=9的记录是多少
聚集索引是哪个？
product表：50万记录
cat表:8千记录
product表聚集索引:info_id
cat表聚集索引:catid
比如说在有排序字段的时候,查询条件阻止了根据排序字段的扫描，这样会更加额外的排序操作，从而大大降低了查询效率而你的环境中也出现了类似这种情况。
去掉cat_childid上的索引执行计划图：
表cat的catid字段上建有UNIQUE的索引，因此的你的查询可以简化成：SELECT d.catid,d.catname,COUNT(a.info_id) AS info_count
FROM cnsb_product a WITH(NOLOCK)
--LEFT JOIN cat b WITH(NOLOCK) ON a.cat_parentid = b.catid
--LEFT JOIN cat c WITH(NOLOCK) ON a.cat_childid = c.catid
LEFT JOIN cat d WITH(NOLOCK) ON a.cat_rootid = d.catid
--LEFT JOIN cat e WITH(NOLOCK) ON a.order4 = e.catid
WHERE ......
GROUP BY d.catid,d.catname2.你说的慢n倍，是如何比较的，只是单纯的比较完成查询所需要的时间嘛？
比较的环境是否一致？热缓存还是冷缓存？3.开启 SET STATISTICS IO ON 对比分析一下两个查询的输出4.sp_helpindex cnsb_product 提供该结果集，进一步分析5.并对所使用的关键索引输出DBCC SHOW_STATISTICS结果