构建千万级别用户的后台数据库架构的话题上，具体建议或做法如下所示：
1> 数据库的设计开始之前，必须优先进行业务的数据流梳理（注释：必须尽量考虑应用所有可能的功能模块），以及对业务优先进行优化和规划，然后根据数据流和功能 考虑数据库的结构设计和优化；
2> 千万级别用户量，若是非游戏行业的产品（SNS游戏除外），建议考虑用户数据拆分架构设计，以及考虑后续未来1-2年的承受量，若是SNS平台必须考虑拆分，除非考虑上SSD、Fusion-io、存储等更高端的设备，用金钱换时间的方式支持技术改造；
3> 数据拆分的核心与难处：同一个用户的数据尽量放一起（拆分规则要尽量简单可执行），拆分之后用户关系的数据如何保存的抉择有多种（存2份或存1份放一个地方），难处数据的分页，统计合并等；
4> 要考虑一些冗余的方式解决SQL性能问题，但是又不能过多引入冗余而造成IO开销增加太多，冗余字段要尽量整型字段；
5> 数据库表对象的字段属性，要尽量考虑数字化，尤其游戏行业；
6> 数据库设计过程中，对于索引组织结构要偏向共同操作最优先，其次应用外部用户级别的操作性能优先，最后内部用户的操作，硬尽量隔离，例如：搜索引擎Build操作、内部编辑团队审核等操作；
7> 数据库要从设计角度规避一些无法通过其他技术手段解决的模糊查询，类似全文索引的模糊查询，要走搜索引擎的模式，再通过数据库读具体的数据，一些必要的计数类型的数据，适当地考虑缓存；
8> 重点解决数据库级别的数据分页问题，要学会从前端应用用户的体验不降低的情况下，达到更高效的数据分页做法，类如论坛中帖子分楼的做法；
9> 数据库的设计必须考虑使用什么类型配置的物理服务器，核心参数：内存、CPU、硬盘（这个是关键：硬盘类型（注： SATA、SAS、SSD）、多少块盘、转速、容量，以及做RAID几），RAID卡内存及RAID写模式也需要考虑进去，必须结合数据量和读写能力要求进行一个预算规划，不一定超准确，但是要八九不离十；