问个问题,建表时,外键约束对性能有多大损耗

chuanzhang5687 2014-08-25 04:26:48
问个问题,建表时,外键约束对性能有多大损耗
...全文
582 17 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
17 条回复
切换为时间正序
请发表友善的回复…
发表回复
Tiger_Zhao 2014-08-26
  • 打赏
  • 举报
回复
客户只关心快不快。什么范式,没听说过。
所以如何取舍自己掌握。
發糞塗牆 2014-08-26
  • 打赏
  • 举报
回复
不用显式外键确实能提高性能,但是要付出更多的代价去维护数据一致性,Oracle和(SQL Server/DB2/Sybase)不同,前者比较“创造性”地实现功能,后者通常比较严格执行关系数据库理论。我个人偏向学院派,毕竟关系型数据库系统的最主要目的是维护数据的一致性,而不是“高性能”,数据的混乱即使查询秒杀,也没有多大意义。并且性能可以从多方面去合理提高。关系数据库理论存在了接近40年,早以接近完善,重点是如何去用好而已
专注or全面 2014-08-26
  • 打赏
  • 举报
回复
我这个确实不是“经验”,我写的那些系统也就是业余级的,只是自己的“经历”罢了,实在是摆不上台面 用不用主外键,这个确实有很多争议,每个人都有自己的看法 http://www.itpub.net/thread-1313696-3-1.html
Tiger_Zhao 2014-08-26
  • 打赏
  • 举报
回复
引用 9 楼 x_wy46 的回复:
[quote=引用 7 楼 ap0405140 的回复:] 不建议使用外键约束,会产生隐性锁,高并发时性能不佳.
不建外键或者主键约束,只是在应用中取做逻辑判断,太危险了,我是吃过这个亏, 因为写的代码总是有bug, 只怪自己技术烂 某些情况下判断不到,造成逻辑上重复的数据,处理起来太痛苦了, 如果有主外键约束,宁愿报错也不愿意让它出现错误的数据[/quote] 程序未经充分测试就上线,根本不及格!还没达到讨论性能的层次。 这种“经验就”不要分享出来了。
专注or全面 2014-08-26
  • 打赏
  • 举报
回复
引用 7 楼 ap0405140 的回复:
不建议使用外键约束,会产生隐性锁,高并发时性能不佳.
不建外键或者主键约束,只是在应用中取做逻辑判断,太危险了,我是吃过这个亏, 因为写的代码总是有bug, 只怪自己技术烂 某些情况下判断不到,造成逻辑上重复的数据,处理起来太痛苦了, 如果有主外键约束,宁愿报错也不愿意让它出现错误的数据
专注or全面 2014-08-26
  • 打赏
  • 举报
回复
外键约束在更新或者删除数据的时候,要去扫描(或者查找,这里不扣字眼)一遍引用这个外键的表,这个就是所谓的影响吧 其实想看这个代价很容易 test,test2两个完全一样的表,数据也一样,test一个列为test2的一个外键,在两个表中, 你删除同样一个ID的数据,效果不就出来了 置于设置外键的表怎么处理,是扫描还是查找,那就看如何见索引了



create table test
(
	col1 varchar(50),
	col2 varchar(50),
	col3 varchar(50),
	col4 varchar(50),
	col5 varchar(50),
)



alter table test
add constraint pk_id primary key(col1)  



--创建表2
select * into test2 from test 

select * from test2


--对表2增加外键
alter table test2
add constraint fk_col1 foreign key(col1) references test(col1)


alter table test2
add constraint pk_id2 primary key(col1)  

select * from test2

insert into test values (NEWID(),NEWID(),NEWID(),NEWID(),NEWID())
go 100000

insert into test2 select * from test


set statistics io on


delete from test where col1='E6200F7E-B53A-49EF-B3B5-96E485C390AF'
(1 行受影响)
表 'test2'。扫描计数 0,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'test'。扫描计数 0,逻辑读取 6 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。


delete from test2 where col1='E6200F7E-B53A-49EF-B3B5-96E485C390AF'
(1 行受影响)
表 'test2'。扫描计数 0,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。



唐诗三百首 2014-08-26
  • 打赏
  • 举报
回复
不建议使用外键约束,会产生隐性锁,高并发时性能不佳.
walkeeper 2014-08-26
  • 打赏
  • 举报
回复
进来围观大神解答~
---涛声依旧--- 2014-08-26
  • 打赏
  • 举报
回复
对插入和修改肯定有影响了,具体影响多大就不知道啦
xiaoxiangqing 2014-08-26
  • 打赏
  • 举报
回复
没有多大影响
我喝多了 2014-08-26
  • 打赏
  • 举报
回复
学习了
Tiger_Zhao 2014-08-26
  • 打赏
  • 举报
回复
那么就来鄙视程序员好了!
没测试就敢跑在真实环境下?
铁定的队友
chuanzhang5687 2014-08-26
  • 打赏
  • 举报
回复
引用 15 楼 Tiger_Zhao 的回复:
真实环境下,还能让非DBA直接更改数据? 这样的管理
不是在数据库里面,删除语句写在程序里面了。
Tiger_Zhao 2014-08-26
  • 打赏
  • 举报
回复
真实环境下,还能让非DBA直接更改数据?
这样的管理
chuanzhang5687 2014-08-26
  • 打赏
  • 举报
回复
理论上,我还是喜欢规范一线,就像发粪哥讲的,关系型数据库的一致性, 实际上,系统里面几乎没有外键约束,就像唐诗哥讲的,会产生隐性锁,高并发时性能不佳. 缘由是 昨天同事删了一张正式业务主表,把所有数据都删掉了,由于主表没有外键约束,所以删的是相当轻松, 700w条数据,弄的DBA都叫起来了。
向东流 2014-08-25
  • 打赏
  • 举报
回复
这个还真没办法说
發糞塗牆 2014-08-25
  • 打赏
  • 举报
回复
70-461上面有一个note,外键上加上非聚集索引能够提高性能。 至于约束,由于要检查是否满足定义,必然带来一定的开销,但是多少这个没有办法说准确

34,838

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧