推 iamnotfat: 用戶行為結束後, 為何還要select 給他? 這個overhead 01/16 10:44
→ iamnotfat: 有點危險~ 01/16 10:44
→ gname: 原po指的SELECT 應該是 UPDATE 完後使用者要看新的資料 01/16 13:23
→ gname: 給原po: 你的系統可以同時間承載10萬人連上來用嗎? 01/16 13:25
→ gname: 如果不行,那你何必去考量這個情況? 01/16 13:26
→ konkonchou: 效能是個問題，deadlock也得考慮，AP加個排queue功能 01/16 15:36
→ konkonchou: 或許犧牲一點點即時性但整體穩定會比較好一些 01/16 15:36
推 wen001: 你的update與select可否再描述一下。例如是否update同一 01/17 21:51
→ wen001: 筆row,還是有其他where條件值。 01/17 21:51
我有一個總表 去記錄每個client對於某項任務的值
有一個任務條件表 去記錄每個任務 達成的條件
例如 吃有一個任務是吃50碗飯
使用者吃完時
我會先去 更新總表內對於此任務的值 maybe 是 49
更新完後 我會去條件表抓此任務 完成的條件 在這個情況是50
若49 = 50 我就會通知使用者完成了
所以update的確是有where條件，條件是某個clientSn和任務Sn
select也是有where值的
而以上所說的是 指是對於單一使用者而言
而我們公司 伺服器的數量 的確可以乘載10萬人以上 這是沒問題的
只是 因為要達到 任務完成 就要馬上通知使用者 該任務完成
我覺得這樣會對總表有大量的update 以及對任務條件表 大量的select
是有想過用index的方式 或者將總表拆成小表
不過還是想問問有沒有更好的方式
※ 編輯: keke0421 (36.230.134.221), 01/17/2015 23:43:50
推 wen001: 你有client sn與任務sn 所以就不會存在同一筆row update 01/18 00:14
→ wen001: 問題，lock問題沒有程式干預就還好。你的問題在於可能會在 01/18 00:14
→ wen001: 單一table的select產生大IO。 01/18 00:14
推 wen001: 能盡量拆分table就儘量拆，wher 01/18 00:19
→ wen001: e條件要考慮index,同一語句下若where條件太多先用子查詢縮 01/18 00:19
→ wen001: 小範圍，記得同一sql語句 子查詢會先載入在記憶體。 01/18 00:19
推 wen001: partition概念有點像是用月份拆分不同減少IO。建議用程式 01/18 00:23
→ wen001: 解決，開發階段先別考慮partition。 01/18 00:23
推 wen001: 加油，硬體上大陸有用一台AIX+夠強的Storage撐整個中國的 01/18 00:33
→ wen001: 春運，沒理由臺灣不行。 01/18 00:33
推 wen001: 你說的index是必須存在的，但是index也是一個table,假設Ro 01/18 00:45
→ wen001: w過多也是要把Table用陳舊資料的方式區分，最簡單是用日 01/18 00:45
→ wen001: 期月份年份區分。 01/18 00:45
推 wen001: 看起你的問題瓶頸會在selectIO 01/18 00:55
→ gname: 從你的敘述看起來任務條件表是拿來讀的? 那何不進 cache ? 01/23 11:00