db2分区建库其实没那么难，跟着步骤慢慢来就行了

开始）

我之前看一些资料，感觉DB2的分区数据库特别高大上，全是些复杂的概念和命令，觉得那是专家才能碰的东西，后来实际做了一次，才发现根本不是那么回事，说白了，它就是把一个很大的数据库，像切蛋糕一样，分成几块，每一块放在不同的服务器上，这样做的目的很简单，就是当数据量太大，一台机器扛不住的时候，用几台机器一起来扛，提高处理能力和可靠性，你只要理解了几个关键点，然后一步一步照着做,真的能搞定。

你得把环境准备好，这不是DB2软件安装那么简单，你得有好几台机器，这些机器可以是物理服务器，也可以是虚拟机，这都没关系，关键有两点：第一，这些机器之间网络必须是通的，而且最好能通过主机名互相访问，所以你得把每台机器的IP和主机名对应关系在hosts文件里配好，或者有DNS服务器更好，第二，这些机器上安装的DB2版本必须一模一样，不能一台是11.5版，另一台是10.5版，那肯定不行，软件装好之后，要在每一台机器上都创建一个相同的操作系统用户，比如都叫db2inst1，并且密码也要设成一样的，这一步很重要，因为后续机器之间通信要靠这个用户身份来认证，这部分内容在IBM的官方文档《DB2高级管理工作台和性能指南》的“分区数据库环境设置”章节里有详细说明。

环境准备好了，接下来就是最核心的一步，规划你的分区，你想怎么分这个“蛋糕”？通常有两种分法，一种叫“按节点分组”，这个最简单，比如你有四台机器，你可以规定，所有表的前一半数据放在前面两台机器上，后一半数据放在后面两台机器上，这种分法对应用是透明的，也就是说，你以后写SQL语句的时候，完全不用关心数据具体在哪台机器上，DB2自己会去找到，另一种分法叫“按哈希分布”，DB2会根据你指定的某一个表字段（比如用户ID），通过一个数学公式算出一个值，根据这个值决定这条记录应该放到哪台机器上，这种方法能保证数据比较均匀地分散到所有机器上，避免出现“旱的旱死，涝的涝死”的情况，你需要在建表的时候通过“DISTRIBUTE BY HASH”这样的关键字来指定，选择哪种分法，取决于你的业务特点，这个决策过程在IBM红皮书《DB2分区数据库设计》中被称为“数据分布策略选择”。

规划好了，就开始动手建库，这里要注意，分区数据库的创建过程和我们平时在单机上建一个数据库有点不一样，它不是在某台机器上直接运行“CREATE DATABASE”命令就完事了，你需要先准备一个配置文件，这个文件里要写明你所有参与分区的机器的主机名、每台机器上DB2实例的通信端口号等等信息，使用DB2提供一个专门的工具，叫“db2ncrt”，来读取这个配置文件，并自动在所有机器上创建数据库目录结构，你可以把“db2ncrt”这个命令理解成一个总指挥，它一下令，所有机器同时动起来，这一步如果报错，多半是前面环境准备没做好，比如网络不通、用户密码不对之类的，回去检查一下就行，这个创建步骤在DB2信息中心的“创建分区数据库”操作指南里有一步步的截图和说明。

库建好了，就等于房子盖好了，但里面还是空的，接下来要创建表空间，表空间你可以理解为数据库里的“磁盘文件夹”，表就存放在表空间里，在分区环境下，创建表空间的关键在于，你要指定你的数据文件（容器）具体分布在哪些物理机器上，你可以创建一个表空间，让它的一部分数据文件在机器A上，另一部分在机器B上，这样，当你在这个表空间里建表时，表的数据自然就分布开了，这个是通过“ON NODE”子句来实现的，这一步做好了,后面建表就水到渠成了。

最后就是建表了，如果你前面表空间规划得好，建表就和普通建表语句几乎一样，唯一的区别就是，你可能需要加上我前面提到的那个“DISTRIBUTE BY HASH”子句，来指定按哪个字段分布数据，如果你用的是“按节点分组”的方式，那连这个子句都可以省略，建完表之后，强烈建议你验证一下数据是不是真的分布成功了，你可以连接到不同的分区节点上，分别执行“select count(*) from 表名”，看看每个节点上的数据量是不是符合你的预期，这个过程在开发者社区论坛里很多帖子都提到过,是检查分区是否生效的土办法但很有效。

全部做完之后，你会发现，整个过程其实就是把一个大任务拆解成了环境准备、规划、建库、建表空间、建表这么几个清晰的步骤，每一步都有明确的命令和检查点，遇到问题也基本能根据错误信息找到原因，根本不需要一开始就去死磕那些高深的理论，别被“分区”两个字吓到，静下心来，找一台测试机多练几遍，熟悉了之后再上生产环境，真的没那么难。 结束）