各位大大好
最近設計資料庫時遇到一些問題 想請問前輩
假設一個網站上面有50個功能，每個功能結束時會call一個api去update
一張資料表的欄位 及 select 動作。
若同時間約有10萬人使用這50個功能，而且不用批次寫入資料庫的方式，
有比較好的設計方式？
我的想法是，將這一張資料表，在依功能拆成5~10張小表，
分散資料表被request的數量。
網路上有找到Partition Table的資訊，但無奈看不是很懂，
想請各位前輩有沒有好的方式，關鍵字也可以ＱＱ

用戶行為結束後, 為何還要select 給他? 這個overhead有點危險~

原po指的SELECT 應該是 UPDATE 完後使用者要看新的資料給原po: 你的系統可以同時間承載10萬人連上來用嗎?如果不行,那你何必去考量這個情況?

效能是個問題，deadlock也得考慮，AP加個排queue功能或許犧牲一點點即時性但整體穩定會比較好一些

你的update與select可否再描述一下。例如是否update同一筆row,還是有其他where條件值。你有client sn與任務sn 所以就不會存在同一筆row update問題，lock問題沒有程式干預就還好。你的問題在於可能會在單一table的select產生大IO。能盡量拆分table就儘量拆，where條件要考慮index,同一語句下若where條件太多先用子查詢縮小範圍，記得同一sql語句 子查詢會先載入在記憶體。partition概念有點像是用月份拆分不同減少IO。建議用程式解決，開發階段先別考慮partition。加油，硬體上大陸有用一台AIX+夠強的Storage撐整個中國的春運，沒理由臺灣不行。你說的index是必須存在的，但是index也是一個table,假設Row過多也是要把Table用陳舊資料的方式區分，最簡單是用日期月份年份區分。看起你的問題瓶頸會在selectIO

從你的敘述看起來任務條件表是拿來讀的? 那何不進 cache ?