关于一个数据库每个用户一个表的问题

我们要设计一个数据库，其中有一个相当于事务的表，我的初试想法是所有用户都有一个事务表，这种情况如果打到百万级的用户一个表可能就会达到亿级，所以有人提出每个用户一个事务表的，但是我想如果那么设计如果也达到百万级的话会出现，百万个表，这样搜索效率是不是会更低？（我的意思是对一个表的亿级的行搜索快，还是对一个百万级的表的只有几百个用户搜索的快），因为之前没有啥经验啊，只是从感觉上觉得这种措施不好，却不知道为啥不好，只是想请问下，这种设计有什么弊端啊，我一时给不出有理的理由希望大神能够给与指点。还有就是一个数据库能建立多少个数据表呢？对了我们服务器用的是mysql。

9 个解决方案

#1

对了 补充一下，那一个用户一个数据库是不是效果又如何？主要是我也没听过这么做的，但是有人提出，只是觉得这样船桨多个链接实体会很麻烦，而且mysql 能建立多少个数据库呢？

#2

你还是放一张表里吧，数据库没有你想象的那么脆弱。

#3

引用 2 楼  的回复:

你还是放一张表里吧，数据库没有你想象的那么脆弱。

你好，能给出一个有说服力的理由吗，因为老板强调的，用多表，你懂得想说服老板不能没有理由啊...麻烦了

#4

单独创建几百万的表？

那这个表怎么设计？
用户的所有行为动作你都放在这个用户表里面吗？

#5

用户总数固定吗？

如果固定且数量不大，那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来，似乎只会按用户分类来查，那么如果你要按时间来查询所有的用户信息呢？你如何把这些零散的数据集中起来？

如果用户数量不确定，那就麻烦了，你需要动态创建表，上面的问题也依然存在，除了这个，管理和组织这么一堆不知道什么时候就会变的东西，相信是件很痛苦的事情。

就个人的理解，分表主要是解决两个问题，一是数据压力太大，分摊负载，一是解决写入时的效率，因为如果一个表太大，写入数据时建立索引会花费大量时间。而对于查询的速度提升并不大。
但你的数据库，似乎也只是一张历史记录表，只有一次写入操作而已，分表到底能有多大的好处，你自己权衡吧。

嗯，你可以了解下分区表的一些功能，看是否适用。

以上是个人的一些考虑，供参考，如果有什么错误，大家指正。

#6

引用 4 楼  的回复:

单独创建几百万的表？

那这个表怎么设计？
用户的所有行为动作你都放在这个用户表里面吗？

事务表的意思就是创建一个类似任务的东西，也就是相当于笔记。一个用户一个表，可能就是这么设计表名，task_“uid”，就是task加用户ID组成，如果用户达到百万级，就会有百万个表，我就是想知道是这样设计好还是一个大表，统一放这几百条记录乘以几百万用户，也就是上亿条记录好

#7

引用 5 楼  的回复:

用户总数固定吗？

如果固定且数量不大，那么一个用户一张表还有可行性。但这里可能需要牵涉到后面的扩展。你的查询可能在现在看来，似乎只会按用户分类来查，那么如果你要按时间来查询所有的用户信息呢？你如何把这些零散的数据集中起来？

如果用户数量不确定，那就麻烦了，你需要动态创建表，上面的问题也依然存在，除了这个，管理和组织这么一堆不知道什么时候就会变的东西，相信是件很痛苦的事情。

就个……

首先，我这种一个用户一个表，不是用户数数量确定的，是用户数量动态增加的，就是一个注册就会多一个。
通过你的介绍，我可以这么理解吗？这种建表，一、对以后的数据挖掘不是很好；二、动态建表很复杂，不容易实现；三、以后DBA面对这么多表会很头疼。
不知道我的理解对不对，还有其实我不知道DBA都做啥事，我真的是个小白，只是在帮导师做项目，也没人带，很多事情都是摸索中，麻烦了。

#8

呃，用户数要不断增长到百万……，你们是出于什么一种想法，要一个用户一张表呢？

#9

引用 8 楼 live_evil 的回复:

呃，用户数要不断增长到百万……，你们是出于什么一种想法，要一个用户一张表呢？

老板说，第一方便远程数据库和本地数据之间的同步，就是都有task表，这样一个用户一个表方便同步。我其实一直想做成大表的，只是没有好的理由劝服老板所以才来这里咨询