大数据量数据库操作和设计中的禁区

大数据量数据库操作和设计中的禁区

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

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、如果列类型是字符串，没有用引号引用起来、！=负向查询。
因为这几种情况的话是都不会去命中索引的而是去全表扫描，会浪费大量资源和时间。

暂时就想起来这么多了，要是以后再想起来的话再补充吧。

本文为本人原创，转载请标明出处，谢谢。