建立一个100万条数据的表，是用一个表好，还是多个表并联好啊

建立一个100万条数据的表，是用一个表好，还是多个表并联好啊
假如一条数据是20个字段
单表时是每行100个字段，共20万行
多表时为5个表，每个表是每行20个字段，共20万行
哪个表比较好，速度快点啊。

57 个解决方案

#1

要看你具体的需求啊，有点模糊

#2

不怕不怕  放心用吧
不过记得把索引建好就OK

#3

我觉得还是做多表好

#4

一百万

什么数据库？
列数据关系？
各行数据使用频率？

其实一百万不算多

#5

数据量并不大，主要看表的用途。
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接；
如果只是查询，定期更新大批记录的话，建议单表分区。

#6

如果有很多冗余数据，就用分表。没有冗余数据就用单表

#7

100万，这点量还用几张表，也特看小SQL Server了

#8

我的数据库一天的数据量就是十几W条。

#9

引用 5 楼 mlemon 的回复:

数据量并不大，主要看表的用途。
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接；
如果只是查询，定期更新大批记录的话，建议单表分区。

回帖是一种美德！每天回帖即可获得 10 分可用分！

#10

引用 9 楼 qizhengsheng 的回复:

引用 5 楼 mlemon 的回复:
数据量并不大，主要看表的用途。 
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接； 
如果只是查询，定期更新大批记录的话，建议单表分区。 
 

回帖是一种美德！每天回帖即可获得 10 分可用分！真的?????

  ..

#11

引用 5 楼 mlemon 的回复:

数据量并不大，主要看表的用途。 
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接； 
如果只是查询，定期更新大批记录的话，建议单表分区。

是這個道理

#12

引用 9 楼 qizhengsheng 的回复:

引用 5 楼 mlemon 的回复:
数据量并不大，主要看表的用途。 
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接； 
如果只是查询，定期更新大批记录的话，建议单表分区。 
 

回帖是一种美德！每天回帖即可获得 10 分可用分！

 回帖是一种美德！每天回帖即可获得 10 分可用分！ 小技巧：教您如何更快获得可用分

#13

100W条的话，只要建一个索引就够了，如果只是查询数据的话应该足够可以了。速度不会慢。
如果一天到晚都在增删改查的话就得考虑分成几个表了。但是建立索引也是必须的。

#14

引用 13 楼 ziqing_deshi 的回复:

100W条的话，只要建一个索引就够了，如果只是查询数据的话应该足够可以了。速度不会慢。 
如果一天到晚都在增删改查的话就得考虑分成几个表了。但是建立索引也是必须的。

同意

#15

数据库里有个规定：行不能跨页，一页只能是8K，100个字段下来的，估计查询时一页也就一行数据吧，速度可想而知了，所以你还是将它分成向个表吧，这样数据的容量会减少，查询的速度也会快些

#16

一行的数据容量有限制的吧,很怀疑一行100列怎么放得下

#17

100列也OK的啊  8K 不够吗~ 多少是多啊~

#18

查询的话，一个表就行了，操作的话就不好说了。

#19

如果数据中的冗佘很小的话,可以用一个大表,不过我个人觉的还是以业务的逻辑来定是一个大表,还是多个小表

#20

看你的用法！多用于查询肯定一个表好一点咯！但是对数据管理很不方便哦

#21

还是一个表里好

#22

同意5楼的,其他人都是瞎白话.

#23

同意五楼

#24

i don't you say

#25

Test_A、Test_B、 Test_C、 Test_D、 Test_E: 字段 id int; F1~F20 char(50)

Test_G:F1~F20 字段 id int; F1~F100 char(50)
     
单表查询:  耗时2.16分钟
select * from Test_G
cpu开销：0.110157
I/O开销：74.0765
估计行大小：5023字节
估计行数：100000
运算符开销：74.1866（100%）
估计子树大小：74.1866

多表查询:  耗时2.56分钟
select a.id,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14,F15,F16,F17,F18,F19,F20,
F21,F22,F23,F24,F25,F26,F27,F28,F29,F30,F31,F32,F33,F34,F35,F36,F37,F38,F39,F40,
F41,F42,F43,F44,F45,F46,F47,F48,F49,F50,F51,F52,F53,F54,F55,F56,F57,F58,F59,F60,
F61,F62,F63,F64,F65,F66,F67,F68,F69,F70,F71,F72,F73,F74,F75,F76,F77,F78,F79,F80,
F81,F82,F83,F84,F85,F86,F87,F88,F89,F90,F91,F92,F93,F94,F95,F96,F97,F98,F99,F100
from Test_A a,Test_B b,Test_C c,Test_D d,Test_E e where a.id=b.id and a.id=c.id and
a. id=d.id and a.id=e.id
cpu开销：0.4356*4+0.110157*5=2.2932
I/O开销：21.2994+23.1513*4=113.9
估计行大小：5023字节
估计行数：100000
运算符开销：0.4359+0.4357+0.4356*2+21.4096+23.2614*4=116.198
估计子树大小：116.198
根据结果看出，多表并联在CPU 、I/O 、运算符上开销都比单表大的，耗时长。

#26

不用分吧，数据也不算大。

#27

即然出於是數據量大小的考慮，樓主你考慮將表欄位分開存放幹嘛呢？你將表拆分成五個表，那麼至少每個表都得有一個共同的欄位以供關聯吧？加起來比一個表的時候還要多出至少4個欄位，這空間是不少反而多了；

嫌數據大，就建分區表，將數據橫向分割，縱向分割，我看不出能從哪方面解決樓主的問題。

#28

引用 15 楼 baronyang 的回复:

数据库里有个规定：行不能跨页，一页只能是8K，100个字段下来的，估计查询时一页也就一行数据吧，速度可想而知了，所以你还是将它分成向个表吧，这样数据的容量会减少，查询的速度也会快些

所言及是，所以樓主你得評估一下你一行的數據最大有多少。

#29

引用 24 楼 devilidea 的回复:

i don't you say

這英文，看懂了的請舉手~~

#30

你们都是高手

#31

高啊。。。

#32

同意5楼

#33

单表的话：先考虑下一行的数据量大不大，哪些字段内容是比较大的，估计下，要是不大，可以用单表，多建几个索引
多表的：  逻辑上就是多了一点复杂度，不过不用考虑那么多

#34

1 有没有哪些字段很长，比如要装入XML之类的,长字段是不是经常要用，如果不是，最好分出去
2 建立索引
基本就差不多了
100万内的话不用分表

#35

100万的一般不用分表的，只要记得加索引。

#36

数据量打的时候记得加索引。个人观点觉得多表好一点

#37

一个表足矣

#38

单表，分区。

#39

如果一张表有冗余的话就用多张表，也可以创建一个视图
如果一张表存放数据没冗余的话就用一张表就行了

#40

回帖是一种美德！每天回帖即可获得 10 分可用分！

#41

100万，好多数据呀

#42

才100W, 一个表足以!!

#43

该回复于2009-07-17 19:48:14被版主删除

#44

100万就分表  你太小看MSSQL了啊。      你可以尝试哈 速度是非常快的。。只有主键。。

#45

如果一张表有冗余的话就用多张表，也可以创建一个视图 
如果一张表存放数据没冗余的话就用一张表就行了

#46

结构要合理哈,就象我建立个用户管理表,
用户名和密码以及邮箱这3个 最常用的查询字段都放一个表里，其他个人信息可填可不添的放其他表里,一个表就4\5个字段数据量很小的字段,查询注册的时候查询用户名是否被注册速度非常快的

#47

引用 5 楼 mlemon 的回复:

数据量并不大，主要看表的用途。
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接；
如果只是查询，定期更新大批记录的话，建议单表分区。

同意

#48

引用 5 楼 mlemon 的回复:
数据量并不大，主要看表的用途。 
如果是业务中事实表，经常进行添加、更新、删除的话，建议多表连接； 
如果只是查询，定期更新大批记录的话，建议单表分区。 

#49

用一个表就可以  放心的用吧

#50

多个表，虽然麻烦了点