日期:2014-05-17  浏览次数:20521 次

sqlserver2008 分区表个数与性能的关系
如题:sqlserver2008 分区表个数与性能的关系

分区表个数的多少对插入性能有哪些影响?

另外为什么普通表的插入比分区表快(测试的结果)?

------解决方案--------------------
分区表的个数恐怕与插入性能并没有太大的关系.
分区表插入与普通表插入主要的区别在于它要检查一下数据主键在哪一个分区,然后插入到指定的分区文件中,这样可能会慢一点,但在检索性能上,会有质的飞跃.
因此,不要管插入,它不是系统速度的瓶颈.
------解决方案--------------------
另外为什么普通表的插入比分区表快(测试的结果)?

一般来说分区表是用的不同的文件组 从外面往不同的文件组插入数据是有可能比普通表慢得
------解决方案--------------------
引用:
有没有高手可以确认一下:
同样一个表有2个分区和有200个分区,插入的性能一样吗?
200个分区?不要随口乱说.
------解决方案--------------------
MYGOD!
为什么要200个分区啊~~~~~
哥们,你知道分区是干嘛的么?
一般,是把各分区文件放在不同的物理磁盘(还不是同一磁盘不同分区)上,这样,可以在存储一定范围数据时,在某个磁盘上操作,而存储另一些范围数据时,在另一个磁盘上操作,这样,可以减小磁盘I/O引起的系统延迟.
你分了200个区,你是不是把各个不同分区文件放在不同磁盘上了?如果不是,那分这样的区有何意义?
------解决方案--------------------
引用:
另外为什么普通表的插入比分区表快(测试的结果)?

一般来说分区表是用的不同的文件组 从外面往不同的文件组插入数据是有可能比普通表慢得


+ 分区表,插入主要正对不同的文件组。(如果分了的话)

写入的时候判断多了一层,但是查询肯定是优化的。
------解决方案--------------------
可以建作业,通过作业每天更改分区函数和分区方案,每天合并一个,新建一个.
但是,由于创建分区相当于创建新的主索引,会消耗很大的系统资源,而且如果修改分区的时候系统花较多的时候,可能会引起查询的问题.

不过,如果不是每天会有数百万(至少数十万数据新添加进来,一般不会天天修改分区的,你这样的方案不可行.
------解决方案--------------------
兄弟,刚才不是说了么,分区的主要目的是减小查询时的系统开支,不般不考虑插入的.很少像你这样把表弄得这么支离破碎的.
建议你先好好钻研一下关于分区表的一些基本知识,再决定怎么干.
------解决方案--------------------
既然是一定要重建分区,那可以考虑用三个分区,交换今天的,前天及以前,昨天,今天.在调用作业的时候,先把今天的合并到昨天去,这样数据量少一些,并新建新一天的分区,然后在系统工作空闲时,再把原来在昨天分区上的,即已经成为前天的数据,合并到前天以前分区去.这样做,切换时重建分区索引的时间可能会少一些.
------解决方案--------------------
引用:
没乱说,当前分区其实是500个
一般分区为几个就足够了,你如果有能力做500个分区的话,就不会到这里来问这种问题了.
------解决方案--------------------
引用:
兄弟,我很清楚分区是为了加快查询,方便管理。但是对于一个每天百万的数据插入,你有什么更好的办法?
如果不把昨天的数据交换到历史表中,实时表就会非常大,这样即使是普通表插入速度也快不到哪里去。
然而你想交换到历史表,除了分区表还有更快的方法吗?
由于分区交换的限制问题,如果不把实时表也做成分区表,那么如何实现快速切换数据?
目前用普通表的话,切换的时候必须停程序(停业务2分钟左右),如果不……


好吧,看了你的需求,我承认一块磁盘做分区表对你来讲,也有意义。
你可以尽可能的把当前数据放到新分区中,根据你的需求,可以一月/一周/甚至一天/一个分区。
只有一块磁盘的话,改为分区表后,相对于普通表,在索引、锁维护方面会减少从而提升性能,但仍会局限于一块磁盘的io读写速度,如果条件允许再加一块磁盘把过往数据交换到该磁盘,那么性能提升才能更明显。
如果你的io很忙,总是有io队列等待,那么无论是不是分区表,性能都差不多了。