在数据库设计和日常使用中，约束和索引是绕不开的两个基础概念。不少人在建表时随手加上主键、唯一约束，却说不清楚这些约束背后到底做了什么；也有人分不清建了一个唯一索引和加一个唯一约束到底是不是一回事。要理解MySQL的存储机制和查询优化，就必须把这两个概念掰开揉碎讲清楚。本文将从概念定义、常见类型、底层实现以及两者的关系几个角度，系统地梳理MySQL中的约束与索引。
一、什么是约束：保证数据正确性的规则
约束（Constraint）是数据库层面定义的一组规则，用来限制表中数据的取值范围和格式，确保写入的数据始终满足业务上的合法性要求。换句话说，约束是一道关卡，任何违反规则的数据修改操作都会被数据库直接拒绝，并抛出对应的错误。比如给用户表的手机号字段加了唯一约束，第二次插入相同的手机号时，MySQL会直接报Duplicate entry错误，根本不需要应用程序自己去校验。
MySQL中常见的约束包括以下几种：PRIMARY KEY主键约束，要求字段值唯一且不能为NULL，一张表只能有一个主键；UNIQUE唯一约束，保证字段值在表内不重复，但允许出现多个NULL；NOT NULL非空约束，禁止字段为空；FOREIGN KEY外键约束，保证子表中的关联字段值必须存在于父表中被引用的列里，维持参照完整性；CHECK约束（MySQL 8.0.16之后才真正生效）用于限定字段值必须满足指定条件；DEFAULT默认值约束则在插入未指定该字段时自动填充默认值。
来看一个综合了多种约束的建表语句：
CREATE TABLE t_user (
id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键',
username VARCHAR(50) NOT NULL COMMENT '用户名，不允许为空',
mobile CHAR(11) NOT NULL UNIQUE COMMENT '手机号，唯一',
age INT CHECK (age BETWEEN 0 AND 150) COMMENT '年龄范围校验',
dept_id BIGINT,
CONSTRAINT fk_dept FOREIGN KEY (dept_id) REFERENCES t_dept(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;约束的核心价值在于把数据校验从应用层下沉到数据库层。应用代码可能被绕过、可能有bug，但数据库约束是最后一道防线，只要约束存在，脏数据就进不来。当然约束也有代价：每写入一行数据都要做校验，外键约束还会带来额外的锁开销和级联操作成本，所以在一些高并发的互联网项目中，外键约束经常被省略，改为在业务逻辑中保证一致性。
二、什么是索引：加速查询的数据结构
索引（Index）本质上是一种帮助存储引擎快速定位数据的数据结构，可以理解为书的目录。没有目录时找一个知识点要一页页翻，有了目录直接翻到对应页码。数据库也是一样，没有索引时查询要走全表扫描，一行行比对；有了索引，InnoDB通过B+树结构，一般只需要三四次IO就能定位到目标数据，查询效率有数量级的提升。
InnoDB存储引擎的索引主要分为聚集索引和二级索引。聚集索引按照主键组织整张表的数据，叶子节点直接存放完整的行记录，所以主键的选择很重要，一般推荐使用自增整数。二级索引的叶子节点存放的是索引列的值加上主键值，如果通过二级索引查询的列不全在索引里，就需要回表，即先查二级索引拿到主键，再去聚集索引里取完整数据。理解了这一点，就能明白覆盖索引为什么能优化查询：把需要的列都放进索引，避免回表操作。
下面是几个常见的索引创建语句：
-- 创建普通索引 CREATE INDEX idx_username ON t_user(username); -- 创建联合索引，遵循最左前缀原则 CREATE INDEX idx_dept_age ON t_user(dept_id, age); -- 创建唯一索引 CREATE UNIQUE INDEX uk_mobile ON t_user(mobile); -- 查看执行计划，确认索引是否生效 EXPLAIN SELECT * FROM t_user WHERE dept_id = 3 AND age = 25;
索引虽然能大幅提升查询速度，但并不是越多越好。每建一个索引，就要多维护一棵B+树，插入、更新、删除数据时索引也要同步调整，写入性能会下降，磁盘空间占用也会增加。此外，联合索引要遵循最左前缀原则，对索引列使用函数或隐式类型转换都会导致索引失效，这些细节在实际优化中都需要注意。
三、约束和索引的区别与联系
很多人混淆这两个概念，是因为它们在MySQL中确实存在交叉：当你创建主键约束或唯一约束时，InnoDB会自动为对应的列创建一个唯一索引。也就是说，唯一性校验这件事，是借助索引来完成的——数据库在索引树上查找是否已存在相同的值，比逐行扫描高效得多。所以说唯一约束的底层实现依赖唯一索引，这就是两者的联系所在。
但反过来不成立：索引本身不等于约束。普通索引没有任何数据校验功能，它只是加速查询的目录，允许重复值，也允许NULL。约束是逻辑层面的规则，回答的是“数据能不能这么存”的问题；索引是物理层面的存储结构，回答的是“数据怎么找得快”的问题。一个关注数据正确性，一个关注查询性能，定位完全不同。
两者的对比可以总结如下：
- 目的不同：约束保证数据的完整性和合法性，索引提升查询速度。
- 生效方式不同：约束在写入时校验，违反则报错；索引在查询时被优化器选用，不影响数据合法性。
- 实现依赖不同：约束是逻辑规则，普通索引是纯物理结构；主键和唯一约束会自动创建唯一索引。
- 删除影响不同：删除唯一索引前必须先处理对应的唯一约束，否则会报错。
一个容易踩的坑是：有人为了去掉手机号的唯一限制，直接执行ALTER TABLE t_user DROP INDEX uk_mobile，结果报错提示无法删除被约束使用的索引。正确做法是先删约束：ALTER TABLE t_user DROP INDEX mobile或使用DROP UNIQUE KEY的方式处理约束关系。理解了约束与索引这种“逻辑规则挂载在物理结构上”的关系，这类问题就能轻松排查。
四、实际建表中的使用建议
在实际设计表结构时，建议遵循这样几个原则。第一，每张表都应该有明确的主键，优先使用自增主键或业务上天然唯一的短字段，保证聚集索引有序增长。第二，对于业务上要求唯一的字段，直接用唯一约束来保证，既有了数据校验，又自动获得了索引加速，一举两得。第三，外键约束在高并发场景下要谨慎使用，互联网项目通常去掉外键，靠应用层和定期校验保证数据一致性，以换取更好的写入吞吐。
关于索引的添加，不要凭感觉建，而要基于实际查询语句。通过EXPLAIN分析执行计划，观察type列和rows列，判断是否走了索引、扫描行数是否合理。多个查询条件经常一起出现时，考虑建联合索引并合理安排列顺序，把区分度高的列放在前面。同时可以利用覆盖索引减少回表，这对高频查询的优化效果非常明显。
最后需要记住一点：约束和索引虽然概念不同，但在维护时都要考虑写入成本。加约束意味着每次写入多一次校验，加索引意味着每次写入多维护一棵树，二者都是用写入时的开销换取查询或数据质量上的收益。设计阶段多花十分钟权衡，往往能省掉后期大量的优化和返价工作。