一张表1.19亿笔数据，是不是要崩了的节奏？

select COUNT(*) from  ICStockBill

select COUNT(*) from  ICStockBillEntry

select COUNT(*) from  t_ICItem

select COUNT(*) from  t_item

K3出入库主表数据540万，明细表1.19亿，物料视图9.5万，物料源表17万，表不能删，不能减。

跑了三年多了，数据量每个月都在蹭蹭往上涨，帐套大小120G目指。

这样下去是不是要崩了的节奏？还有救吗？

现在K3成本核算、凭证维护、职员维护要瘫痪了。
------解决方案--------------------
你的数据不能归档。那就不好办了。如果能归档一些历史数据的话。。。。
------解决方案--------------------
可以考虑用分区表,对前端程序没有影响.
------解决方案--------------------
我认为  你首先要把ICStockBill ?ICStockBillEntry 这2个表的SQL语句 最耗时的TOP 10找出来，   
然后再看看这些SQL语句有没有问题  （你已经改不了语句了  除非是存储过程里）   看看能不能动索引（我估计可能性很小）

比较靠谱的办法是提高硬件性能    存储换成PCI-E接口的SSD  怕丢数据组个RAID   加大内存  

最后的方案是换软件  


------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

数据库文件放存储上，也可以使用分区表方法吗？

是的,可以设多个数据库文件组,把分区表的各分区放在不同的文件组里,有利于分担IO.

如果磁盘只有1个IO通道  这个有效果？     如果文件放到不同的磁盘里    这个IO能力提高有多少呢？

除非做测试，不然没有准确数据，这里说的分担IO是只多个物理磁盘下，可以把不同的分区文件组放到不同的磁盘，这样可以并行读取多个磁盘，而不用把所有I/O请求集中在一个物理磁盘上

想来想去，我觉得性能问题可能出在[存储]上了。
这个存储由十几块6Gb SAS 15k 600G硬盘组成，分了多个LUNs，几家公用，三路6Gbps光纤连接，挂了不少虚拟机。
数据库服务器也是虚拟机，早知道有性能瓶颈，数据库就干脆装实体机上了。

那就赶紧买一台好一点的服务器吧，肯定比金蝶的要价要低对了。

我原来公司的，就dell的普通服务器，大表现在估计得有超过2亿条，也没奔溃过。所以买个好一点的服务器，多点内存，性能就上去了。

如果再建点索引，那速度肯定更快，如果再用分区表，把数据进行归档，那就更好了。
------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

数据库文件放存储上，也可以使用分区表方法吗？

是的,可以设多个数据库文件组,把分区表的各分区放在不同的文件组里,有利于分担IO.

如果磁盘只有1个IO通道  这个有效果？     如果文件放到不同的磁盘里    这个IO能力提高有多少呢？

除非做测试，不然没有准确数据，这里说的分担IO是只多个物理磁盘下，可以把不同的分区文件组放到不同的磁盘，这样可以并行读取多个磁盘，而不用把所有I/O请求集中在一个物理磁盘上

想来想去，我觉得性能问题可能出在[存储]上了。
这个存储由十几块6Gb SAS 15k 600G硬盘组成，分了多个LUNs，几家公用，三路6Gbps光纤连接，挂了不少虚拟机。
数据库服务器也是虚拟机，早知道有性能瓶颈，数据库就干脆装实体机上了。

早知道就不要放那么多公用的
------解决方案--------------------
说句实在话，个人认为K3写的很烂（数据库处理这部分），随便起账套，随便复制N次。
再大的硬盘也是要崩的节奏。

------解决方案--------------------
硬件要跟上才行，这么大的数据量，要从多方面调整
------解决方案--------------------

引用:

可以考虑用分区表,对前端程序没有影响.

的确，分区表很好

我的一个应用，最大的表已经8.5亿，分100个区表
打算5-10年内到20亿再改造
------解决方案--------------------
若方便申请预算，乐意提供支持、优化、咨询。。120G的数据库在这几天不算大数据了，十多年前算是
略看了KD、UF结构与DB代码，设计注重功能完成，至于效率，无非是一味地让客户买高端机器（这样也好，大伙儿都有钱赚）
未看SAP的DB代码，不便评论。不过也都是买高级硬件