MySQL中的复合主键性能缺陷

3 回答

• 22

  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
  

  ，引擎只需要在表格中查找确切的键值 .

  如果您使用autoincrement字段作为假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 ），并将以相同的方式使用 .

  回复于 2024-04-29T14:41:07+08:00
• 2

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

  这意味着

  • 您的二级索引将占用主键中所有列的那些列的空间

  • 如果所需的所有列都包含在辅助索引pk中，则可以使用辅助索引作为覆盖索引

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

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

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

  但总的来说，我会说 balancer . 拥有复合主键本身不会导致问题 . 然而，具有“大”主键（例如大变量）可能会超过群集的优势并且能够使用覆盖索引 .

  回复于 2024-04-29T14:41:07+08:00
• 53

  • 让复合主键慢慢减慢 SELECT s虽然效果几乎可以忽略不计，但不值得担心 .

  • 将这些列编入索引会减慢 INSERT 的速度，你肯定做得足够多 INSERT 来担心它 . 如果它是一个_478574_锁定表格的MyISAM表，那么这将是一个值得关注的问题，而不是因为它在性能方面为你做任何事情 .

  回复于 2024-04-29T14:41:07+08:00