Heim  >  Artikel  >  Backend-Entwicklung  >  mysql数据表之间是多对多的关系时,中间表如果加上`id`主键,会不会比不加主键快?

mysql数据表之间是多对多的关系时,中间表如果加上`id`主键,会不会比不加主键快?

WBOY
WBOYOriginal
2016-06-06 20:35:39983Durchsuche

比如商品表和属性表,因为是多对多的关系,所以有个商品属性中间表;
CREATE TABLE IF NOT EXISTS dslxs_goods_attr (
goods_id mediumint(8) unsigned NOT NULL COMMENT '商品的id',
attr_id mediumint(8) unsigned NOT NULL COMMENT '属性的id',
KEY goods_id (goods_id),
KEY attr_id (attr_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品属性中间表';
如果在这张表中加个id mediumint(8) unsigned NOT NULL AUTO_INCREMENT,并设为主键PRIMARY KEY (id)。这样会不会快点,没有大数据测试不起来,哪位经验多的请告知一下。。

回复内容:

比如商品表和属性表,因为是多对多的关系,所以有个商品属性中间表;
CREATE TABLE IF NOT EXISTS dslxs_goods_attr (
goods_id mediumint(8) unsigned NOT NULL COMMENT '商品的id',
attr_id mediumint(8) unsigned NOT NULL COMMENT '属性的id',
KEY goods_id (goods_id),
KEY attr_id (attr_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品属性中间表';
如果在这张表中加个id mediumint(8) unsigned NOT NULL AUTO_INCREMENT,并设为主键PRIMARY KEY (id)。这样会不会快点,没有大数据测试不起来,哪位经验多的请告知一下。。

所谓的KEY只是索引的别名而已,而索引才是提升你这种映射表查询速度的关键,而你已经设置了这两个字段的索引了。现在可能要做的就是加个外键,提升表和整个数据库的稳定性,其他的也就这样了,加唯一键反而会略微增加插入负担,而且肯定不会有基于这个唯一键的查询,也许存在基于这个键的删除(可能性很小,非要加速的话,就添加一个二者的联合索引,插入会变慢,索引文件会变大)。

大致就是这样,要跳出所有表都要来个唯一递增键的误区。

补充一点,希望有些帮助。

聚簇索引:
MySQL InnoDB一定会建立聚簇索引,把实际数据行和相关的键值保存在一块,这也决定了一个表只能有一个聚簇索引,即MySQL不会一次把数据行保存在二个地方。
1) InnoDB通常根据主键值(primary key)进行聚簇
2) 如果没有创建主键,则会用一个唯一且不为空的索引列做为主键,成为此表的聚簇索引
3) 上面二个条件都不满足,InnoDB会自己创建一个虚拟的聚集索引

优点:
聚簇索引的优点,就是提高数据访问性能。聚簇索引把索引和数据都保存到同一棵B+树数据结构中,并且同时将索引列与相关数据行保存在一起。这意味着,当你访问同一数据页不同行记录时,已经把页加载到了Buffer中,再次访问的时候,会在内存中完成访问,不必访问磁盘。不同于MyISAM引擎,它将索引和数据没有放在一块,放在不同的物理文件中,索引文件是缓存在key_buffer中,索引对应的是磁盘位置,不得不通过磁盘位置访问磁盘数据。

缺点:
1) 维护索引很昂贵,特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插入新行后,选在负载较低的时间段,通过OPTIMIZE TABLE优化表,因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片

2) 表因为使用UUId作为主键,使数据存储稀疏,这就会出现聚簇索引有可能有比全表扫面更慢,所以建议使用int的auto_increment作为主键
3) 如果主键比较大的话,那辅助索引将会变的更大,因为辅助索引的叶子存储的是主键值;过长的主键值,会导致非叶子节点占用占用更多的物理空间

引自:http://blog.csdn.net/wyzxg/article/details/8779235

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn