联合主键和逻辑主键的优劣，多表同样一个主键是好还是坏？

zcj007w 2009-11-26 10:01:44

我在做项目是通常是一个表一个主键。一天正讨论数据库中是表时，说道一个话题：两个表用同样一个字段做主键。
这两个表的这个字段关系是外键关系。我从来没这么用过，不知道这样用是好还坏？
在网上查时无意间看到了联合主键，不知道联合主键和逻辑主键在做项目时的优劣？
初出茅庐，向各位高手请教？

...全文

480 4 打赏收藏转发到动态举报

写回复

用AI写文章

4 条回复

切换为时间正序

请发表友善的回复…

发表回复

crazylaa 2009-11-28

打赏
举报

支持PK与业务无关，要知道客户的需求是无止境的～～～弄不好开始强调绝对不会重复，某天你的主键变成有重复值了～～～吃过亏啊。。。。

yonghengdizhen 2009-11-28

打赏
举报

联合主键在应对频繁变化的需求时显得有点力不从心.因为业务的变化可能将原来能标识实体的组合属性变得不再唯一,而面对这样的变化.在多个关联实体上实施一个变化将会很困难.

Dave 2009-11-26

打赏
举报

具体情况具体对待。数据字典的设计根据需求分析来...

iqlife 2009-11-26

打赏
举报

联合主键第一次听说,听楼下答案....

MyISAM InnoDB 区别 InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，　　MyISAM 和 InnoDB 讲解　　InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。　　以下是一些细节和具体实现的差别：　　◆1.InnoDB不支持FULLTEXT类型的索引。　　◆2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。　　◆3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。　　◆4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。　　◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。　　另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%” 　　两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。　　我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。　　原因如下：　　1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。　　2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。　　3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。　　4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。　　5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。　　6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。　　7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。　　当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。　　另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

在一个表中user_id和type两个字段唯一确定一条记录，那么在设计中是将这两个字段设计为联合主键呢，还是建立一个逻辑主键id,而将这两个字段设计为唯一索引呢？这两种方式有什么区别？哪个更好呢？具体还是要看你的业务需求。另外说些在读写操作上的区别：1.主键和符合主键在查询上没什么性能上的区别（前提是索引相同，运用得当）2.写的性能上是有区别的，因为符合主键会使用更多的block去创建索引，所以在

UUID 作为 MySQL 的主键有其独特的优势，但也存在一些明显的劣势。考虑到UUID的劣势，有些系统采用折衷方案来优化性能。索引效率：由于UUID的随机性，它们的数据分布会非常稀疏，这可能导致数据库在查询时需要更多的磁盘I/O操作，降低了索引的效率。UUID（Universally Unique Identifier，通用唯一识别码）作为 MySQL 数据库的主键，有其独特的优势和劣势。易于迁移和合并：由于UUID的唯一性，数据可以在不同的数据库或系统之间轻松迁移和合并，无需担心主键冲突。

本文系统构建了一个逻辑严密的表格体系，围绕"相提并论的三者"展开组织设计。核心包含：1）组织表作为总表，包含3个并列主键（序号/三者/责任人）和4个内容字段；2）4个用户子表分别以单个主键或联合主键实现逻辑等价与完备性；3）原则表分为三则子表（刚性约束）、双簧子表（柔性跟踪）和总原则表（统一律统合）。通过主键关联、刚性柔性协同、三自性映射等机制，形成"3+2+1"完整规则体系，确保逻辑无悖论且完备。最后提出可延伸至派生表设计和系统落地方案。

准备面试时看的各种做的一些笔记可能有点乱 1.MySQL 三大范式第一范式:要求数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值（所有字段值都是不可分解的原子值）第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。第二范式：满足第二范式必须先满足第一范式第二范式要求实体中每一行的所有非主属性都必须完全依赖于主键、非主属性必须完全依赖于主键完全依赖：要求不允许存在非主属性依赖于主键中的某一部分属性意思就是必须依赖主键来保持这行数据的唯一性，

Oracle 高级技术

3,497

社区成员

18,710

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

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

+ 用AI写文章