MySQL中复合主键的性能缺陷

Question

我们有一个表，其中包含一个由三个字段组成的复合主键(在MySQL 5.1中)。该表每秒有近200次插入和200次选择，表的大小约为100万行，而且还在不断增加。

我的问题是：“复合主键”是否会降低此表上的插入和选择的性能？

我应该使用简单的自动递增INT ID字段而不是复合主键吗？(我认为答案与MySQL处理多列索引的方式有很大关系)

Answer 1

INSERT和UPDATE的性能差别很小：(INT)和(INT, INT)密钥的性能几乎相同。

复合PRIMARY KEY的SELECT性能受多种因素的影响。

如果您的表是InnoDB，那么该表将隐式地聚集在PRIMARY KEY值上。

这意味着如果两个值都包含键，则搜索这两个值的速度会更快:不需要额外的键查找。

假设您的查询是这样的：

SELECT  *
FROM    mytable
WHERE   col1 = @value1
        AND col2 = @value2

表格布局是这样的：

CREATE TABLE mytable (
        col1 INT NOT NULL,
        col2 INT NOT NULL,
        data VARCHAR(200) NOT NULL,
        PRIMARY KEY pk_mytable (col1, col2)
) ENGINE=InnoDB

，引擎将只需要在表本身中查找确切的键值。

如果您使用自动增量字段作为假id：

CREATE TABLE mytable (
        id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
        col1 INT NOT NULL,
        col2 INT NOT NULL,
        data VARCHAR(200) NOT NULL,
        UNIQUE KEY ix_mytable_col1_col2 (col1, col2)
) ENGINE=InnoDB

，那么引擎将需要，首先，在索引ix_mytable_col1_col2中查找(col1, col2)的值，从索引中检索行指针(id的值)，并通过id在表本身中进行另一次查找。

但是，对于MyISAM表，这没有什么区别，因为MyISAM表是堆组织的，行指针只是文件偏移量。

在这两种情况下，将创建相同的索引(用于PRIMARY KEY或UNIQUE KEY)，并以相同的方式使用。

Answer 2

如果为InnoDB，则复合主键将包含在每个二级索引的每个条目中。

这意味着

• 您的辅助索引将占用与这些列+主键
• 中的所有列一样多的空间。如果需要的所有列都包含在辅助索引+ pk

中，则可以使用辅助索引作为覆盖索引。

当然，这既是劣势，也是优势。

复合主键不一定是坏的，有时它们可能真的很有帮助，因为InnoDB将它们聚集在一起-这意味着在PK上(磁盘限制的)范围扫描可以使用比非聚集索引所需的更少的IO操作来满足。

当然，如果在其他表中有外键，那么外键会更宽，因为它们需要包含主表中的整个键。

但总的来说，我会说不是的。拥有复合主键本身不会造成问题。然而，如果“大”主键(例如，大的varchars)超过了集群和能够使用覆盖索引的优势，那么它可能会做到这一点。

Answer 3

具有复合主键的

1. 会略微降低SELECT的速度，尽管这种影响几乎可以忽略不计，不值得担心。对这些列进行索引的
2. 会降低INSERT的速度，您肯定会为此担心足够多的INSERT。如果它是一个MyISAM表，其中INSERT锁定表，这比如果它是一个InnoDB表更令人担忧。如果通过使用auto_increment主键，您可以不对这些列进行索引，那么您将从更改中受益。但是，如果您仍然需要对这三个列进行索引(例如，如果您需要强制它们的组合具有唯一性)，那么它对您的performance-wise.

没有任何帮助