作者stevekevin10 (hippo泡)
看板Soft_Job
标题Re: [请益] 资料库join後count速度问题
时间Sun May 8 22:23:27 2016
※ 引述《stevekevin10 (hippo泡)》之铭言：
: 抱歉又来请益个资料库问题m_ _m
: 需要join 500万 跟 3万笔的表格
: 根据筛选条件後再根据後者的栏位做count
: 但现在下完query後都会卡住
: 请问该如何是好
抱歉我补上query QQ
select c.`CHROM`,d.`GeneId`,count(distinct c.`primaryKey`) from `variation`
as c join `table 8` as d
on c.`CHROM` = d.`CHROM` and c.`POS` > d.`5US` and c.`POS` < d.`3UE` Group
by d.`GeneId`
其中variation表格大概快五百万笔 table 8 大概三万
然後variation表格有一个pos栏位是一个数字
在table8里面有两个栏位 5US 3UE组成一个数字区间 然後两张表各有一个`CHROM`栏位
但table 8里面还有一个geneId栏位
主要是想找出variation每一笔各属於哪一个geneId 并做一个统计
但目前此QUERY跑下去.......SQL SERVER就没回应卡死了T____T
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.230.218.125
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1462717410.A.650.html
1F：→ gn01838335: 恶你直接在join做运算式喔 05/08 23:07
2F：嘘 yourinfo: 加一个c.`CHROM`=xxx，先测看看你的index有没有用吧!? 05/08 23:32
3F：→ yourinfo: 我是觉得不会卡死，应该是其他问题比较大 05/08 23:40
4F：→ alan3100: 用loop join试看看 你需要学会看execution plan 05/09 00:25
5F：→ yyc1217: distinct去掉试试看~ 05/09 01:13
6F：→ yyc1217: 也可以先一个单纯的select 再把其他部份逐步加上去 05/09 01:14
7F：→ yyc1217: 直到发生卡死 就知道是哪个部份造成的了 05/09 01:15
8F：→ ihon822: 把join的部份做成view 再用view去做筛选和group 05/09 02:12
9F：推 kiwatami: 那 index 是哪些栏位? explain SQL 的结果是什麽? 05/09 08:20
10F：→ kiwatami: 是 1:1 还是 1:n ? 范围数值很多有没有分割 table? 05/09 08:20
11F：→ abola921: CHROM栏位的资料型态是什麽？因为500w x 3w 其实是小事 05/09 09:20
12F：推 tomken: 怎麽卡死法？应该有在跑 只是要等 05/09 10:55
13F：→ tomken: 之前下join查询等过ㄧ天都有 05/09 10:55
14F：→ AminLA: 就这个 query 来说, C表需要 POS + CHROM 的索引 05/09 13:33
15F：→ AminLA: 具体要看 CHROM 与 POS 的资料差异性大不大 05/09 13:34
16F：→ AminLA: CHROM 没什麽差异性的话就建 POS 05/09 13:34
17F：→ AminLA: d 表的话则是需要 5US+3UE + CHROM 05/09 13:35
18F：→ AminLA: 假设你索引建对了(建多字段的索引 别分开建) 05/09 13:36
19F：→ AminLA: 有可能是你2张表 join 字段类型不一致, 导致索引没有正确 05/09 13:37
20F：→ AminLA: 用了索引不一定会比较快, 具体要看资料怎麽分布的 05/09 13:39
21F：→ AminLA: 查询的范围, 所以上一篇有人让你用 hash join 试试 05/09 13:39
22F：推 lionpierrot: 看来应该不会卡 可是chrom不用加到group by的栏位吗 05/09 21:28
23F：推 lionpierrot: 不然上面有人提过的 join部分先建成view 05/09 21:55
24F：→ yourinfo: 正常来说建view只是好看，对效能没什麽帮助 05/09 23:34
25F：推 littlethe: 同意楼上,view试过,对效能没有用 05/10 01:08
27F：→ AminLA: indexed view 跟一般的view 是不一样的，增速的地方在於 05/10 11:20
28F：→ AminLA: 相对於原表额外的clustered index 05/10 11:20
29F：→ AminLA: 并不是view 05/10 11:20
30F：→ yourinfo: 问题是你们说view，我也只说view没用-.- 05/12 00:00
31F：→ yourinfo: 不过原po还是要学着找出慢的原因，这是基本功 05/12 00:03