忍无可忍，我drop了主键

公司有一个生产系统，以前很少使用，现在用的多了，发现性能有问题，系统管理员找到我，于是查看事件，db file parallel write最多。查看os，i/o wait平均在50%。检查发现数据库系统中在频繁的对一个表进行update，抓到此sql查看执行计划是全表扫描。这个表是主要的生产表，数据量比较大。

检查此表的索引，大吃一惊：已经建了3个索引，但都是复合索引，并且复合的字段非常多，都有5到6个字段！其中有一个主键索引，也是5个字段的（晕！）

而系统中频繁运行的update语句的where条件用到的字段没有出现在上面索引的第一位。

再查询这几个索引的第一位字段的distinct值，发现都是非常小的！

     如此频繁的update，这么大的索引，却没一个对的，不慢才怪！主键由5个字段组成，第一次看到啊~~~快下班的时候，看到系统渐渐没有事务在跑了，犹豫片刻，保存好那个表的索引与约束的脚本后，drop掉主键，drop掉所有的索引。再建了2个索引，一个时间字段，貌似会用到的，另一个是update语句的where条件中2个字段的复合索引。

      今天上班，9点半是系统运行的高峰期，查看数据库与操作系统，一片平静~~~~呵呵。。
那个5个字段组成的primary key，有什么必要呢？这样的主键，花费太大啊。不知道会不会因为少了这个主键，系统后续运行出现问题

 

1） 我想也许开发人员当时的目的可能不想让这些字段重复吧，从业务上来说很少又这么设计的

2） 如果是为了保证唯一性的，楼主要小心咯

 

3） 没主键可能出现逻辑问题

     如果你的UPDATE用的是主键的列，可能是你的主键列顺序不优，改改看

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13165828/viewspace-607257/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13165828/viewspace-607257/