一、什么是 MySQL 主键

咱们先聊聊 MySQL 主键是个啥。简单来说，主键就像是身份证号，在数据库的每一张表里，它能独一无二地标识每一行数据。打个比方，咱们有一个学生信息表，每个学生都有一个独特的学号，这个学号就可以作为这张表的主键。要是没有主键，数据库在找数据、更新数据或者删除数据的时候就会两眼一抹黑，不知道该操作哪条记录。

示例（MySQL 技术栈）

-- 创建一个学生信息表，并设置学号作为主键
CREATE TABLE students (
    student_id INT NOT NULL,  -- 定义学生 ID 列，且不能为空
    name VARCHAR(50),       -- 定义学生姓名列
    age INT,                -- 定义学生年龄列
    PRIMARY KEY (student_id) -- 指定学号为该表的主键
);

在上面的代码里，我们创建了一个 students 表，student_id 被设置为主键，这样就能保证每个学生的记录都能唯一被识别。

二、MySQL 主键设计原则

2.1 唯一性

这是主键设计最基本的原则。主键的值在整个表中必须是独一无二的，不能有重复。就像世界上不会有两个人的身份证号一样，表中的每一行记录的主键值也不能重复。还是拿学生信息表举例，如果有两个学生的学号一样，那数据库在查询或者更新数据的时候就会乱套。

示例（MySQL 技术栈）

-- 往学生信息表中插入一条记录
INSERT INTO students (student_id, name, age)
VALUES (1, '张三', 20);

-- 再次插入相同 student_id 的记录，会报错，因为违反了主键唯一性原则
INSERT INTO students (student_id, name, age)
VALUES (1, '李四', 22);

在这个示例中，第一次插入记录成功，因为 student_id 是唯一的。但第二次插入相同 student_id 的记录时，就会报错，因为违反了主键的唯一性原则。

2.2 非空性

主键的值不能是 NULL。这就好比身份证号不会是空的一样，因为如果主键为空，数据库就没办法明确地标识这一行记录。

示例（MySQL 技术栈）

-- 尝试插入一条 student_id 为 NULL 的记录，会报错
INSERT INTO students (student_id, name, age)
VALUES (NULL, '王五', 21);

由于 student_id 是主键，设置了非空约束，所以插入 NULL 值会导致操作失败。

2.3 稳定性

主键的值一旦确定，就尽量不要去修改它。因为主键就像是数据的“身份证”，频繁修改会让数据库在处理关联数据时出现问题。比如说，有一个成绩表和学生信息表通过学号关联，如果学号这个主键频繁修改，成绩表和学生信息表之间的关联就会混乱。

2.4 简洁性

主键的字段要尽量简洁，能用一个字段作为主键就不要用多个。因为如果主键字段太多，会增加数据库的存储开销和查询的复杂度。例如，只需要一个学号就能唯一标识学生，就不要用姓名和出生日期来组合作为主键。

三、自增 ID 作为主键的使用场景

自增 ID 是一种很常见的主键设置方式。它的特点是在插入新记录时，数据库会自动为其分配一个比当前最大 ID 值大 1 的新 ID。这种方式适合很多场景，下面给大家详细说说。

3.1 日志表

日志表主要用来记录系统的操作日志，比如用户的登录时间、操作内容等。这些日志记录通常是按照时间顺序依次插入的，使用自增 ID 可以方便地对日志进行排序和管理。

示例（MySQL 技术栈）

-- 创建一个日志表，使用自增 ID 作为主键
CREATE TABLE operation_logs (
    log_id INT AUTO_INCREMENT,  -- 定义自增的日志 ID 列
    user_id INT,                -- 定义用户 ID 列
    operation_content TEXT,     -- 定义操作内容列
    operation_time TIMESTAMP,   -- 定义操作时间列
    PRIMARY KEY (log_id)        -- 指定日志 ID 为该表的主键
);

-- 插入一条日志记录
INSERT INTO operation_logs (user_id, operation_content, operation_time)
VALUES (1, '用户登录系统', NOW());

在这个例子中，每次插入新的日志记录时，log_id 会自动递增，方便我们按照插入顺序对日志进行管理。

3.2 订单表

订单表记录了用户的订单信息，新订单会不断地产生。使用自增 ID 可以清晰地标识每个订单的先后顺序，便于订单的跟踪和管理。

示例（MySQL 技术栈）

-- 创建一个订单表，使用自增 ID 作为主键
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT,  -- 定义自增的订单 ID 列
    user_id INT,                  -- 定义用户 ID 列
    product_name VARCHAR(100),    -- 定义产品名称列
    order_time TIMESTAMP,         -- 定义订单时间列
    PRIMARY KEY (order_id)        -- 指定订单 ID 为该表的主键
);

-- 插入一条订单记录
INSERT INTO orders (user_id, product_name, order_time)
VALUES (2, '手机', NOW());

这里，order_id 会随着新订单的插入而自动递增，方便对订单进行排序和查询。

四、自增 ID 的优点

4.1 简单易用

使用自增 ID 非常简单，不需要我们手动去维护 ID 的唯一性。数据库会自动为新插入的记录分配一个合适的 ID，减少了开发的复杂度。就像上面的日志表和订单表示例，我们只需要专注于插入其他业务数据，ID 会自动生成。

4.2 性能较好

自增 ID 通常是整数类型，在数据库中存储和查询的效率都比较高。因为整数的比较和排序操作比其他类型的数据（如字符串）要快得多。而且，自增 ID 会按照顺序依次插入，在磁盘上的存储也是连续的，这有利于提高数据库的读写性能。

4.3 便于索引

数据库的索引是提高查询效率的重要手段。自增 ID 作为主键，非常适合创建索引。因为索引是按照主键的值进行排序的，自增 ID 的有序性使得索引的维护和查询更加高效。

五、自增 ID 的潜在问题

5.1 数据迁移问题

当我们需要将数据从一个数据库迁移到另一个数据库时，自增 ID 可能会带来麻烦。因为不同数据库的自增 ID 是独立管理的，迁移后新数据库中的自增 ID 可能会和原数据库中的 ID 不一致，这会导致关联表之间的数据关联出现问题。

示例（MySQL 技术栈）

假设我们有一个 users 表和一个 user_orders 表，user_orders 表通过 user_id 关联 users 表。

-- 创建 users 表
CREATE TABLE users (
    user_id INT AUTO_INCREMENT,  -- 定义自增的用户 ID 列
    name VARCHAR(50),            -- 定义用户姓名列
    PRIMARY KEY (user_id)        -- 指定用户 ID 为该表的主键
);

-- 创建 user_orders 表
CREATE TABLE user_orders (
    order_id INT AUTO_INCREMENT,  -- 定义自增的订单 ID 列
    user_id INT,                  -- 定义用户 ID 列，用于关联 users 表
    product_name VARCHAR(100),    -- 定义产品名称列
    PRIMARY KEY (order_id),
    FOREIGN KEY (user_id) REFERENCES users(user_id)  -- 定义外键关联
);

如果将这两个表的数据迁移到另一个数据库，由于自增 ID 的重新生成，user_orders 表中的 user_id 可能和新 users 表中的 user_id 对应不上，导致关联关系出错。

5.2 安全隐患

自增 ID 是连续且有序的，这就给一些别有用心的人提供了可乘之机。他们可以通过猜测 ID 的顺序来获取数据库中的其他数据。比如，在一个网站的用户信息查询接口中，如果使用自增 ID 作为用户标识，攻击者可以通过不断尝试不同的 ID 来获取其他用户的信息。

5.3 并发性能问题

在高并发的场景下，自增 ID 的生成可能会成为瓶颈。因为自增 ID 的生成需要对表进行加锁，以保证 ID 的唯一性。当有大量并发插入操作时，锁的竞争会导致性能下降。

示例（MySQL 技术栈）

假设有一个高并发的订单系统，很多用户同时下单。

-- 模拟高并发下单，多个事务同时插入订单记录
START TRANSACTION;
INSERT INTO orders (user_id, product_name, order_time)
VALUES (1, '电脑', NOW());
COMMIT;

在高并发情况下，多个事务同时尝试插入订单记录，由于自增 ID 的生成需要加锁，会导致部分事务等待，从而影响系统的并发性能。

5.4 数据分布问题

由于自增 ID 是顺序生成的，数据在磁盘上也是连续存储的。这可能会导致数据分布不均匀，某些磁盘块的访问压力过大，而其他磁盘块则闲置。例如，在一个大型的数据库中，新插入的数据总是集中在最后一个磁盘块，会影响磁盘的读写性能。

六、注意事项

6.1 合理选择主键类型

除了自增 ID，还有其他类型的主键可以选择，如 UUID（通用唯一识别码）。在选择主键类型时，要根据具体的业务场景来决定。如果业务对数据迁移和安全性要求较高，那么 UUID 可能是一个更好的选择；如果业务对性能要求较高，自增 ID 可能更合适。

示例（MySQL 技术栈）

-- 创建一个使用 UUID 作为主键的表
CREATE TABLE products (
    product_id CHAR(36) NOT NULL,  -- 定义 UUID 类型的产品 ID 列
    product_name VARCHAR(100),     -- 定义产品名称列
    PRIMARY KEY (product_id)       -- 指定产品 ID 为该表的主键
);

-- 插入一条记录，使用 UUID() 函数生成 UUID
INSERT INTO products (product_id, product_name)
VALUES (UUID(), '相机');

在这个例子中，我们使用 UUID 作为 products 表的主键。

6.2 考虑业务需求

在设计主键时，要充分考虑业务需求。比如，如果业务需要对数据进行范围查询，那么自增 ID 作为主键可能更合适；如果业务需要在分布式系统中保证数据的唯一性，那么 UUID 可能更适合。

6.3 定期维护数据库

对于使用自增 ID 的数据库，要定期进行维护，如清理无用数据、重建索引等。这样可以保证数据库的性能和数据的完整性。

七、文章总结

在 MySQL 数据库中，主键的设计非常重要，合理的主键设计可以提高数据库的性能和数据的安全性。自增 ID 作为一种常见的主键设置方式，有它的优点，如简单易用、性能较好、便于索引等，适用于日志表、订单表等场景。但它也存在一些潜在问题，如数据迁移问题、安全隐患、并发性能问题和数据分布问题等。在设计主键时，我们要根据具体的业务场景和需求，合理选择主键类型，同时注意数据库的维护，以确保数据库的稳定运行。