from: http://wordpress.cn.am/2009/01/wordpress-mu-multi-db/p>
WordPress MU 的安装行为和Lyceum不同，默认安装条件下它为每个用户建立8个数据表，这样的好处是结构相对清晰，各个用户的数据可以方便地分别进行管理。但是它无法便捷地实现全站的索引与检索，同时最大的弊病在于这样的结构在可扩展性上存在缺陷。一旦用户数量达到数千人，wp数据库内将存在数万张表，这给管理与备份带来很大的不便，而单库的数据表总存在物理极限，因此必须切分数据库。
WordPress.com 的用户数在写本文的时候达到了5,164,192，他们使用了多个数据中心同时建立了自己的负载均衡手段。这方面的细节将专文论述，本文主要讨论数据库结构的规划。他们开发了HyperDB 来划分数据库，具体有大致三种功能实现：
Partitioning，数据在不同层级上的迁移。
Replication，主/从数据库的读写规则，Master写，Slave只读不写，这是典型的负载均衡手段。
Failover，故障转移机制。
HyperDB的下载地址是：
http://svn.wp-plugins.org/hyperdb/trunk/
以上是背景知识介绍，我们主要论述在现实中广泛使用的Multi-DB。WPMUDEV的人在这个思路与成果的基础上开发了简化版的Multi-DB：
http://premium.wpmudev.org/project/multi-db
这个插件允许我们建立16/256/4096个数据库，用户建立时数据会被散列纳入相应的数据库中，这样就实现了用户数量级的跃升。譬如原先我们的心理接受极限是在单库数万张表，几千用户，那么使用multi-db之后承载能力，形式上地，就获得了×16、×256、×4096的倍率。当然我们知道其实这不是简单的乘数效应，因为系统的短板会在不同时期出现在不同的环节，比如blogs.dir的文件数理论极限，比如单一WEB服务器不做负载均衡时单机的负载能力上限，比如静态文件请求产生的资源消耗等等。但是，通过这个插件，我们就可以轻松跨越单数据库海量表单对站长心理上的考验。这取决于你对自身站点规划的需要。一个小型的团队博客无需计较这个问题，但是比如我早前运行的 blog.cn.com ，注册数字每一天都是在往骆驼背上加草，这也是为什么在2008年中期关闭注册的原因。现在你看到的 CN.am 及其绑定的站群，是建立在4096+2的定制上的。为什么要+2？因为我们倾向于把重要博客的数据单列以方便管理，同时对于博客的插件系统，有时需要一个global的数据库进行设置。此外，对于有特殊需求的用户，从数据稳定性考虑也可以为他们单独建库。因为不同的数据库可以存在于不同的数据中心，这一切都是可设置的。
以下介绍安装过程，我们的平台是CentOS，管理工具使用PHPMyAdmin。
1，首先使用工具构造建立数据库的代码：
http://db-tools.wpmudev.org/db_sql.php
推荐使用256库设置，因为16库不会带来本质上承载能力的提升，而4096仅限于中型以上的规划。
你获得的代码是：
CREATE DATABASE `wp_00` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
…
CREATE DATABASE `wp_ff` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
wp_00~wp_ff就是数据库的标号，你可以使用root身份在PhpMyAdmin里运行并创建。
2，建立用户赋予wildcard的数据库使用权限：
你需要对应地建立用户，然后为该用户赋权，确保它可以使用上述数据库。这是PhpMyAdmin的基本操作。
3，使用工具完善db-config.php：
http://db-tools.wpmudev.org/db_servers.php
你获得的代码类似于：
add_db_server(’00′, ‘dc1′, 1, 1,’38.×.×.×’,’localhost’, ‘wp_00′, ‘admin’, ‘password’);
…
add_db_server(’ff’, ‘dc1′, 1, 1,’38.×.×.×’,’localhost’, ‘wp_00′, ‘admin’, ‘password’);
然后完善这个到db-config.php文件。另外它需要数据中心的IP（DC IPs）那里只需要填写前三位IP位址，还要声明计划的数据库数目。
之后的安装每个人方法不同，我讲我的处理。现在需要单独建立一个global的数据库，一个home库。因为我需要一个单独的global库给插件，同时一个独立的库给主博客。然后也给user赋权，注意数据库命名的规则与前面的数据库阵列统一！然后令add_global_table(’global’);这句可用，global是你的那个总库名称。
我们先不上传这个插件，使用global库默认安装MU，这是基本操作。
然后上传插件，填写好db-config.php的每一个环节，这里可能容易出错，但是调试几次就好。需要声明建库总数，是否设定global，主要的是那个数据库阵列的配置。还有下面的add_vip_blog(1, ‘home’); 也就是声明主博客单独使用的数据库。
4，手动将主博客的8个表迁移到home数据库。完工！
数据库的scale一定要从长计议，在一开始就认真规划。一旦完成了配置，今后注册的新用户都会被散列到各自的合适位置。对应关系服从hash的计算：
http://cn.am/wp-content/scripts/list-hashes.php
所以第2个用户的数据库标号是c8，第100个ID的数据库标号是f8，以此类推，在需要修改他们的时候可以分别进行整理。
完工后的数据库非常整洁，很有逻辑性，符合数据库洁癖人士的喜好。因为总库和主博客的home库都是很清爽的。当然这最主要的目的就是实现用户负载数目的跃升。假定10000个注册用户，散列到256个数据库，每个数据库不到40人，管理起来很容易。如果按照单库接近1000注册用户的情况，使用4096个数据库，那就是超过400万用户，当然，我们都不会面对那样的托管情况:-)