各位大大好
最近设计数据库时遇到一些问题 想请问前辈
假设一个网站上面有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 ?