.随着normalization1,2,3级的进行,table 之间的join在一般的OLTP系统中是很常见的也是很难避免的.不能说"没事别join". 在OLAP中由于要进行大量的summarization,我们才做denormalization以减少join 数.
query需时的多少并不一定和table的大小成正比.它往往取决于
(1)record的长度. record越长,需要search的data page就越多,相应的时间也就越长;
(2) join时有没有specify join的条件.象本例中的两个table join,如果忘了写join的条件,实际进行的将是cross join ,此时search的record 数是两个table cross join的结果 -- 十几万乘以几千 = 上亿 ---
(3) 有没有对join的colomn作index,如果没有,此时的join属hash join,速度也会受很大影响.
(4)作query时有没有其他的transaction在进行,从而导致query被block.打开sql profile,看一下实际情况.
(5)从hardware上讲,memory够不够,看看performance monitor中的cache hit ratio是不是远远低于90%
(6)database file 放在HARD DRIVE 的什么RAID ARRAY上,不同的RAID Level SEEK SPEED不一样,query的performance 也会受到影响.
总之 系统不同,即使很小的database差别也会很大,在没有具体分析前,还是不应该匆忙就下结论.
以上意见,仅供参考.
query需时的多少并不一定和table的大小成正比.它往往取决于
(1)record的长度. record越长,需要search的data page就越多,相应的时间也就越长;
(2) join时有没有specify join的条件.象本例中的两个table join,如果忘了写join的条件,实际进行的将是cross join ,此时search的record 数是两个table cross join的结果 -- 十几万乘以几千 = 上亿 ---
(3) 有没有对join的colomn作index,如果没有,此时的join属hash join,速度也会受很大影响.
(4)作query时有没有其他的transaction在进行,从而导致query被block.打开sql profile,看一下实际情况.
(5)从hardware上讲,memory够不够,看看performance monitor中的cache hit ratio是不是远远低于90%
(6)database file 放在HARD DRIVE 的什么RAID ARRAY上,不同的RAID Level SEEK SPEED不一样,query的performance 也会受到影响.
总之 系统不同,即使很小的database差别也会很大,在没有具体分析前,还是不应该匆忙就下结论.
以上意见,仅供参考.