分区表或分表能否解决大并发量读写的问题?
我们公司目前全国有效的门店大概是1500家左右.
服务器为一台IBM,双CPU,32G内存(由两台单CPU,16G内存IBM服务器合并),业务服务器有3台.
数据库为MS SQL2005,核心业务表半年数据量在12W左右,闲时每天的业务量(仅指核心业务)在3000笔左右,忙时可翻倍达6000笔.每日活动门店在500家左右,但在节假日可能达到1000家.
系统前端采用C#.NET编写,前端操作业务单据就是删除再插入,而几乎所有业务逻辑都在数据库中执行,后端数据库中业务逻辑复杂.
五一时曾出现数据库服务器资源耗尽(当时是两台16G内存单CPU的集群环境),CPU资源占满,数据库出现大量锁,尤其是核心业务相差的表,业务无法进行,当时采取分区域限时操作才缓解此情况.当时前端业务服务器运行正常.

我们关注到当数据库连接数达到400以上时,数据库服务器就会出现资源耗尽的情况.
现在为了解决并发量较大的问题,考虑采用分区表,或将核心业务表分表来解决大并发量的问题,但不知道采用分区或分表是否真能提升并发能力,不知道这个方案的方向是否正确,请有经验的大牛们指教.



------解决方案--------------------
http://wenku.baidu.com/view/df7f92ce05087632311212cc.html

楼主可以参考一下这个资料，希望问题可以尽快解决
------解决方案--------------------
都有作用，分表作用效果更好
------解决方案--------------------
分区或分表对你说的问题有好处，但是需要注意分区或分表后不同的核心业务的分表存储最好放到不同的硬盘上，这样可以有效地利用多CPU和多硬盘的IO优势。分区表的划分也需要多多考虑下，尽量做到数据的平均分配效率最高。
------解决方案--------------------

探讨

我们公司目前全国有效的门店大概是1500家左右.
服务器为一台IBM,双CPU,32G内存(由两台单CPU,16G内存IBM服务器合并),业务服务器有3台.
数据库为MS SQL2005,核心业务表半年数据量在12W左右,闲时每天的业务量(仅指核心业务)在3000笔左右,忙时可翻倍达6000笔.每日活动门店在500家左右,但在节假日可能达到1000家.
系统前端采用C#.NET编写,前端操作……

------解决方案--------------------
表分区并分布在不同磁盘上，需要对RAID、文件组、文件作良好设计
资源耗尽跟是否分区无关，若IO分布不均，最多导致磁盘读写慢、阻塞等情况
有偿支持