大数据量要关系的数据库设计问题

huolan 2019-12-20

大数据量数据库操作和设计中的禁区
在操作数据库的使用中,有很多禁区,这些禁区是我们想都不要想,碰都不要碰的,一旦做了这些事情,带来的后果绝对是灾难性的。

1、主外键
主外键在小型应用,或者人数不多,可以控制的范围内绝对是可以使用的,但是一旦数据量大了起来,再使用外键约束会导致性能很差,一般互联网应想都不要去想外键这种东西了,因为这样的话会在读写时花费大量的性能去查询约束,而在请求量大的时候再去查询约束来消耗性能,后果和成本可想而知。
而且不管在测试还是后期数据维护时,你会发现,哎?这个表跟那个表连着呢?我是谁?我在那?我在干什么的哲学三问。

2、游标
这个你就更难为数据库了,因为游标会把整表执行变为行执行,你可以想象一下,一个十万级别或者百万级别的数据库,你让他一行一行的去执行,那好,性能消耗更加恐怖了,你的服务器基本什么事情都不要去做了,CPU和IO全去干这东西去了。

3、触发器
这个东西说真的,不管是谁写的,有时候你想知道触发器改了什么是真的麻烦,而且难以调试,还不好控制,这就要求我们在决定是否使用触发器的时候需要非常谨慎。

4、存储过程
存储过程一时爽,后面你再去改动项目的时候,整个跟他相关的类全部要重写,那感觉,相当的酸爽,不说了,先去哭会。

5、使用DROP和DELETE时
关于这个事情么,你可以参考下从删库到跑路和下面这个链接:
http://www.sohu.com/a/256357612_104421
所以说DROP和DELETE的时候要注意使用的条件和表,最好不要去动生产库,在非动不可时,一定要注意备份,千万注意,要不下一个从删库到跑路的人就是你了。

6、用TRUNCATE替代DELETE:
TRUNCATE是清空一个表内的数据,DELETE是DML操作,truncate是DDL操作;因此,用delete删除整个表的数据时,会产生大量的Rollback,占用很多的Rollback Segments, 而TRUNCATE不会。
在内存中,用delete删除数据,表空间中其被删除数据的表占用的空间还在,便于以后的使用,另外它是“假相”的删除,相当于windows中用delete删除数据是把数据放到回收站中,还可以恢复,当然如果这个时候重新启动系统(OS或者RDBMS),它也就不能恢复了!而用truncate清除数据,内存中表空间中其被删除数据的表占用的空间会被立即释放,相当于Windows中用shift+delete删除数据,不能够恢复!

7、 在查询中尽量不要用的关键字
or、以%开头的like、如果列类型是字符串,没有用引号引用起来、!=负向查询。
因为这几种情况的话是都不会去命中索引的而是去全表扫描,会浪费大量资源和时间。

相关推荐