每月几十万条数据，查询太慢了

[420jil]

有两张表，一个是流水表，一个是部门表，流水表一个月50万左右的数据，部门表400多条。两个表联合查询进行统计，如下，其中OrganizationId IN('31b05701-60ef-405c-87ba-af47049e3f48部分是进行权限设置，最多有400个部门。现在只有一个月的数据，查询时间就达到7秒。大家帮忙看看，问题是出在哪？如何优化，多谢了

SELECT Departcode='1000',departname='医院',EmployCode='',realname='医院总计',sum(expenses) expenses,sum(jixiao) jixiao,
CONVERT(varchar(7), FeeTime, 120) as FeeTime FROM serV_Employee_JournalItem j join bpms_organization o on o.code=j.departcode 
WHERE departcode is not null AND year(feeTime)='2016' and month(feetime)='02' and workkind in('医疗','医技') 
and  clinicitemclass in (2,4) AND OrganizationId IN('31b05701-60ef-405c-87ba-af47049e3f48','297cd29a-fb66-42fb-9ba0-bad60fc8144d',
'21e34fa7-e4b2-4aa7-8c44-b38302c9138b','01bddbb4-df03-40c6-82fa-89ed93852d5f','e4ecb3a2-b59a-46fd-b300-0dddb3f7d1bc'............)
 group by CONVERT(varchar(7), FeeTime, 120) 
union all 
SELECT Departcode,departname,EmployCode='',realname='科室总计',sum(expenses) expenses,sum(jixiao) jixiao,
CONVERT(varchar(7), FeeTime, 120) as FeeTime FROM serV_Employee_JournalItem  j join bpms_organization o on o.code=j.departcode 
WHERE departcode is not null  AND year(feeTime)='2016' and month(feetime)='02' and workkind in('医疗','医技') and  
clinicitemclass in (2,4) AND OrganizationId IN('31b05701-60ef-405c-87ba-af47049e3f48','297cd29a-fb66-42fb-9ba0-bad60fc8144d',
'21e34fa7-e4b2-4aa7-8c44-b38302c9138b','01bddbb4-df03-40c6-82fa-89ed93852d5f','e4ecb3a2-b59a-46fd-b300-0dddb3f7d1bc'............)
 group by Departcode, departname,CONVERT(varchar(7), FeeTime, 120)

[crazy_boom]

这么大的数据 像你这么写 不慢 才怪呢 还不如把你要in的数据 都写入临时表 然后 join 这个临时表 速度会有很大提升 字段 clinicitemclass， departcode，feeTime，OrganizationId创建索引

[顾西昂]

少用in 多用左联 右联接 多用临时表暂存数据 然后再查询

[shoppo0505]

就这么点点数据就这么慢,肯定是没有添加合适的index

[spiritofdragon]

1、如果OrganizationId in 后面能到400个这个数量级的话，建议把它们放进表变量，去join，不要in 了 2、FeeTime 有索引没？把你的FeeTime 写法改成能用到索引的写法。如 where FeeTime >= ‘2016-02-01’ and FeeTime <‘2016-03-01’ 3、其他看执行计划再研究吧。

[shoppo0505]

引用 6 楼 yenange 的回复:

最失败的一点： 表的主键用了GUID， 这种ID是最慢的， 会迅速形成索引碎片， 而且毫无顺序可言。 建议改成： bigint 或者 int

这个严重反对

[Ny-6000]

主要三点, 1时间统计这个判断可能优化,没必要写2个组合,一个就足够了 日期类型的,可以用系统方法datediff()判断大小, 2用in的太多了,尽量用关联表实现 3建索引,这个会有很明显提升的

[吉普赛的歌]

引用 7 楼 shoppo0505的回复:

[quote=引用 6 楼 yenange 的回复:] 最失败的一点： 表的主键用了GUID， 这种ID是最慢的， 会迅速形成索引碎片， 而且毫无顺序可言。 建议改成： bigint 或者 int

这个严重反对[/quote] 不懂就算了，你是没接触过大点数据感觉不到。 索引碎片是什么你都不知道吧

[吉普赛的歌]

最失败的一点： 表的主键用了GUID， 这种ID是最慢的， 会迅速形成索引碎片， 而且毫无顺序可言。 建议改成： bigint 或者 int

[责任after自由]

应该是索引的问题，楼上说的对，尽量不要使用year(feetime) 这种写法，写多了就会要了你索引的命

[xiaoxiangqing]

这么多数据，除了提高电脑配置外，看能不能优化语句

[Ginnnnnnnn]

1 查询条件里面尽量不要用 year(feetime) 这种写法，按照你的条件应该用 feetime >= '2016-02-01' and feetime < '2016-03-01' 这种代替，year(feetime) 这种写法即使是有索引也不会走的。 2 feetime和 OrganizationId 这2个位置，如果有必要的话就建一个索引看下会是怎么样 3 用guid 做主键的话，主键就用非聚合索引，聚合索引用建在流水表的创建时间里面

[HyperWang]

贴一下实际执行计划，再进行分析比较好。

[道玄希言]

应该是索引没建好吧 我们公司的一个流水表,一个月将近10亿的数据, 统计时也不会要太长时间了.

[420jil]

多谢大家的帮助，我现在将in去掉了，用程序限制权限，时间用 feetime >= '2016-02-01' and feetime < '2016-03-01' ，且给feetime加了聚集索引，现在查询时间为2秒，这样正常吗？还需要怎么优化？再次感谢

[spiritofdragon]

从语句上只有group by CONVERT(varchar(7), FeeTime, 120) 这个地方还能想想办法，其他都只能从设计或者框架上了。 比如做个日期的赘余列 FeeDate，加索引。group by FeeDate