22,209
社区成员
发帖
与我相关
我的任务
分享话说性能问题，张嘴闭嘴都是分区，各位大哥大姐小弟小妹，都实实在在的测试过没
说到性能问题，张口分区，闭口分区，各位大哥大姐小弟小妹，都实实在在的测试过没
分区到底能提高多少性能？
你们的生产环境在什么情况下，数据量下分区了？
分区后，表中的数据与对应的物理文件时怎么存放的，索引时怎么建的？
维护时，是怎么备份的，管理的？
有生产环境下，实实在在用到分区的，并且证明分区确实提高了性能的没？？？
个人认为（也曾测试过），按照索引的B树存储结构，当数据量达到千万级时（亿级及更多没测试过），
也不过是5层，B树每涨一层结构，可以多存储3-4个数量级的数据吧
也就是说，按照聚集索引来查找的话，表中的数据不过亿，别想着用分区来提高查询性能，因为最多就是多了一次page页的读而已，靠着一次的逻辑读或者物理读来提高性能，咱也不在这里较劲
当然其他情况也很多，非聚集索引，包含索引，过滤索引，各种索引……，咱也不钻那个牛角尖，成不？
csdn曾经也遇到过类似观点，靠分区来提高性能，切……
估计人家是高手，一直在关注，我跟少见他回帖，估计没时间给人理论这些东西，
大家来说说吧，君子动手不动口，别拿理论来吓唬我。
咱就结合查询和分区，试试咋地个就提高性能了。
-
--
---
广告走远。
分区到底能提高多少性能？
你们的生产环境在什么情况下，数据量下分区了？
分区后，表中的数据与对应的物理文件时怎么存放的，索引时怎么建的？
维护时，是怎么备份的，管理的？
有生产环境下，实实在在用到分区的，并且证明分区确实提高了性能的没？？？
个人认为（也曾测试过），按照索引的B树存储结构，当数据量达到千万级时（亿级及更多没测试过），
也不过是5层，B树每涨一层结构，可以多存储3-4个数量级的数据吧
也就是说，按照聚集索引来查找的话，表中的数据不过亿，别想着用分区来提高查询性能，因为最多就是多了一次page页的读而已，靠着一次的逻辑读或者物理读来提高性能，咱也不在这里较劲
当然其他情况也很多，非聚集索引，包含索引，过滤索引，各种索引……，咱也不钻那个牛角尖，成不？
csdn曾经也遇到过类似观点，靠分区来提高性能，切……
估计人家是高手，一直在关注，我跟少见他回帖，估计没时间给人理论这些东西，
大家来说说吧，君子动手不动口，别拿理论来吓唬我。
咱就结合查询和分区，试试咋地个就提高性能了。
-
--
---
广告走远。
...全文
请发表友善的回复…
发表回复
大海008 2013-07-05
- 打赏
- 举报
帮我分析一下，这个数据减少这么多正常吗
haitao 2013-07-05
- 打赏
- 举报
有分区表 用到生产系统的兄弟吗？ 出来说说？？？
[/quote]
我在10、11楼都说了，并发查询效果很好
Mirror然 2013-07-05
- 打赏
- 举报
可以探讨 目前也在考虑分区这个问题
数据量大 上千万的数据 不考虑分区 有没其他方法提升效率
524929657雯 2013-07-05
- 打赏
- 举报
天-笑 2013-07-05
- 打赏
- 举报
有分区表 用到生产系统的兄弟吗？ 出来说说？？？
叶子 2013-07-05
- 打赏
- 举报
实践出真知!
haitao 2013-07-04
- 打赏
- 举报
我所理解的也是分区给维护带来的方便，性能上我暂时不大理解是如何提高的，想楼上所说的，我暂时还没有能够接触到类似的应用场景
我的目的不是怀疑分区所带来的性能上的提升
只要大家分区适应的场景来出来溜溜，我就打到目的了
[/quote]
分区表 和 维护 有什么关系？
难道我理解的分区表与你们的不同？
分区表就是系统在底层把一个大表分拆为多个小表
而应用（sql）仍然当它是一个大表
删除记录，也与没分区的大表 没区别啊，该写多少日志，应该也不会少吧[/quote]
一个1亿的表，删除1kw，对于非分区表，你几乎没法操作。[/quote]
我那个4亿记录的表，倒是没进行过一次性超过万行的删除
删除1kw条记录，主要的时间花在写日志上了吧？
所以衍生出很多 每次只删除1000条 的自动sql 的实现问题
分区表删1kw条记录很快吗？[/quote]
1000W的数据，你肯定没法一次delete，因为只要你操作，这是一个相当大的事务，直接就能把表干死。
你就得delete top (100)这样，产生大量的日志，并且相当相当的耗时。
假设一个场景，你有一个表是记录的一些数据，这些数据只保留1年，每月产生2000W数据，如果你不用分区表，当你要删除最开始那一个月数据时，这个操作就困难了，如果你有分区表，按月来分区，那么你可以直接把最早的分区switch到一个临时用的表，然后再把这个表删除即可。[/quote]
这种每月只删一次的，循环delete top (1000)也可以接受的：只要日志不大涨，时间慢点没关系[/quote]
ok，好好用。[/quote]
循环1万次：
begin
delete top (1000) where ...
这里需要怎么处理，才能保证这1千条的产生的事务日志不会被累积——有没有标准的做法？
end
之所以这样做而不是移删整个小表，是因为移除的标准 与 分区规则完全相同 不是正好[/quote]
你这样循环删除，循环1000次，第800次不成功呢？
还有时间上的浪费？这个你都不计算的？
还有分区表分区SWITCH和TRUNCATE可是日志很少的，你单表循环删除可是日志很大的，分区跟不分区差距很大的。
分区表的优势就来了。[/quote]
问题是分区的规则可能与历史的方向不一致
比如，按用户的类别进行了分区，就不能说过了一年可以直接删除哪个子表的了
按年份分区，才可以这样做
循环删除，是希望每个循环产生的日志（删1千行）能随即被下一个循环（删后面1千行）所覆盖，那就没那么可怕了
guanjm 2013-07-04
- 打赏
- 举报
我所理解的也是分区给维护带来的方便，性能上我暂时不大理解是如何提高的，想楼上所说的，我暂时还没有能够接触到类似的应用场景
我的目的不是怀疑分区所带来的性能上的提升
只要大家分区适应的场景来出来溜溜，我就打到目的了
[/quote]
分区表 和 维护 有什么关系？
难道我理解的分区表与你们的不同？
分区表就是系统在底层把一个大表分拆为多个小表
而应用（sql）仍然当它是一个大表
删除记录，也与没分区的大表 没区别啊，该写多少日志，应该也不会少吧[/quote]
一个1亿的表，删除1kw，对于非分区表，你几乎没法操作。[/quote]
我那个4亿记录的表，倒是没进行过一次性超过万行的删除
删除1kw条记录，主要的时间花在写日志上了吧？
所以衍生出很多 每次只删除1000条 的自动sql 的实现问题
分区表删1kw条记录很快吗？[/quote]
1000W的数据，你肯定没法一次delete，因为只要你操作，这是一个相当大的事务，直接就能把表干死。
你就得delete top (100)这样，产生大量的日志，并且相当相当的耗时。
假设一个场景，你有一个表是记录的一些数据，这些数据只保留1年，每月产生2000W数据，如果你不用分区表，当你要删除最开始那一个月数据时，这个操作就困难了，如果你有分区表，按月来分区，那么你可以直接把最早的分区switch到一个临时用的表，然后再把这个表删除即可。[/quote]
这种每月只删一次的，循环delete top (1000)也可以接受的：只要日志不大涨，时间慢点没关系[/quote]
ok，好好用。[/quote]
循环1万次：
begin
delete top (1000) where ...
这里需要怎么处理，才能保证这1千条的产生的事务日志不会被累积——有没有标准的做法？
end
之所以这样做而不是移删整个小表，是因为移除的标准 与 分区规则完全相同 不是正好[/quote]
你这样循环删除，循环1000次，第800次不成功呢？
还有时间上的浪费？这个你都不计算的？
还有分区表分区SWITCH和TRUNCATE可是日志很少的，你单表循环删除可是日志很大的，分区跟不分区差距很大的。
分区表的优势就来了。
铁歌 2013-06-22
- 打赏
- 举报
简单谈下互联网海量数据背景下的数据库性能优化策略：分库和分区
把订单、付款、仓库、等按业务打散部署在不同的DB SERVER，以增加系统吞吐能力，
然后，单个库如订单库上亿的表就按订单日期分区表，分区前后同样的查询，通过查询分析器
来看，开销cost是明显降低了，原因很简单，它已经不需要读取那魔多的data block就能够读取数据了，
因而I/O指标也有提升。。。总结起来，对于海量数据，分库和分区是绕不开的解决方案。。。
阳泉酒家小当家 2013-06-22
- 打赏
- 举报
之前也看过Oracle，Mysql中讲到分区表，都提到，通过分区表能提高查询性能，能提高可用性，能提高可管理性。
我觉得后两个还是很有意义的，比如可用性，比如一个分区的数据有坏块，那么只会影响到这个分区，其他的分区还是可以正常访问。
可管理性就是比如你的数据是每个月一个分区，如果你不需要了，直接删除这个分区就可以，就相当于truncate table一样，只不过这里是truncate 这个分区，速度非常快，另外，如果当表很大的时候，你会发现导入数据非常慢，但通过先导入到一个表，再把这个表加入到分区中，这样的速度非常快。
分区能提高查询性能，就像上面说的，通过分区确实能降低整个B+树的高度，少一层可以减少IO，但是如果你的查询一次要访问多个分区的数据，那么总体效率反而比不用分区表要更差。
所以，必须通过把不同的分区，放到不同的物理硬盘来实现并行IO，实现IO的负载均衡，也就是说你要访问整个表的数据，原来你就是全表扫描，只能访问一个硬盘，而现在通过把不同的分区放到不同的硬盘上，就能通过扫描多个分区，速度肯定提高很多。
说到底，要提高性能，有2种方法，一种就是尽量少做，比如通过索引来访问数据，而尽量少用全表扫描。
另一种就是用更多的资源同时来做，比如执行计划的并行性，并行IO等。
haitao 2013-06-21
- 打赏
- 举报
对，我的实际使用也证明了这一点
KevinLiu 2013-06-21
- 打赏
- 举报
我记得分区表在并行方面有很优势
haitao 2013-06-21
- 打赏
- 举报
我所理解的也是分区给维护带来的方便，性能上我暂时不大理解是如何提高的，想楼上所说的，我暂时还没有能够接触到类似的应用场景
我的目的不是怀疑分区所带来的性能上的提升
只要大家分区适应的场景来出来溜溜，我就打到目的了
[/quote]
分区表 和 维护 有什么关系？
难道我理解的分区表与你们的不同？
分区表就是系统在底层把一个大表分拆为多个小表
而应用（sql）仍然当它是一个大表
删除记录，也与没分区的大表 没区别啊，该写多少日志，应该也不会少吧[/quote]
一个1亿的表，删除1kw，对于非分区表，你几乎没法操作。[/quote]
我那个4亿记录的表，倒是没进行过一次性超过万行的删除
删除1kw条记录，主要的时间花在写日志上了吧？
所以衍生出很多 每次只删除1000条 的自动sql 的实现问题
分区表删1kw条记录很快吗？[/quote]
1000W的数据，你肯定没法一次delete，因为只要你操作，这是一个相当大的事务，直接就能把表干死。
你就得delete top (100)这样，产生大量的日志，并且相当相当的耗时。
假设一个场景，你有一个表是记录的一些数据，这些数据只保留1年，每月产生2000W数据，如果你不用分区表，当你要删除最开始那一个月数据时，这个操作就困难了，如果你有分区表，按月来分区，那么你可以直接把最早的分区switch到一个临时用的表，然后再把这个表删除即可。[/quote]
这种每月只删一次的，循环delete top (1000)也可以接受的：只要日志不大涨，时间慢点没关系
hgwyl 2013-06-21
- 打赏
- 举报
海爷……这个这个……
haitao 2013-06-21
- 打赏
- 举报
我所理解的也是分区给维护带来的方便，性能上我暂时不大理解是如何提高的，想楼上所说的，我暂时还没有能够接触到类似的应用场景
我的目的不是怀疑分区所带来的性能上的提升
只要大家分区适应的场景来出来溜溜，我就打到目的了
[/quote]
分区表 和 维护 有什么关系？
难道我理解的分区表与你们的不同？
分区表就是系统在底层把一个大表分拆为多个小表
而应用（sql）仍然当它是一个大表
删除记录，也与没分区的大表 没区别啊，该写多少日志，应该也不会少吧[/quote]
一个1亿的表，删除1kw，对于非分区表，你几乎没法操作。[/quote]
我那个4亿记录的表，倒是没进行过一次性超过万行的删除
删除1kw条记录，主要的时间花在写日志上了吧？
所以衍生出很多 每次只删除1000条 的自动sql 的实现问题
分区表删1kw条记录很快吗？[/quote]
1000W的数据，你肯定没法一次delete，因为只要你操作，这是一个相当大的事务，直接就能把表干死。
你就得delete top (100)这样，产生大量的日志，并且相当相当的耗时。
假设一个场景，你有一个表是记录的一些数据，这些数据只保留1年，每月产生2000W数据，如果你不用分区表，当你要删除最开始那一个月数据时，这个操作就困难了，如果你有分区表，按月来分区，那么你可以直接把最早的分区switch到一个临时用的表，然后再把这个表删除即可。[/quote]
这种每月只删一次的，循环delete top (1000)也可以接受的：只要日志不大涨，时间慢点没关系[/quote]
ok，好好用。[/quote]
循环1万次：
begin
delete top (1000) where ...
这里需要怎么处理，才能保证这1千条的产生的事务日志不会被累积——有没有标准的做法？
end
之所以这样做而不是移删整个小表，是因为移除的标准 与 分区规则完全相同 不是正好
nzperfect 2013-06-21
- 打赏
- 举报
我所理解的也是分区给维护带来的方便，性能上我暂时不大理解是如何提高的，想楼上所说的，我暂时还没有能够接触到类似的应用场景
我的目的不是怀疑分区所带来的性能上的提升
只要大家分区适应的场景来出来溜溜，我就打到目的了
[/quote]
分区表 和 维护 有什么关系？
难道我理解的分区表与你们的不同？
分区表就是系统在底层把一个大表分拆为多个小表
而应用（sql）仍然当它是一个大表
删除记录，也与没分区的大表 没区别啊，该写多少日志，应该也不会少吧[/quote]
一个1亿的表，删除1kw，对于非分区表，你几乎没法操作。[/quote]
我那个4亿记录的表，倒是没进行过一次性超过万行的删除
删除1kw条记录，主要的时间花在写日志上了吧？
所以衍生出很多 每次只删除1000条 的自动sql 的实现问题
分区表删1kw条记录很快吗？[/quote]
1000W的数据，你肯定没法一次delete，因为只要你操作，这是一个相当大的事务，直接就能把表干死。
你就得delete top (100)这样，产生大量的日志，并且相当相当的耗时。
假设一个场景，你有一个表是记录的一些数据，这些数据只保留1年，每月产生2000W数据，如果你不用分区表，当你要删除最开始那一个月数据时，这个操作就困难了，如果你有分区表，按月来分区，那么你可以直接把最早的分区switch到一个临时用的表，然后再把这个表删除即可。[/quote]
这种每月只删一次的，循环delete top (1000)也可以接受的：只要日志不大涨，时间慢点没关系[/quote]
ok，好好用。
王向飞 2013-06-20
- 打赏
- 举报
啥BUG
???
专注or全面 2013-06-20
- 打赏
- 举报
继续，就是需要一些争议，才能辨得出内在的东西
昵称被占用了 2013-06-20
- 打赏
- 举报
君子动手不动口，别拿理论来吓唬我。
u011146785 2013-06-20
- 打赏
- 举报
对于大数据量来讲，比较明显的优势是容易维护，另外对高并发下写速度会有一定的提升，不仅仅是为了提高查询性能，但从提高查询性能来讲，也不仅是靠的每条记录差几个page
加载更多回复（16）
