关于建表冗余的讨论(性能的影响)

zhbname 2011-01-29 11:16:30

我现在要开发一个业务单据（数据量非常，都会超百万），在建业务单据数据表时涉及到一个是否冗余的问题，就拿主表来说吧。主表中有客户资料信息(客户资料表不会超50万），涉到5，6个字段内容。在建主表时有两种方法，一种是采用冗余客户资料信息，一种是不采用冗余只关联。采用第二种方法，在程序开发时老要关联客户资料表，影响性能。第一种方法，我担心冗余后
数据量大了，查询单表速度还不如关联查询快。现在，在这两种方法中不好决策，不知大家有什么好建议。或者大家能用数据或经验分析出这两种方法的优缺点？！

...全文

91 8 打赏收藏转发到动态举报

写回复

用AI写文章

8 条回复

切换为时间正序

请发表友善的回复…

发表回复

wuyu22222 2011-01-30

打赏
举报

关联吧（上万条的啊）

luoyoumou 2011-01-29

打赏
举报

-- 快过年啦：压岁钱拿来!

lwd4210 2011-01-29

打赏
举报

2,3楼基本都说了,百万级别的数据量不算大,最好别产生过多的冗余数据,后期维护会很麻烦,比如更新了要修改多个地方.

iqlife 2011-01-29

打赏
举报

最好不要冗余，
除非真的有必要，一般来说不建议，

lyiply 2011-01-29

打赏
举报

才百万不多，，我的表中都好几百万，，我建立了索引，查询速度还可以，，不到一秒
备注：我还内联接的一个表

njlywy 2011-01-29

打赏
举报

数据量不算大，冗余应该在正常范围内…

xman_78tom 2011-01-29

打赏
举报

在数据仓库中，时常需要进行反正规化，允许数据冗余，以加速查询。但是，在 OLTP 数据库中，如果客户信息存在冗余，在修改客户信息时就会涉及到修改多个位置。

zengjc 2011-01-29

打赏
举报

这种情况不需要采用冗余方法。
百万级别的表，并不算大，查询性能不会出问题，个人有几点建议：
1. 建立合适的索引。
特别是主表的常用查询列、关联表的关联列。
2. 优化SQL代码，选择高效的索引。
在tomcat等容器中对小表进行缓存也是一个好方法。
3. 控制单次查询返回的结果集。
可从业务、程序多方面控制单次查询可返回的最大记录数。
4. 冗余的方法初步看似简单高效，但不利于后期的扩展和保持数据一致性。