MySQL 数据库表的数量很多会造成什么不良影响?

Yian
  • 1.1k

最近在帮学校做一个问卷调查系统,目前存储问卷以及问卷结果是这样的:

每新增一份问卷,数据库增加两个表,其中一个表用来存放这份问卷的信息,另一个表用来存放问卷结果信息

之前没怎么接触过数据库,在做这个系统之前查了一些关于数据库的资料,看到有人说

表的数量多不会影响查询速度,反而可能会因为你的数据存储结构更加有条理了而是查询更高效

在这个系统运行了一段时间之后,我感觉上面这种说法好像不太靠谱,现在正在准备重新设计数据库的结构。在此之前我想问一下各位熟悉数据库的前辈:数据库表的数量像我刚刚描述的那样动态增加会有什么弊端?数据库的结构设计一般遵循什么样的规则?


20140530 17:10 新增
感谢各位的回答,大家的回答算是解答了我的疑惑,另外我想说明一下,我这个问题主要不是问我这个数据库该怎么设计,而是侧重于数据表太多会有什么样的结果
再次感谢各位的回答啦 :P

回复
阅读 15.7k
7 个回答
✓ 已被采纳

别超过几百个表从性能上来说问题不大——个人浅见,无依据。

但是,如果你的每个表都只有几行数据,或者数据量不会增加的话,这种设计是对数据库表的误用,可以参考下面的方式优化:

  • 建立问卷表和和结果表,这样总共就只有 2 个表了。
  • 用 json/xml 或其他类似格式存储问卷和结果,因为不同问卷之间结构大多不同,用不到数据库表的查询特性

参考:

网上还有很多讨论,可以自己去看。

总体来说,表太多了,一是文件系统效率会降低,二是维护难度增加。

建议你根据实际需求情况,如果一天最多一个调查,那么无论哪种方案都是能够承受的。

得看你具体采用的引擎。
mysql innodb的话,如果不做额外设置,表是在一个空间里面的,不存在文件系统的限制。但innodb会将表和分区信息记录在内存,且不主动释放,如果表太多有可能耗尽内存(估计得有几百万张表了)。

其他引擎,如果是表独立建文件存放的话,那就受操作系统文件限制了

bingo_523022
  • 1
新手上路,请多包涵

表基本上遵循我们常说的几个范式,但是不能一味的去遵循这个东西,因为从实际的实际来说,这些范式有时候反而会成为累赘!但是,也不是说不遵循,就是说我们在满足自己需求和保证系统性能的情况下,尽量去满足范式,毕竟前任总结的东西存在这么久,有其可取之处!
其次,数据库的表并非越多越好,在某种层面上说,表多确实反映了你数据库分的够细致,但是从你查询的层面上来说,你在查询的时候相应也就慢了,而且可能由于你的疏忽,产生很多的脏数据,但是如果为了保证数据的完整性,关联好像是好的选择,但是可以明确说,表的关联很影响数据库的性能,所以根据自己的要求,选取适合的才是最好的!……拙见勿喷!

一份问卷数据库便生成2个表设计似乎有问题,除非是非常特殊的需求,正常的问卷调查数据库一般是这样设计的:
1、user(用户表)
id,uesrname,password,email
2、questionnaire(问卷表,用来记录问卷属性,例如标题、介绍、开始和截至日期等)
id,title,intro,type,start_date,end_date,create_date,update_date
3、question(问卷下设的问题表)
id,questionnaire_id(所属问卷),type(类型,比如是单选还是复选,还是其他输入等)
4、option(选项表,用来保存每个问题的可选项)
id,question_id(所属问题),label(标签),value(值)
5、vote(投票结果,用来保存每个用户选择的结果)
id,question_id(对于的问题),user_id,option_id(用户最终选择的选项)

最终是5~6个表之间。

我不是很清楚,为什么你要把每个问卷都拆成两个表,我想可能是你没有理解表和行的概念。一份数据,注意是一份,放在数据库中也不过就是一行,比较复杂的数据结构,放在数据库中,也无非就是多个关联表中的多行而已,完全没有必要为一份数据新建一个表。而且,数据库表多少本身影响不大,主要是在程序中操作的时候,比较麻烦,可以说,本来应该在表中用语句查询的问卷,你放到了程序中用代码查询,完全没有利用查询语句。

我们之前做了一个设计,是把用户数据按id取模,拆分到100个表中,后期处理的时候实在是非常麻烦。后来才明白,其实几十万几百万条数据,根本用不到拆那么多的表,一般的中小型系统都达不到mysql的瓶颈,很多时候是想太多了

章小凡
  • 3
新手上路,请多包涵

针对楼主这种业务场景,为什么不把问卷做成文件,在库表中去记录文件文件信息岂不是更方便?

宣传栏