1. 项目概述：为什么我们需要一套建表规范？

干了这么多年后端开发，我见过太多因为数据库表设计“随心所欲”而引发的血泪史。一个项目初期跑得飞快，随着业务增长，数据量上来后，各种性能瓶颈、逻辑混乱、维护成本飙升的问题就全暴露出来了。很多时候，问题根源不在复杂的业务逻辑，而在于最初建表时那几行看似简单的CREATE TABLE语句。

“数据库建表设计规范及原则”这个话题，听起来像是学院派的老生常谈，但恰恰是决定一个系统能否健康、稳定、易于扩展的基石。它解决的不仅仅是“表能不能建起来”的问题，更深层次的是解决团队协作的一致性、数据模型的可持续性、以及未来面对业务变化时的弹性问题。无论是刚入行的新人，还是经验丰富的老手，一套清晰、可落地的建表规范，都能让你在设计和评审时心中有谱，避免很多“坑”。

简单来说，这套规范就是给数据库设计这个“自由创作”过程，加上一套经过实战检验的“语法”和“最佳实践”。它告诉你字段该怎么命名、类型该怎么选、索引该怎么加、关系该怎么定。接下来，我会结合自己踩过的坑和总结的经验，把这套规范拆解开来，让你不仅能照着做，更能理解背后的“为什么”。

2. 核心设计原则：从道到术的指导思想

在深入到具体的命名规则或字段类型之前，我们必须先理解支撑这些具体规则的顶层原则。这些原则是设计的“道”，它们决定了我们设计方向的正确性。

2.1 唯一权威源原则

这是我最想强调的第一原则。任何一份业务数据，在数据库中必须有且仅有一个权威的存储位置。举个例子，用户的基本信息，如user_id,user_name，就应该只存储在user主表中。如果在订单表order里又存了一份buyer_name，这就违反了该原则。

为什么它如此重要？一旦同一份数据存在多个副本，最大的噩梦就是数据不一致。当用户修改了昵称，你是只改user表，还是需要同步去更新所有存了他名字的订单、评论、日志表？后者几乎是不可能完成的任务，最终会导致系统不同地方查到的用户名不一样，引发严重的业务逻辑错误和信任危机。

实操心得：在设计时，如果发现需要在多个地方存储同一语义的数据（比如商品名称），首先应该问自己：这里存的是不是就是一个“冗余字段”？如果是，那么必须明确它的更新机制。更常见的做法是，只存储关联ID（如product_id），通过联表查询或业务层拼接来获取最新的权威信息。这虽然可能增加一点点查询复杂度，但换来了数据一致性的根本保障。

2.2 持续演进与扩展性原则

数据库表结构不是一成不变的墓碑，它应该像活着的生物一样，能够随着业务成长而平滑演进。这意味着我们的设计要具备“向前兼容”的能力。

核心要点：

1. 慎用删除和重命名：对于线上已使用的表、字段，绝对不要轻易执行DROP COLUMN或RENAME COLUMN。这会导致依赖该字段的现有代码立即崩溃。正确的做法是“先增后弃”：先添加新的字段，逐步将业务逻辑迁移到新字段上，经过足够长的观察期（并确认无任何查询依赖旧字段后），再在某个低峰期下线旧字段。
2. 为字段预留空间：对于某些可能扩展的字段，在设计之初就要考虑其扩展性。例如，一个状态字段，如果初期只有“0-未处理，1-已处理”，那么使用TINYINT是合适的。但如果未来可能有几十种状态，那么可以考虑使用SMALLINT甚至VARCHAR来存储状态码，但更推荐的是使用SMALLINT配合一张独立的“状态字典表”，这样扩展性最好，也便于管理。
3. 使用注释明确意图：每个字段的COMMENT不仅是写给别人看的，更是写给三个月后的自己看的。清晰地说明字段的用途、取值范围、与其他字段的关系，是降低未来维护成本最廉价有效的方式。

2.3 高性能与可维护性平衡原则

设计规范常常需要在“查询快”和“维护易”之间做权衡。纯粹的规范化（范式化）设计有利于减少冗余、保证一致性，但可能导致多表关联查询，影响性能。反之，过度反范式化（冗余存储）虽然提升了单表查询速度，却增加了数据同步的复杂度和不一致风险。

我的经验是：在核心业务模型上，优先遵循第三范式（3NF），确保数据的一致性和基础结构的清晰。然后，针对明确的、高频的、性能敏感的场景（如报表查询、实时展示页），再有目的地、受控地引入反范式设计，比如在订单表中冗余一份商品快照信息（商品名、缩略图等）。关键是要记录下这些冗余设计的理由和更新逻辑，并在设计文档中明确标出。

3. 命名规范：让名字自己会说话

混乱的命名是理解数据库结构的最大障碍。一套好的命名规范，能让团队任何成员看到表名和字段名，就能大致猜出其作用和归属。

3.1 表命名规范

1. 使用复数名词或集合概念：表存储的是一类实体的集合，因此推荐使用复数形式或能体现集合概念的名词。例如，users,orders,products。有些团队也习惯用单数，如user，关键在于团队内部统一。我个人更倾向复数，因为SELECT * FROM users在语义上更直观。
2. 使用小写字母、数字和下划线：这是最通用、兼容性最好的做法。避免使用大写字母（不同数据库大小写敏感策略不同）和特殊字符。例如，order_details优于OrderDetails或orderDetails。
3. 关联表命名：对于多对多关系的中间表，可以使用关联双方表名的组合，按字母顺序排列，并用下划线连接。例如，用户和角色的多对多关系表，可命名为user_roles。
4. 前缀与后缀的使用：可以约定特定的前缀来区分不同类型的表，但这要谨慎使用，避免过度设计。常见的如：
   • t_/tb_：表示表（在一些老系统中常见，现代设计已不推荐，显得冗余）。
   • dim_：维度表（数据仓库中常用）。
   • fact_：事实表（数据仓库中常用）。
   • tmp_/temp_：临时表。
   • bak_/_history：备份表或历史表。 对于常规业务表，我建议不加前缀，保持简洁。

3.2 字段命名规范

1. 使用小写蛇形命名法：即全部小写，单词间用下划线分隔。例如：user_id,created_at,is_deleted。
2. 避免使用保留字：不要使用date,time,order,group等数据库或编程语言的保留字作为字段名。如果业务上确实需要，可以加前缀或后缀，如order_date,user_group。
3. 外键字段命名：通常与被引用表的主键名保持一致。如果users表的主键是id，那么在orders表中引用它的外键可以就叫user_id。如果存在多个引用，可以加上前缀以示区分，如creator_user_id和approver_user_id。
4. 布尔字段命名：使用is_,has_,can_等前缀，明确表示真假。例如：is_active,has_verified,is_deleted。值使用1/0或TRUE/FALSE。

3.3 索引命名规范

清晰的索引名有助于在EXPLAIN语句或慢查询日志中快速定位。

• 主键：pk_表名，例如pk_users。
• 唯一索引：uk_表名_字段名，例如uk_users_email。
• 普通索引：idx_表名_字段名，例如idx_orders_created_at。
• 复合索引：idx_表名_字段1_字段2，例如idx_orders_user_id_status。

注意：命名规范一旦在团队内确定，就必须严格遵守。可以借助代码审查（CR）工具或数据库变更管理工具（如 Liquibase, Flyway）的规则检查来保证一致性。

4. 字段设计与数据类型选择：细节决定成败

字段是表的细胞，其设计质量直接影响到数据存储效率、计算准确性和查询性能。

4.1 数据类型精挑细选

选择最小的、能满足当前和可预见未来需求的数据类型。这不仅节省存储空间，更能提升索引效率和内存计算速度。

1. 整型：

   • TINYINT：范围 -128 ~ 127，适用于状态码、枚举（如is_deleted）。
   • SMALLINT：范围 -32768 ~ 32767。
   • MEDIUMINT：范围约 -800万 ~ 800万。
   • INT：最常用的整型，范围约 -21亿 ~ 21亿。用于主键、外键、数量等。
   • BIGINT：范围极大，用于可能超过INT范围的ID（如分布式ID）、大数据量计数。
   • 实操要点：对于非负的数值，务必使用UNSIGNED关键字，可以将正数范围扩大一倍。例如INT UNSIGNED范围是 0 ~ 42亿。

2. 字符型：

   • CHAR(N)：定长字符串。适合存储长度固定或几乎固定的短字符串，如国家代码(‘CN’, ‘US’)、MD5哈希值(32位)。查询速度略快于VARCHAR。
   • VARCHAR(N)：变长字符串。最常用的字符类型。N表示最大字符数。对于UTF8mb4编码（支持emoji），一个字符最多占4字节，所以VARCHAR(255)最大可能占用 255*4 + 长度前缀 ≈ 1024字节。超过255后，长度前缀会从1字节变为2字节，因此255是一个常见的分界线。
   • TEXT：用于存储大段文本，如文章内容、日志详情。有TINYTEXT,TEXT,MEDIUMTEXT,LONGTEXT之分。注意：TEXT类型字段在排序、创建索引（前缀索引除外）时可能会使用磁盘临时表，性能较差，尽量避免在WHERE条件或ORDER BY中使用。

3. 时间与日期：

   • DATETIME：范围 ‘1000-01-01 00:00:00’ 到 ‘9999-12-31 23:59:59’，存储与时区无关的绝对时间值。占用8字节。
   • TIMESTAMP：范围 ‘1970-01-01 00:00:01’ UTC 到 ‘2038-01-19 03:14:07’ UTC。占用4字节。它存储的是UTC时间戳，存入和取出时会根据数据库连接设置的时区进行转换。适用于需要记录精确时间点且可能跨时区的场景。
   • DATE：仅存储日期。
   • TIME：仅存储时间。
   • 强烈建议：所有需要精确到秒的创建、更新时间字段，统一使用DATETIME或TIMESTAMP，并在业务代码中传入明确的UTC时间或服务器本地时间（并确保数据库时区设置正确）。避免使用字符串存储时间。

4. 数值精度型：

   • DECIMAL(M, D)：精确小数类型，适用于需要精确计算的金额、利率等金融数据。M是总位数，D是小数位数。例如DECIMAL(10, 2)表示总共10位，小数点后2位，能存储最大为 99,999,999.99。
   • FLOAT/DOUBLE：浮点数，存在精度损失，适用于科学计算或对精度要求不高的场景。金额不要用浮点数！

4.2 字段约束与默认值

1. NOT NULL：尽可能为字段指定NOT NULL。NULL值在索引、比较和计算中处理起来更复杂，且语义模糊（是“没有值”还是“值未知”？）。如果一个字段业务上可能为空，但逻辑上有合理的默认值，就设置默认值而不是允许NULL。例如，count字段默认0，status字段默认 ‘pending’。
2. 默认值（DEFAULT）：为NOT NULL的字段设置合理的默认值。时间字段如created_at可以设置DEFAULT CURRENT_TIMESTAMP。updated_at可以设置DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP（MySQL 5.6.5+支持）。
3. 注释（COMMENT）：再次强调，为每个字段写注释。这是成本最低的文档。

4.3 范式化与反范式化的实战权衡

这是一个需要结合具体业务场景反复斟酌的点。

场景示例：电商订单表

• 完全范式化设计：
  • orders表：order_id,user_id,total_amount,status,created_at
  • order_items表：item_id,order_id,product_id,quantity,price
  • 查询一个订单详情时，需要orders联表order_items，再联表products获取商品名称、图片等。
• 引入反范式化设计：
  • 在order_items表中，除了product_id，冗余存储product_name和product_image。因为订单一旦生成，其商品信息就是历史快照，不应随后来商品信息的修改而改变。
  • 优点：查询订单详情时，无需再联表products，性能提升显著。
  • 缺点：增加了存储空间，且如果业务允许“修改已下单商品信息”（通常不允许），则需要复杂的同步逻辑。
  • 决策：在这个场景下，由于订单快照的稳定性要求，这种反范式化是利大于弊的，也是业界通用做法。

核心判断标准：冗余的数据是否是“不变的”或“变化频率极低且影响可控的”？如果是，可以考虑反范式化以换取性能。同时，必须在设计文档中明确记录此冗余字段及其数据来源。

5. 索引设计艺术：为查询插上翅膀

索引是提高查询性能最重要的手段，但绝不是越多越好。不当的索引会降低写操作（INSERT/UPDATE/DELETE）速度，并占用额外空间。

5.1 索引创建的核心原则

1. 只为用于搜索、排序、分组的列创建索引：即频繁出现在WHERE、ORDER BY、GROUP BY以及JOIN ... ON条件中的列。
2. 考虑列的基数（Cardinality）：基数指列中不重复值的数量。基数越高，索引的区分度越好，效果越明显。例如，为“性别”这种只有两三个值的列建索引，效果微乎其微；而为“用户ID”、“手机号”这种高基数列建索引，效果立竿见影。
3. 使用复合索引覆盖查询：一个复合索引(col1, col2, col3)相当于建立了(col1)、(col1, col2)和(col1, col2, col3)三个索引。设计时应考虑查询模式，将最常用的列放在前面，并且遵循“最左前缀匹配原则”。
4. 短小精悍原则：索引列的长度越短越好。特别是对于字符串列，可以考虑使用前缀索引INDEX(field_name(length))，但需注意前缀长度的选择要能保证较高的区分度。

5.2 复合索引设计与最左前缀原则

这是索引设计的重中之重，也是容易出错的地方。

假设我们有查询：

SELECT * FROM orders WHERE user_id = 100 AND status = 'completed' ORDER BY created_at DESC;

低效的设计：

• 单独在user_id、status、created_at上各建一个索引。MySQL在一次查询中通常只会选择一个最优索引（在早期版本中可能使用索引合并，但效率并非最佳）。

高效的设计：

• 创建一个复合索引idx_user_status_created (user_id, status, created_at)。
• 为什么高效？这个索引可以完美覆盖这个查询：
  1. WHERE user_id = 100可以利用索引的第一列进行快速定位。
  2. AND status = 'completed'可以在第一步定位的结果集中，利用索引的第二列进一步过滤。注意：如果查询是WHERE status = 'completed' AND user_id = 100，由于MySQL查询优化器会调整条件顺序，同样可以利用该索引。
  3. ORDER BY created_at DESC由于created_at是索引的第三列，且前两列都是等值查询，所以索引中的数据已经是按照created_at排序好的，可以直接利用索引进行排序，避免了昂贵的文件排序（filesort）操作。

最左前缀原则：如果查询条件不包含复合索引最左边的列，则无法使用该索引。例如，对于索引(user_id, status, created_at)：

• WHERE user_id = 100✅ 可以使用索引（部分）。
• WHERE user_id = 100 AND status = 'completed'✅ 可以使用索引。
• WHERE status = 'completed'❌无法使用该索引。
• WHERE user_id = 100 ORDER BY created_at DESC✅ 可以使用索引（用于查找和排序）。

5.3 索引使用禁忌与建议

1. 避免在索引列上使用函数或计算：WHERE YEAR(created_at) = 2023无法使用created_at上的索引。应改为WHERE created_at >= '2023-01-01' AND created_at < '2024-01-01'。
2. 避免隐式类型转换：如果字段user_id是字符串类型，但查询写WHERE user_id = 100（整数），会发生隐式类型转换，导致索引失效。应确保类型一致。
3. LIKE 查询的通配符位置：WHERE name LIKE '张%'可以使用前缀索引。WHERE name LIKE '%张%'或WHERE name LIKE '%张'则无法使用索引。
4. 定期分析索引使用情况：使用SHOW INDEX FROM table_name查看索引基数，使用EXPLAIN分析慢查询，使用performance_schema或慢查询日志来找出未使用或低效的索引，并进行优化或删除。

6. 表与关系设计：构建清晰的业务地图

表结构是业务模型的直接映射。清晰的关系设计能让复杂的业务逻辑变得直观。

6.1 主键设计：代理主键 vs 自然主键

• 自然主键：使用具有业务含义的字段作为主键，如身份证号、手机号、订单号。优点是直观，且天然具有唯一性约束。缺点是业务规则可能变化（如身份证号升位），且长度可能不规整，影响索引效率和在InnoDB中作为聚集索引的性能。
• 代理主键：使用一个与业务无关的自增数字（如BIGINT AUTO_INCREMENT）或分布式ID（如雪花算法生成的ID）作为主键。这是目前绝大多数场景的推荐做法。优点是与业务解耦，稳定不变；长度固定且较短，索引效率高；特别是对于InnoDB引擎，表数据本身就是按主键顺序组织的，自增主键能保证顺序插入，避免页分裂，提升写入性能。

强烈建议：除非有非常强烈的理由，否则统一使用BIGINT UNSIGNED AUTO_INCREMENT或等价的分布式ID作为所有业务表的主键。同时，为具有业务唯一性的字段（如用户邮箱、手机号）创建唯一索引（UNIQUE KEY）即可。

6.2 外键约束：用还是不用？

在物理数据库层面使用FOREIGN KEY约束，数据库会自动保证引用完整性（Referential Integrity）。任何违反引用关系的操作（如插入不存在的用户ID到订单表）都会被拒绝。

优点：数据一致性由数据库层保证，绝对可靠。缺点：

1. 性能开销：在数据插入、更新、删除时，数据库需要检查约束。
2. 并发问题：可能引发锁等待甚至死锁。
3. 运维复杂性：在数据迁移、分库分表、历史数据清理时，外键约束会带来很多麻烦。

业界趋势与我的建议：在大型互联网应用、微服务架构下，倾向于在应用层（业务代码）保证数据一致性，而不在数据库层使用物理外键。通过清晰的代码逻辑、事务控制和定期数据稽核来维护关系。这给了架构更大的灵活性和可扩展性。但在传统的、业务逻辑相对稳定、对强一致性要求极高的企业级应用（如金融核心系统）中，物理外键仍然是一个重要的安全网。

如果不用物理外键，那么必须在设计文档和代码注释中清晰地说明表与表之间的逻辑关联关系。

6.3 常用字段范式

为了提高效率，可以约定一些所有表都可能需要的通用字段，形成模板：

CREATE TABLE `example_table` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `creator` varchar(64) DEFAULT NULL COMMENT '创建人', `updater` varchar(64) DEFAULT NULL COMMENT '更新人', `is_deleted` tinyint(1) NOT NULL DEFAULT '0' COMMENT '逻辑删除标志: 0-未删除, 1-已删除', -- ... 其他业务字段 ... PRIMARY KEY (`id`), KEY `idx_created_at` (`created_at`), KEY `idx_updated_at` (`updated_at`), KEY `idx_is_deleted` (`is_deleted`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='示例表';

• id：代理主键。
• created_at/updated_at：审计追踪，用于排查问题、数据分析。
• creator/updater：操作人追踪（可根据审计级别决定是否添加）。
• is_deleted：实现逻辑删除，避免物理删除数据导致关联查询失败和历史数据丢失。查询时默认加上WHERE is_deleted = 0。

7. 性能与维护考量：面向未来的设计

设计不能只满足眼前，更要为未来的扩展和维护铺平道路。

7.1 存储引擎选择：InnoDB 是绝对主流

除非有极其特殊的只读、全文搜索需求（考虑 MyISAM），或者需要内存表（MEMORY），否则一律使用 InnoDB。InnoDB 支持事务（ACID）、行级锁、外键约束（虽然可能不用）、崩溃恢复能力，是现代OLTP（在线事务处理）应用的不二之选。

7.2 字符集与排序规则：统一使用 utf8mb4

• 字符集：utf8mb4。这是真正的UTF-8编码，支持存储所有Unicode字符，包括emoji表情。MySQL历史上的utf8其实是“阉割版”的UTF-8，最多只支持3字节字符，遇到4字节的字符（如emoji）会出错。所以，请忘记utf8，只用utf8mb4。
• 排序规则：utf8mb4_unicode_ci。ci表示大小写不敏感（Case-Insensitive）。unicode_ci基于Unicode标准进行排序和比较，能更准确地处理多种语言。对于中文场景，也可以考虑utf8mb4_general_ci，它速度稍快但准确性略低。团队内部统一即可。

7.3 大字段与文本分离

对于TEXT、BLOB这类可能存储大量数据的字段，如果它们不是查询条件，且不经常被SELECT *带出，可以考虑将它们分离到一张扩展表中。这有助于提升主表的查询效率，因为数据库以页（如16KB）为单位读取数据，大字段会使得每页能存储的行数减少，导致查询需要读取更多的页。

示例：文章表articles存储标题、作者、摘要等核心元数据，而文章正文content（LONGTEXT类型）则存放在article_contents表中，通过article_id关联。在列表页查询时，只访问articles表，速度更快。

7.4 分区表与分库分表的提前规划

对于数据量增长极快的表（如日志、交易流水），在设计初期就要考虑数据膨胀问题。

1. 分区表：在单库单表内，根据某个规则（如时间RANGE、哈希HASH）将数据分布到不同的物理文件上。适用于数据量大，但查询通常只涉及某个分区（如按时间查询最近一个月）的场景。注意：分区表不能代替索引，且分区键选择很重要。
2. 分库分表：当单表数据量达到千万甚至亿级，或并发写入极高时，就需要考虑分库分表。这属于架构级调整，成本很高。在设计规范阶段，需要做的是：为未来分片预留可能性。例如，主键不使用自增ID，而使用包含分片信息的分布式ID（如雪花ID）；避免复杂的跨表关联查询，业务上尽量通过一次查询就能定位到具体分片。

8. 设计评审与变更管理：规范落地的保障

再好的规范，如果不执行，也是一纸空文。必须将设计评审流程制度化。

1. 设计文档先行：在动手写CREATE TABLE之前，先撰写简明的设计文档，包括：
   • 表的目的和职责。
   • 字段清单（名称、类型、约束、注释）。
   • 主键、索引设计及理由。
   • 与其他表的关系（逻辑外键）。
   • 预计的数据量、增长速度和主要查询模式。
2. 团队评审：在团队内部或核心开发人员之间进行评审。重点评审：是否符合规范、命名是否清晰、索引是否合理、能否满足查询需求、是否存在过度设计或设计不足。
3. 使用版本化迁移工具：绝对不要直接在线上数据库执行ALTER TABLE。使用Liquibase或Flyway这样的数据库迁移工具。所有的表结构变更（创建、修改、删除）都以版本化的SQL脚本形式存在项目中，随代码一起提交、评审、部署。这保证了所有环境（开发、测试、生产）的数据库结构一致，并且可以追踪每一次变更的历史。
4. 变更回滚方案：任何DDL操作都要考虑回滚。例如，删除一个字段，应该先确保没有代码依赖它，然后通过迁移工具先添加新字段（如果需要），迁移数据，再下线旧字段。工具化的迁移脚本可以方便地编写回滚（rollback）逻辑。

9. 常见问题与避坑指南实录

这里记录了一些我在实际项目中遇到的典型问题和解决方法。

问题1：varchar(255)是万能的吗？不是。虽然255是一个常见的分界线，但盲目使用255会造成浪费。应该根据业务实际最大长度来定义。例如，用户名varchar(50)，邮箱varchar(100)，地址varchar(200)。更精确的长度定义有助于在应用层进行输入验证，也能让数据库优化存储。

问题2：为什么我建了索引，查询还是慢？请按以下步骤排查：

1. 使用EXPLAIN分析SQL，确认是否真的用到了你期望的索引（看key列）。
2. 检查索引是否因为“最左前缀原则”失效。
3. 检查查询条件中的字段是否做了函数计算或类型转换。
4. 检查索引的区分度（基数）。如果索引列的值大量重复，数据库优化器可能会认为全表扫描更快。
5. 检查查询的数据量。即使用了索引，如果需要回表查询大量数据（即索引不能覆盖所有查询字段），性能也可能不佳。考虑使用覆盖索引。

问题3：逻辑删除 (is_deleted) 导致唯一索引冲突怎么办？这是一个经典问题。比如用户表要求邮箱唯一，但用户注销（逻辑删除）后，他的邮箱应该可以被新用户注册。解决方案：创建唯一索引时，将is_deleted条件排除。但MySQL不支持条件索引。变通方案有：

• 方案A：注销时，将唯一字段（如邮箱）修改为一个不可能重复的值，例如original_email_deleted_timestamp。但这改变了原始数据。
• 方案B：不依赖数据库的唯一约束，在应用层实现更复杂的唯一性校验逻辑。例如，查询时判断email = ? AND is_deleted = 0。
• 推荐方案C：使用组合唯一索引，但将is_deleted的非删除状态值固定。例如：

  ALTER TABLE users ADD UNIQUE KEY uk_email_deleted (email, is_deleted);

  对于有效用户，is_deleted始终为0，所以(email, 0)的组合是唯一的。对于已删除用户，可以将is_deleted设置为该用户的主键ID（或其他唯一值），这样(email, user_id)的组合也是唯一的，且不会与有效用户的(email, 0)冲突。这个方案既保证了数据库层的约束，又满足了业务逻辑。

问题4：时间字段到底用DATETIME还是TIMESTAMP？

• 如果业务需要处理1970年以前或2038年以后的日期，或者需要存储一个与时区无关的绝对时间点（例如“合同签订于2023-01-01 08:00:00”，无论在哪看都是这个时间），用DATETIME。
• 如果只需要记录事件发生的时刻，并且需要根据数据库或连接时区自动转换，或者对存储空间敏感，用TIMESTAMP。注意2038年问题，在MySQL 8.0及更新版本中，TIMESTAMP已经支持更宽的范围。
• 最稳妥的建议：在绝大多数业务场景下，统一使用DATETIME，并在应用代码中明确处理时区问题（例如，所有时间都以UTC格式存储和传输）。这样可以避免TIMESTAMP的隐式时区转换带来的困惑。

问题5：如何应对字段后续需要增加长度或修改类型？这是高频操作。规范是：必须通过迁移工具执行。

1. 评估影响：修改varchar长度从50到100，通常是安全的在线操作（MySQL 5.6+支持ALGORITHM=INPLACE）。但修改字段类型（如int改bigint）可能是代价高昂的复制表操作（ALGORITHM=COPY），对于大表会造成长时间锁表。
2. 制定方案：对于大表修改，可能需要使用pt-online-schema-change或gh-ost等第三方工具进行在线无锁变更。
3. 执行与验证：在低峰期操作，并通过迁移工具记录。变更后，立即验证相关业务功能是否正常。

一套好的数据库建表规范，就像一份经过千锤百炼的工程图纸。它不能保证你造出惊世骇俗的建筑，但能最大程度地避免你盖出歪歪扭扭、随时可能倒塌的危房。规范的价值，在项目初期或许不明显，但当团队扩张、业务复杂、数据量激增时，前期在设计上投入的每一分思考，都会在未来的维护性、稳定性和开发效率上得到百倍的回报。最后记住，规范是死的，业务是活的。所有的原则和规则，最终都要服务于清晰表达业务逻辑、保障系统稳定高效运行这个根本目标。在深刻理解原理的基础上，灵活而不失原则地运用规范，才是高级工程师的体现。