再论主键（二）

前面的blog里我说过在DB2中随便拿一个自增量列“创造”主键是很垃圾的行为，“业务无关”的主键是垃圾主键。只有在考虑某些特殊的管理要求时才需要这么做。
但我们都会看到在mysql的项目中这种行为是很普遍的，何故？
其实用自增列创造主键在mysql中也是基于管理的考虑而并非是业务的选择。[@more@]

严格来说只有在innodb引擎（SolidDB引擎用的较少）中这种设计才是可取的。
基于innodb引擎表是索引组织表，并非一般数据库中常见的堆表（DB2中全是堆表）。
表中所有数据都存储于cluster index中，cluster index默认按照primary key聚集，如果没有primary key就按照表中的唯一非空index聚集，如果两者都没有，innodb就会创建一个隐藏的主键，并按照该主键聚集；这个隐藏的主键是单调递增的rowid序列，该序列由全局共享--高并发时与表中单独创建自增主键相比更易产生争用。

这种情况下primary key的选择对innodb的数据操作和组织就非常关键了。此时将之称为“Surrogare key”比“primary key”更恰当，“primary key”是业务上的概念，“Surrogare key”是数据管理上的概念。不过碰巧的是innodb中“Surrogare key”选择的是“primary key”而已。

在innodb索引组织表中对聚集列的无序写入及更新都会造成很大的成本：
数据页移动，split page。。（cluster要保持聚集度）
而且在innodb中第二index会包含primary key--最终仍然是通过cluster index检索数据，primary key如果是字符一类较大，也会造成第二index体积过大。

如果我们在创建innodb引擎的表时，如果选择创建一个业务无关的自增列做primary key将会得到很多性能提升：
1 自增所以一定是顺序写入，不会造成数据页移动 split page
2 业务无关就不会被更新，也能避免数据页移动 split page
3 数字列体积较小，因此其他index的体积也会相对小，节省存储空间提升性能

基于myisam引擎创建的表是堆表，上面说的种种优势在myisam中并不存在。如果在myisam中也使用“业务无关”的自增列做主键依然如我前文所讲也是不合适的。

mysql现在确实很流行，开发使用者众多，但其中很多开发设计者对数据库了解的并不是很清楚，结果是这种设计就被不恰当的“普及”了。

“创造”主键的行为在DB2 DPF系统中就可以看出有多垃圾了，基于这个设计是不能改造成即使是很简单的DPF的（DPF此时毫无意义，性能太差，不多讲），必须要重新设计。

最后还是想强调一点：只有在特殊的数据库管理需求中才考虑“创造”主键，否则不要这么做。

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

转载于:http://blog.itpub.net/598443/viewspace-1058167/