企业官网建设流程全解析

1. 索引与约束，先分清“加速”和“守规矩”

1.1 索引不是约束，约束也不是索引

很多人提到“SQL 表结构定义”时，会把索引、外键、约束混在一起讲，仿佛它们是一回事。实际处理过几个项目之后你会发现，这俩东西的定位完全不同，混在一起想只会越调越乱。

索引的本质是“加速”。它的作用是让查询少扫描数据，用空间换时间，类似于一本书的目录。没有索引也能查，只不过全表扫过去，数据量一大就让用户盯着加载转圈。

约束的本质是“守规矩”。它规定了数据能不能写入、能不能删除、能不能改。比如主键约束就是不能有重复、不能为空；唯一约束就是某列的值不能重复；外键约束就是子表的引用必须真实存在于父表，不能凭空指一个不存在的 id。

在 MySQL 的 InnoDB 引擎下，外键约束确实会自动帮你创建一个索引，这是引擎层面的行为，不代表“索引就是外键”。在其他数据库里，比如 PostgreSQL、Oracle，并不会因为你建了外键就自动帮你把索引一并建好。很多新人在 Oracle 里照着 MySQL 的习惯写表结构，结果外键列上没索引，删除父表记录时子表做全表扫描，一条删除语句能跑出分钟级延迟，这种坑我见得不少。

所以第一篇学习笔记，我先把结论放在最前面：索引解决的是“查得快不快”，约束解决的是“数据对不对”，外键属于约束，级联是外键的衍生行为，它们之间有关联，但别混淆。

1.2 为什么设计表结构时就要想清楚这两件事

我见过太多半路改表的项目。业务上线时表结构简单，没索引也没外键，CRUD 都很快。等到数据量过了百万级，慢查询开始冒出来，才回头补索引。补索引本身不复杂，复杂的是补的过程中要停服务、要处理重复数据、要协调多个团队的联调窗口。

更麻烦的是外键。如果前期没设计好，后期发现数据出现“孤儿记录”，比如订单表里指向了一个根本不存在的用户 id，这时候再想回头加外键约束，数据库会直接报错，因为已有的脏数据就不满足约束条件。你得先把脏数据清理干净，才有资格加外键。

在 SQL 表结构定义阶段，就应该把业务规则摸清楚：

• 哪些字段是唯一的，适合做主键或唯一索引；
• 哪些字段会被频繁用于 where 过滤、join 关联、order by 排序，适合建二级索引；
• 哪些表之间是强引用关系，需要外键来兜底；
• 删除父表数据时，子表数据是跟着删、置空、还是拒绝删除。

这些思考放在建表阶段，成本最低。改一张刚建好的表和改一张跑了一年的线上表，完全不是一个工作量级。

2. 索引设计，从单列到联合索引的取舍

2.1 主流索引类型先过一遍

日常工作里接触最多的索引类型就下面几种，我按数据库差异整理了一下：

InnoDB 的主键是聚簇索引，表数据本身就按主键顺序物理存储。二级索引（普通索引）的叶子节点存的是主键值，所以查到二级索引后还要回表取完整数据。这个概念后面优化慢 SQL 时非常关键，比如“覆盖索引”就是让查询列全部命中在索引里，省掉回表。

2.2 联合索引的最左前缀原则怎么用

单列索引好理解，联合索引才是比较容易出错的地方。

先说结论：联合索引“a, b, c”生效的条件是查询条件从 a 开始，连续的列才有效。比如 where a=1 会用到索引；where a=1 and b=2 会用到索引；where a=1 and b=2 and c=3 会用到索引；where b=2 单独用，索引基本失效；where a=1 and c=3，中间跳过了 b，c 就用不上索引。

这个原则叫最左前缀。我自己的理解是：联合索引就像“先按姓氏排序，再按名字排序”的通讯录。你要查“张伟”，可以先按张找到张姓区间，再在区间里找伟。但如果你直接在全册通讯录里找所有名字叫“伟”的人，排序规则根本不支持你跳着查。

实际建联合索引时，一个常见的经验是：

• 等值条件的列放最前面，范围条件的列放后面；
• 区分度高的列优先，比如“状态”这种只有几个枚举值的列，区分度很低，放前面意义不大；
• 结合具体 SQL 的 where 顺序调整字段先后。

举个例子，订单表经常按“店铺 id + 下单时间”查某段时间某个店铺的订单，那联合索引（shop_id, order_time）就比分别在两列上建独立索引更合适。独立索引的情况下，MySQL 一般只能选其中一个走索引，另一个靠回表过滤，性能差距明显。

2.3 建索引的实操命令与执行计划验证

以 MySQL 为例，建索引的常用 SQL 如下：

-- 创建普通索引 CREATE INDEX idx_shop_time ON orders (shop_id, order_time); -- 创建唯一索引 CREATE UNIQUE INDEX idx_order_no ON orders (order_no); -- 建表时直接带索引 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL, shop_id BIGINT NOT NULL, order_time DATETIME NOT NULL, UNIQUE KEY uk_order_no (order_no), KEY idx_shop_time (shop_id, order_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

SQL Server 的写法略有不同：

CREATE INDEX idx_shop_time ON orders (shop_id, order_time);

Oracle 禁用索引的常用命令，也顺便列一下：

ALTER INDEX idx_shop_time INVISIBLE;

网上很多人搜“oracle 禁用索引”，单独列出来了，这个操作主要是为了在不删索引的前提下测试性能，比 drop 再 recreate 安全得多。

索引建好之后，别忘了用执行计划验证是否真的生效。MySQL 里就是：

EXPLAIN SELECT * FROM orders WHERE shop_id = 100 AND order_time >= '2024-01-01';

重点看 type 列和 key 列。type 从好到差一般是：system > const > eq_ref > ref > range > index > ALL。看到 ALL 说明全表扫描；看到 ref 或 range 说明索引用上了。key 列会显示实际使用的索引名，如果为 NULL 就说明没有命中索引。

网上热搜“慢sql优化 explain主要看哪些信息”，下面几列要记住：type 判断扫描级别、key 判断实际索引、rows 判断预估扫描行数、Extra 判断是否文件排序或临时表。出现 Using filesort 或 Using temporary，意味着排序和分组没有用到索引，也是优化信号。

2.4 索引失效的几类经典场景

这部分算老生常谈，但每次排查慢查询都还是能遇到。

第一类：索引列上用了函数或运算。比如 where YEAR(create_time) = 2024，即使 create_time 上有索引也白搭。正确写法是 where create_time >= '2024-01-01' AND create_time < '2025-01-01'。

第二类：隐式类型转换。最常见的就是字符串列没加引号，比如 phone 列是 VARCHAR，条件写成 where phone = 13800001111，数字会被转成字符串去匹配，索引失效。热搜里“oracle 数据库sql导出的身份证信息是科学计数法”本质也是类型问题，导出时把文本当数字处理了——这个坑我们后面在“常见问题”里细说。

第三类：前导模糊匹配。like '%abc' 无法使用索引，like 'abc%' 可以用。这个取决于 B-Tree 的排序特性，开头不确定就不知道从哪开始扫。

第四类：OR 条件部分列无索引。比如 where name = '张三' OR phone = '13800001111'，如果只有 name 有索引而 phone 没有，整个 OR 条件可能退化全表扫描。用 UNION 拆开，或给 phone 也建索引都可解。

第五类：联合索引不满足最左前缀。前面已经展开过，不再重复。

3. 外键，引用完整性到底要不要交给数据库

3.1 外键能解决什么问题

外键的存在是为了保证引用完整性，简单说就是不让你在子表里插入一个父表根本不存在的引用。举例来说：

用户表 users 和订单表 orders，orders.user_id 指向 users.id。如果没有外键约束，完全能插一条 user_id = 9999 的订单，哪怕 users 表里根本没有 9999 这个用户。这种数据叫“孤儿数据”，跑报表时各种奇怪结果都出来了，关联查询匹配不上，数据对账对到怀疑人生。

外键约束一旦加上，插入或更新子表时会检查父表是否真的有对应记录，没有就直接报错。这条规则对应用层写代码也是有帮助的，相当于数据库层兜底，就算某个同事漏了业务判断，数据库也会拦住。

3.2 哪些场景反而不建议用外键

这个观点可能和教科书不太一样，但在互联网业务里确实存在“故意不用外键”的实践。原因主要有几点：

第一，高并发写入场景下，外键约束会带来额外的锁竞争和检查开销。每一次插入子表都要去父表确认引用是否存在，父表记录可能被锁住，并发一高就出现锁等待。

第二，分库分表后外键基本失效。订单表拆到 A 库，用户表拆到 B 库，数据库层面的外键无法跨库生效，最终还得靠应用层保证。

第三，业务删除逻辑复杂时，外键的级联行为可能让人措手不及。

所以很多互联网团队的做法是：表结构里不建物理外键，只保留逻辑外键（就是一个普通索引列），由应用层代码控制引用关系。这种方案更灵活，适合频繁变更的业务。

但如果你做的是内部管理系统、传统企业级应用，数据准确性大于一切，那外键该用就用，别犹豫。外键不是洪水猛兽，用错场景才是问题。

3.3 实操：Navicat 添加外键和手写 DDL

很多刚接触数据库的同事喜欢用 Navicat 图形化操作，这里也说一下。

在 Navicat 里给表加外键的大致路径是：右键点表 -> 设计表 -> 切到“外键”标签页 -> 添加一条外键 -> 选择字段和引用表、引用字段 -> 保存。

这里有个小坑，如果两张表的字段类型或字符集不一致，Navicat 会报错，比如字段对不上或者找不到引用的索引。字符集不一致是最隐蔽的，a 表字段是 utf8mb4，b 表字段是 utf8，DDL 能写但外键加不上。

手写 DDL 的核心语法如下：

ALTER TABLE orders ADD CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id);

注意一个细节：外键引用的父表列上必须有索引（如果是主键或唯一键就不用额外建）。MySQL InnoDB 在创建外键时会自动为子表的外键列建索引，其他数据库不一定。PostgreSQL 就需要你手动建好，否则外键限制会影响父表删除性能。

4. 级联约束，用好是利器，用错是连锁炸弹

4.1 四种级联策略怎么选

外键定义里通常会带上 ON DELETE 和 ON UPDATE 的级联策略，决定父表记录被删除或更新时，子表怎么办。SQL 标准里常见的几类如下：

口语一点说：CASCADE 是“跟到底”，SET NULL 是“断了关系但人还在”，RESTRICT 是“你想删，我不让”。

4.2 真实业务里我为什么不轻易用 CASCADE

我知道 CASCADE 的写法看起来很简洁，一行 ON DELETE CASCADE 就搞定“删用户连带删订单”。但实际业务里我强烈建议谨慎使用。

最核心的问题是：级联删除是自动的、隐式的、不可控的。你在父表执行一条 DELETE，数据库可能默默把关联的多张子表数据全删了。如果子表数据量很大，或者级联链路横跨三张表以上，一次“轻轻删除”可能变成一次大范围数据清理，耗时和锁表范围都超预期。

监控的时候更麻烦。通过应用日志你只看到对父表的一条删除操作，但数据库内部执行了多少条级联删除，你很难追踪。

所以我现在在业务系统里更倾向的做法是：

• 不物理删除，用逻辑删除，给表加一个 is_deleted 或者 deleted_at 字段；
• 删除操作变成 UPDATE，外键完全不受影响，历史数据也留着可追溯；或者外键用 SET NULL，删除父表记录，子表记录保留，但外键列置空。

这个思路在电商、内容系统里尤其常见。用户注销了，订单记录不能删，否则财务对不上；但可以把 user_id 置空，或者保留用户快照字段。

4.3 级联链路与性能、误操作的权衡

级联约束还有个隐性问题：多层级联时的性能。

假设 A 表删一条，级联删 B 表 100 条，B 表每条又级联删 C 表 10 条，那一次的删除放大效应就是 1 比 1000。事务持续时间长，锁范围大，很可能拖垮线上业务。更恐怖的是，这种级联删除不是程序员一行行写出来的，是数据库自动执行的，排查问题的时候你未必第一时间想到它。

另一个痛点是误操作。我曾经在一个内部系统里见过这样的案例：某同事要清理测试数据，删了一条主数据，结果因为外键级联配置，连带把误关联的所有业务数据全删了，最后只能靠凌晨备份恢复。从那以后，我对 CASCADE 的约束进一步收紧：只在“父子生命周期完全一致”的场景才允许用，比如“订单”和“订单明细”，订单没了明细没意义；其余一律逻辑删除或 SET NULL。

外键和级联约束本身没有对错，但对它的影响范围要有敬畏。

5. 常见问题与排查技巧实录

5.1 索引不生效的排查路线

算是我调试 SQL 的一个固定套路：

1. 先把 SQL 单独复制出来，EXPLAIN 看执行计划；
2. 确认 key 列是否为空；为空则索引没被选中；
3. 检查是否触碰了前面说的失效场景：函数、隐式转换、前导模糊、OR 条件、最左前缀不满足；
4. 确认数据库的统计信息是否过旧，必要时 ANALYZE TABLE；
5. 看表数据量是否太小，优化器觉得全表扫反而更快；
6. 检查字符集和排序规则是否一致，表连接时两边字符集不一致也会让索引失效。

最后一步最容易被忽略。两张表字段类型都是 VARCHAR，但一张表是 utf8mb4_general_ci，另一张是 utf8mb4_0900_ai_ci，join 时 MySQL 可能就无法使用索引。

5.2 外键加不上的几个典型原因

“Navicat 如何添加外键”这个搜索词热度一直很高，它背后通常是添加失败。我来盘一下常见原因：

第一，字段类型不一致。父表 id 是 BIGINT，子表 user_id 是 INT，即使数值上没问题，外键也建不上。SQL 对类型匹配要求严格。

第二，排序规则不一致。前面提过，字符集和 collation 不一致会导致失败。排查方法：查看两表字段的 COLLATE。

第三，已有数据不满足外键约束。子表里已经有 user_id=999 的脏数据，而父表没有这个 id，加外键必然报错。需要先清理脏数据：

-- 找出没有匹配父表的孤儿数据 SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL;

第四，父表被引用的列不是主键或唯一键。外键要求引用列必须有唯一性，否则数据库不知道该指向哪一行。

5.3 问题速查表

额外提一下“datetime 与时间函数”——热搜里也有“sql server 时间函数”，建议做时间范围查询时用闭区间写法排…

注意上面表格里，26003 那条和表结构无关，放到这里主要是提醒：如果你在 SQL Server 2019/2022 安装时报 26003 警告，很大原因是旧版本安装程序支持文件没有卸载干净，跟你的表设计没有半毛钱关系。不要花大把时间在索引和外键上找问题，先清理环境。

写到这，核心内容基本覆盖完整了。索引、外键、级联约束这三件事，理解起来不难，但真正用到项目里，每一条都是经验和教训堆出来的。我在实际开发和调优过程中，最深刻的体会就是：**表结构定义阶段多花半小时想清楚索引和约束，后面省下的是无数个小时的排查和返工。**尤其是外键和级联约束，宁可少用、慎用，也别让它在生产环境里给你“意外惊喜”。这套笔记我打算接着写下去，下一次可以专门聊聊视图、分区表或者查询优化器的一些细节。