大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

上周写了主键选型，后台收到一条留言：

“小耶，你说自增主键好。但我看很多规范文档都推荐用业务复合主键，比如订单明细用(订单ID,商品ID)，说这样更自然、更符合业务语义。到底听谁的？”

复合主键在数据库设计规范里确实常见。它看起来更“自然”——用业务字段组合做主键，不需要额外的自增列，听起来很合理。但很多人不知道的是，

在InnoDB的索引组织表结构下，复合主键的代价可能远超你的预期。

今天把这件事彻底拆开讲清楚。

复合主键（Composite Primary Key）是由两个或多个字段共同组成的主键。比如订单明细表的

，表示“一个订单中的一个商品”是唯一标识。

InnoDB是索引组织表——数据行本身存储在聚簇索引的叶子节点中。聚簇索引就是主键索引，叶子节点存放完整的行数据。

如果没有显式定义主键，InnoDB会选择一个非空唯一索引作为聚簇索引；如果没有合适的唯一索引，InnoDB会隐式创建一个6字节的ROWID作为聚簇索引。

二级索引（辅助索引）是除了聚簇索引之外的索引。二级索引的叶子节点存放的不是完整行数据，而是

查询时，先在二级索引中找到主键值，再通过主键值去聚簇索引中查找完整行——这个过程叫

每建一个二级索引，InnoDB都会把这个二级索引的列和

一起存到叶子节点中。主键越大，每个二级索引就越大。

-- 方案A：自增主键
CREATE TABLE order_items (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT,
    price DECIMAL(10,2),
    INDEX idx_order (order_id)
);

-- 方案B：复合主键
CREATE TABLE order_items (
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT,
    price DECIMAL(10,2),
    PRIMARY KEY (order_id, product_id),
    INDEX idx_product (product_id)
);

都是BIGINT，每个索引条目额外多出16字节。

在千万级数据量下，这个差异会放大到GB级别。

插入一条记录时，InnoDB需要更新：

二级索引越大，每次写入需要更新的索引页就越多，产生的Redo Log也越多。在高并发写入场景下，这个差异会直接体现在TPS上。

代价三：主键顺序影响插入性能

自增主键是顺序递增的，新数据总是插入到B+树的最右侧。这是最优的插入模式——不会触发页分裂。

复合主键的顺序取决于业务数据。如果主键是

不是顺序递增的（比如用了雪花ID），插入位置就会随机分布在B+树的各个位置，频繁触发页分裂。

在1000万行订单明细数据上做对比测试：

：复合主键在存储空间和写入性能上的代价是显著的。

四、什么场景下复合主键反而更合适？

说了这么多复合主键的代价，那它是不是完全不能用？

天然就是唯一的，用复合主键可以避免额外加一个自增列。同时，这个主键本身就是业务约束——数据库层面保证了不会出现重复的订单明细。

，复合主键可以一步定位到聚簇索引中的记录，不需要回表。而自增主键需要先通过二级索引找到

如果表上二级索引很少（比如只有1-2个），复合主键对二级索引的膨胀效应影响有限。如果表上有5个以上二级索引，复合主键的代价会成倍放大。

复合主键的“自然”是有代价的。在InnoDB的索引组织表结构下，复合主键会被复制到每个二级索引中，导致索引体积膨胀、写入性能下降。自增主键虽然看起来“不自然”，但它在存储效率和写入性能上有明确优势。选主键这件事，不能只看业务语义，还要看物理存储代价。

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

为什么你的数据库写入越来越慢？可能是复合主键惹的祸

选主键时，很多人会在“自增ID”和“业务复合主键”之间犹豫。复合主键看起来更“自然”——订单明细用(订单ID,商品ID)，用户角色用(用户ID,角色ID)。但在InnoDB的索引组织表结构下，复合主键会带来索引膨胀、二级索引体积暴涨、写入性能下降等隐藏代价。本文从InnoDB的存储结构出发，拆解复合主键和自增主键的物理差异，给出可量化的选型依据。

数据库

后端

架构设计

复合主键在InnoDB中虽符合业务语义，但会膨胀二级索引、降低写入性能并触发页分裂。自增主键在存储效率和写入性能上更优，尤其适合多二级索引或高并发场景。选择需权衡物理代价，二级索引少或高频主键点查时复合主键更合适。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

为什么你的数据库写入越来越慢？可能是复合主键惹的祸

为什么你的数据库写入越来越慢？可能是复合主键惹的祸

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐