MySQL中的复合主键性能缺陷

Question

我们有一个表,其中包含一个由三个字段组成的复合主键(它在MySQL 5.1中).此表上每秒有近200个插入和200个选择,表的大小约为100万行,并且正在增加.

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

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

Answer 1

INSERT并且UPDATE性能变化很小:它(INT)和(INT, INT)键几乎相同.

SELECT复合材料的性能PRIMARY KEY取决于许多因素.

如果您的表是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

,然后引擎首先需要查找(col1, col2)索引中的值,从索引ix_mytable_col1_col2中检索行指针(值id)并id在表本身中进行另一次查找.

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

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

Answer 2

如果是InnoDB,则复合主键将包含在每个二级索引的每个条目中.

这意味着

• 您的二级索引将占用与主键中的列+所有列一样多的空间
• 如果所需的所有列都包含在辅助索引+ pk中,则可以使用辅助索引作为覆盖索引

当然,这些分别是缺点和优点.

复合主键不一定是坏的,有时它们真的很有用,因为InnoDB将它们聚集在一起 - 这意味着使用比非聚集索引所需的IO操作少得多的IO操作可以满足PK上的(盘绑定)范围扫描. .

当然,如果你在其他表中有外键,它们会更宽,并且需要包含主表中的整个键.

但总的来说,我会说平衡.拥有复合主键本身不会导致问题.但是,拥有"大"主键(例如大变量)可能会超过群集的优势并能够使用覆盖索引.