早在公元前五百年，孙子就参透了数据库分区的真谛

Oracle中索引的Hash分区，在大规模的高并发插入的数据库表上应用十分常见，因为这种场景非常容易产生冲突事件 ，使用Hash分区之后，可以极大的缓解。然而这也挖下了一个坑，那就是这个索引上的范围查找就变得不那么理想。

由此推论，分区上可以能遇到的大坑，其实在分库的场景同样使用。

比如说，做了分库，却发现交易的业务场景拿不到Sharding Key。采用了Hash的算法，算Sharding Key，又突然发现有个交易要范围查Sharding Key，以至于可能要去各个库兜一圈。

分区面对的坑，可以说在分库场景下，是急剧放大了。所以，不可以随意滥用分区，更加不可以随便乱分库。

3、容错率提高

反过来讲，我为何在开篇说分区十分伟大，尤其是Oracle。在你违背了种种优化原则之后，做了NPI，做了跨分区的JOIN等等。尽管有性能上的损失，无论如何，数据库都帮你把那些复杂的工作给完成了。

当你的需求不是实时响应时，这些奇奇怪怪的跨分区要解决的问题，Rdbms都还是透明的把这些工作给你做完了，这怎么能不说它是伟大的呢?这一点我想那些开发分布式数据库中间件的人，最能认同。

三、写在最后

最后写到这里，作为一个DBA，我特别希望给程序开发者传递一个理念，那就是这世界上一定没有一个完美的优化方案。

你要一个表，又能高并发插入，又能做各种各样高效的查询，一会范围，一会模糊。我只想说，这是不可能的。所有优化方案都是以牺牲某一种性能来换另一种性能。

而DBA的职责，就是搞清楚业务需要什么，不需要什么。牺牲掉不需要的功能，换取需要的功能，甚至于牺牲不常用的功能，换取优异的常用功能。这其实就是完美的方案，分区也不例外。

在本文的最后，我想留一个我一直困惑的问题。在我看了无数篇分库分表放在一起的文章和帖子之后，我开始怀疑人生了。

作者介绍 

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!