定时分区和动态分区,那个方案比较好
定时分区:定时进行分区,比如一月一个分区
动态分区:根据数据量来动态分区,比如每天执行job检查分区里的数据量,如果超过100w则分区,否则不分区
第一种分区每个分区的数据量差别会很大,因为业务是不断增长的
第二种分区每个分区的数据量差不多,但分区时间会越来越短,因为是定时检查的
请问,大家认为哪种分区比较好,各自的优缺点和适用情况
------解决方案--------------------无论哪种方式,保证你的分区策略可控就可以。
如果是定时分区,需要根据数据量变更情况定期调整分区间隔时间
如果是自动分区,需要定期检查分区数量和相关操作执行时间是否在预期范围内,发现问题不对及时修正。
------解决方案--------------------
其实一般建立分区,最大的好处是,对数据的管理,以及历史数据的归档,比较方便,也就是主要在于管理上。
而对性能,针对不同情况,可能会有所提升,可能反而会有下降,不一定的。
不过一般,从单个分区取是快的,而从多个快取,是慢的。
------解决方案--------------------另外,建了分区,还得相应的建索引,分区只是把数据分开存储,当然逻辑上还是一个表,
比如,你只需要访问一个分区,执行计划是表扫描,而原来没分区,是对整个表进行表扫描,那么性能就能提升。
但是,如果需呀扫描多个分区,那么性能就会下降,因为得扫描多个分区后,还得union all合并数据
------解决方案--------------------没见过这种说法,不过你这两种分区策略本质上貌似不是一回事
------解决方案--------------------动态分区有个不好的地方,当刚好你在用的时候,包括update、delete、insert,但是刚好达到100W,那么就触发分区。不过这个倒好处理。另外分区有其特性,如果分区不对齐、数据查询跨区太多,那么性能很难有保证,分区主要还是为了减少访问的范围。如果不能从中获取主要利益,那么不分区可能会更好
------解决方案--------------------另外一般要3000万以上的数据才建议分区,如果用高版本的sqlserver,这个数字还要增加
------解决方案--------------------
不完全一样,如果你的表时分区表,那么索引就分为,分区索引 和 全局索引。
所谓分区索引,就是比如你按xx字段来做分区表,然后建立索引时,指定分区架构,那么这个索引就是分区索引,特点是,每个分区都会有一个索引,如果你有10个分区,那么就会有10个分区索引。
而全局索引,是针对整个表的所有数据的索引,比如xx是分区字段,但是还有其他的查询条件,比如yy字段,那么你建立yy字段建立索引,那么这个就是全局索引,只有一个。
------解决方案--------------------
我发现,这归结出来就一个问题,那就是我一次的查询数据是从多个分区中取快,还是从单个分区中取快
如果是从多个分区中取快,则应该采用动态分区
如果是从单个分区中取快,则应该采用定时分区
不知道这样理解对不对
没见过这种说法,不过你这两种分区策略本质上貌似不是一回事
所以问问大家,看大家有没考虑过或遇到过这样的情况
不建议用动态分区,这个不好管理,因为分区本身最大的优点就是可管理性,而你引入动态分区,你还得不断扫描数据,然后来判断这个数据归入哪个分区,这个很累的呢。
我觉得,如果你实战想要平均分配,那么还不如考虑增加一个代理键,自增列,然后通过范围分区,规定,比如:
1-100w 分区1
...
这么分区,就行,没必要采用动态分区。
------解决方案--------------------分区的数量和版本有关系,别太容易就达到上限
------解决方案--------------------
我发现,这归结出来就一个问题,那就是我一次的查询数据是从多个分区中取快,还是从单个分区中取快
如果是从多个分区中取快,则应该采用动态分区
如果是从单个分区中取快,则应该采用定时分区
不知道这样理解对不对
没见过这种说法,不过你这两种分区策略本质上貌似不是一回事
所以问问大家,看大家有没考虑过或遇到过这样的情况
不建议用动态分区,这个不好管理,因为分区本身最大的优点就是可管理性,而你引入动态分区,你还得不断扫描数据,然后来判断这个数据归入哪个分区,这个