作者查詢 / AminLA
作者 AminLA 在 PTT 全部看板的留言(推文), 共293則
限定看板：全部
看板排序：
12F推: 應該說chuck 一開始不知道要去做什麼，只知道是要去axe那05/08 23:25
13F→: 是到了以後 Wendy 要把棍子折斷，chuck 才尿遁想害axe，05/08 23:29
14F→: 最後還是決定先救Wendy再說05/08 23:29
119F推: 推百萬朵玫瑰，小區音樂隊長也有唱過04/16 19:40
150F推: 可能是在說 男主角把女主角認定為人生的key，而前女友覺03/18 17:54
151F→: 得你不夠重視她03/18 17:54
16F→: 只01/13 16:53
17F→: 只要你不動IL裡的人 肯定可以過，因為我今天IL裡有 THJ 401/13 16:59
18F→: 點交易完成 人員交換順利完成01/13 16:59
17F→: 這用countdownlatch 可以實現，但要記得處理好time out與02/04 17:15
18F→: 異常02/04 17:15
9F→: 可以在update 時指定當初取得的序號例如 set seq=150 whe10/07 21:23
10F→: re seq=1 取得受影響的筆數就知道有沒有成功，沒成功的話10/07 21:23
11F→: 就再次取得最新的序號 ，算出差值，下個update 幫原本已10/07 21:23
12F→: 經寫入的149 筆更新成新的序號，再下個update 更新當前的10/07 21:23
13F→: seq 反複這個過程直到成功 簡單說就是 CAS10/07 21:23
14F→: 就這個 query 來說, C表需要 POS + CHROM 的索引05/09 13:33
15F→: 具體要看 CHROM 與 POS 的資料差異性大不大05/09 13:34
16F→: CHROM 沒什麼差異性的話就建 POS05/09 13:34
17F→: d 表的話則是需要 5US+3UE + CHROM05/09 13:35
18F→: 假設你索引建對了(建多字段的索引 別分開建)05/09 13:36
19F→: 有可能是你2張表 join 字段類型不一致, 導致索引沒有正確05/09 13:37
20F→: 用了索引不一定會比較快, 具體要看資料怎麼分佈的05/09 13:39
21F→: 查詢的範圍, 所以上一篇有人讓你用 hash join 試試05/09 13:39
27F→: indexed view 跟一般的view 是不一樣的，增速的地方在於05/10 11:20
28F→: 相對於原表額外的clustered index05/10 11:20
29F→: 並不是view05/10 11:20