snoopy11hk

我都講左, 我果句係有 performance issue 既.  係唔理 performance 寫出黎.
同你果句都係, 做到答案, 唔 ...
Super169 發表於 2016-4-1 00:41

    以下只係個人經驗:
唔太喜愛 exists (id>id) 呢個 pattern, 唔太直觀

就算
SELECT
FROM (SELECT *, ROW_NUMBER().....  FROM .....)
WHERE row_num = 1
呢個都其實係 oracle 好常見的 pattern
asktom 好, stackoverflow 好, 都好常見呢個答案

Super169

以下只係個人經驗:
唔太喜愛 exists (id>id) 呢個 pattern, 唔太直觀

就算
SELECT
FROM (SELECT * ...
snoopy11hk 發表於 2016-4-1 00:48

問題在於行到同好唔好既分別.  之前講過, 交功課既 OK, 無問題的.

我想知 Oracle 接唔接受我 #38 果句 (改番用 rowid):

SELECT recnum, input_date, account_no, product_cd, agent
  FROM <table>
WHERE rowid IN (SELECT min(rowid)
                    FROM <table>
                                   GROUP BY account_no
                                 )
   
呢句係原本 GROUP 果句拆成 sub-query 既寫法.  等同於我 group by having rowid  = min(rowid)
不過, GROUP BY 果下, 無 SELECT account_no, 唔知 Oracle 受唔受.

snoopy11hk

1/2: 夠資料就做到, 唔夠就要答做唔到.  唔好意思, 好難接在不確定情況下, 是旦比一條人都叫答案.
      ...
Super169 發表於 2016-4-1 00:45

    1,2/: Oracle 自己有 mechanism, 果 D 唔深入探討
我自己個 fault tolerance 就係真係好 exceptional 的錯都無計
generally 99.9999999% 無事就 ok

3/ 呢個 Practice 基本上係 best practice..
所以我唔會再點 tune

4/ :你個思維係 procedural, 我的係 set operation, 無咩野好比較

snoopy11hk

問題在於行到同好唔好既分別.  之前講過, 交功課既 OK, 無問題的.

我想知 Oracle 接唔接受我 #38 果句  ...
Super169 發表於 2016-4-1 00:56

呢句照睇 oracle 係compile 到 run 到
如果你想以 performance 講的話, 呢個就正正最好代表
一個 SELECT... FROM WHERE ROWID , 即係一個 row id access
之後一個 inlist  的 select, 即係第二個 table scan

即係 total 1.5-2 table scan

而我的 solution 就係一個 table scan + 一個 window sorting

其實真係好睇個人喜好
但我個人就覺得用 window sorting 好直觀, 唔洗諗太多野

但同一樣的道理, oracle 都可以 insert 錯 sequence
所以要解決呢個問題, 一係改 DB setting, 一係改 table schema
呢個唔係 programmer/software developer 要解決的 level.

Super169

1,2/: Oracle 自己有 mechanism, 果 D 唔深入探討
我自己個 fault tolerance 就係真係好 exceptiona ...
snoopy11hk 發表於 2016-4-1 00:57

你果個唔係乜野 exceptional 既錯, 係亂咁將 D 野比人.  
連會比邊條 row 出黎自己都唔肯定, 咁都叫 99.99999999% 無事?  你真係咁好彩?

行唔到既好易知, program 未出街就應該執走左.  但係 performance issue 往往係用左一排至會出現, 好多人都忽略, 但唔代表就係好既.    可能我對慣既 table 都係好大 volume, 有錯既 SQL 試兩試就睇得出, 基本上睇 SQL 只係睇 performance.

或者只可以咁講, 真係你好好彩, 可以唔去諗 performance.  
但係, 我相信你將來總有一天, 要學下對 performance 負責任的.

Super169

回覆 54# snoopy11hk


無錯, 我果句會 scan 兩次, 如果一句 group 做到, 睇 optimzer 係有可能一次 scan 就得, 可惜 Oracle 唔受.
只好拆開先搵 min (掃一次), 再搵番 D row 出黎(掃一次), 結果要掃兩次.  
因為假設無 index, 每一次都要掃哂至知, 所以要掃兩次.

但係同 sort 比, sort 肯定無可能快過一次 table scan, 而且係慢好多.
我諗你讀書點都有寫過 sorting 既 program 掛, sorting 同 搵 min 既分別有幾大, 你真係唔知?  係既話真係無野好講了.

做唔到同唔去做係兩回事, programmer 除左要寫個 work 既 program 出黎, 亦都有負責任寫好佢.
performance tuning 係其中一個好重要既環節, 亦係 programmer 應該要識既.
呢樣野唔可以話個人喜好, 對成個 system 影響可大可小.....除非只係做下功課, 有問題都只係影響自已既成績.

至於你講到話 oracle 都可以 insert 錯 sequence, 好似有點過火了.
如果我之前講既野有得罪之處, 請多多包涵.  希望大家理性點.

Super169

唔好意思, 唔知 ching 可唔可以幫忙試多樣.

之前話呢句 xyz 無用 aggregate function 包住唔得, 我都明白既, 因為 group 既結果唔可以出現 duplicate row under 個 group.

1. SELECT rowid, account_no, x, y, z
   
2. GROUP BY acount_no
   
3. HAVING rowid = min(rowid)

複製代碼

咁如果用個 min 去包住佢地, 又得唔得呢?

1. SELECT rowid, account_no, min(x), min(y), min(z)
   
2. GROUP BY acount_no
   
3. HAVING rowid = min(rowid)

複製代碼

我唔係話呢句好, 因為多左個多餘既 min, 睇 code 會亂.  而且又無端端 call 多層.
我只係想知道下 Oracle 食唔食呢個 syntax, 因為相對 sub-query 果個, 呢度有機會快 D.
而且 optimizer 有可能做到scam table 一次, 再 dummy scan result set 一次就得.

snoopy11hk

回覆  snoopy11hk


無錯, 我果句會 scan 兩次, 如果一句 group 做到, 睇 optimzer 係有可能一次 scan 就 ...
Super169 發表於 2016-4-1 01:30

1/ window sort 同 sort 有分別

2/  1.5-2 個 table scan 快定 1 個 table scan + window sort 快, 其實係 case by case 仲要好 marginal
, 不值一提


3/    無過左火, non deterministic 的意思就係咁簡單
你就算 select 出黎唔同時間都可以唔同 order
只不過你好少時間會見到真係唔同咁解

要講到好 detail 我就真係唔想講, 係呢個 post 都唔需要, 所以我唔想搞到太 complicated 要講呢 D
最簡單, 你落個 Primary Key 落去, 佢成個 natural sorting 都會變哂

落 index 好似又會

Super169

1/ window sort 同 sort 有分別

2/  1.5-2 個 table scan 快定 1 個 table scan + window sort 快, 其實 ...
snoopy11hk 發表於 2016-4-1 01:58

呢度有樣野我講錯左, 要更正番.  
我果句 SQL, 應該唔係 2 次.  可以係好多次, 又可以係好快.
原因:
兩次只係講 main table, 但係佢仲要去搵 result set 對, 如果第一下出既 result set 好大 (完全無得 group), 就會變左 每條做一次 search, search 結果係 1+2+3+4.... 即係 n 條 row 就對 n(n+1)/2 次.
但又有可能好快既原因, 係要睇 Oracle 既設計.  一般 rowid 都係 index 左既, 正路 SQL server 如對 where 既 field 係 index 左, 佢會由 result set 搵番轉頭.  就變成係 scan result set 再 index search main table.

唔好下下 case by case 就算, 係咁簡單, 就唔駛日做 tuning 喇.
可能我會令你煩左 D, performance 既野, 同樓主既要求無關.
不過, 習慣左成日要 tune 野, 睇 SQL 第一時間係睇會唔會慢左, 無 index 既 table 比較少玩, 樓主既 case 就當成係咁去諗.

snoopy11hk

呢度有樣野我講錯左, 要更正番.  
我果句 SQL, 應該唔係 2 次.  可以係好多次, 又可以係好快.
原因:
兩次 ...
Super169 發表於 2016-4-1 02:14

基本上有 D 題型的問題, 用 pattern/cookbook  就 ok , 唔洗特別去諗 tuning
唔係最快都會係快

倒不如留番時間, 有時 D complex 的 query 連 optimizer 都搞唔掂先出手啦
果 D就真係好哂時間 同心機