数据库设计核心原则与实战：从范式到索引优化

干了十多年后端开发和数据架构相关的工作，我越来越觉得数据库设计是一项“平时不起眼、出事要人命”的硬功夫。很多项目前期跑得飞快，到了数据量上来、业务开始迭代的时候，各种问题就集中爆发了：慢查询、字段不够用、表结构大改、迁移累到崩溃、并发一高就死锁。追根溯源，一大半问题都能落到当初建表时那几个“随手”的决定上。

这篇博文想聊的，就是数据库设计里那些真正重要、而且可以落地执行的原则。我会结合自己踩过的坑、拆解过的项目，以及这些年面试别人和被别人面试时反复出现的数据库设计问题，把从范式设计、命名规范、主键策略、字段类型，到索引设计、事务并发、跨数据库迁移的完整链路讲透。无论你是在做MySQL、Oracle、达梦还是人大金仓，或者正在纠结SQLite、Doris这类特殊场景，这篇内容都能给你一套可以直接拿去用的判断标准。内容偏实战，适合刚入行的开发、写了两三年业务代码想补基础的同学，以及正在做系统重构或者准备数据库相关面试的朋友。

1. 为什么数据库设计如此重要——先看几个翻车现场

1.1 我经历过的三个真实事故

第一个事故是金额字段用了FLOAT。那是一个电商类的结算系统，订单表里的金额字段当时图省事用了FLOAT类型，上线初期数据量小，一切正常。等订单量到了百万级别，对账的时候发现金额对不上，差了几分钱。排查到最后，发现是FLOAT的精度丢失问题——0.1在二进制里是个无限循环小数，存进去再读出来，尾数早就不是原来的样子了。那次事故让我们加班了两周，把所有金额字段全面改成DECIMAL，还写了一堆数据订正脚本。从那以后，我见到谁用FLOAT存钱就跟谁急。

第二个事故是用户表全表都用VARCHAR。有个后台管理系统，设计者为了让“所有字段都能灵活变长”，把用户表里的年龄、性别、状态、甚至创建时间全部定义成了VARCHAR(50)。结果就是：无法按时间范围做高效查询，无法对年龄做数值比较，索引几乎全部失效，每次统计报表都要先把字符串转成数字，性能惨不忍睹。更麻烦的是，下游数据分析系统对接的时候，还得写一堆CAST转换逻辑。设计表结构图一时痛快，后面还债还到哭。

第三个事故是没有外键，全靠应用层维护数据关系。有些团队为了“性能”或者“灵活”，建表时不建外键约束，关联关系全靠代码里保证。结果某次一个定时任务误删了父表数据，子表里的孤儿数据成了“无头冤案”，业务查询结果莫名其妙多出一些脏数据，排查了很久才发现是引用完整性被破坏。你手里的ORM再强，也扛不住有人在数据库客户端里手滑执行了一条DELETE。

1.2 好设计到底在解决什么问题

这三个事故指向的是同一个核心问题：数据库设计不是“把字段填上、把表建出来”这么简单，它是在为未来五年甚至十年的数据生命周期做规划。一份好的表结构设计，至少要同时解决四个问题：

第一是数据一致性。数据不会因为并发操作、异常中断、类型精度等问题出现“不该有的状态”。这靠的是合理的主键约束、外键约束、唯一约束、非空约束，以及事务隔离级别的正确选择。

第二是查询性能。同样的业务查询，在结构合理的库上可能就是几十毫秒，在结构混乱的库上可能就是几十秒。字段类型、索引设计、表关联方式，直接决定了SQL执行计划的走向。

第三是可维护性。项目总有人员更替，三个月后接手的人能不能一眼看懂这张表是干什么的、字段什么含义？命名规范、注释、统一的约定，看起来是小事，实际上决定了团队协作效率。

第四是可扩展性。业务一定会变，字段一定会加。好的设计能在需求变化时通过增量方式演进，而不是动不动就重建表、全量迁移数据。

常见的误区是把“数据库设计”等同于“ORM建实体类”或者“写建表语句”。真正专业的设计是从业务需求出发，先梳理实体与关系，再设计字段结构，最后才是落实到具体的数据库产品。很多人在第一步就跳过了，直接在代码里new一个Entity，让ORM框架自动建表——这样搞出来的库，基本就是随缘设计。

2. 数据库设计的核心原则，逐条拆解

2.1 范式设计：3NF打底，反范式是权衡不是偷懒

范式（Normal Form）是关系型数据库设计的理论基础，但实际工作中没人会跟你念教科书。你需要掌握的是1NF、2NF、3NF的区别，以及什么时候该反范式。

1NF要求字段不可再分，这个基本都满足，不再多说。2NF要求非主键字段完全依赖主键，不能只依赖主键的一部分——这主要针对联合主键的场景。例如选课表（学号，课程号，成绩，学生姓名），学生姓名只依赖学号，不依赖课程号，这就存在部分依赖，应该拆成学生表和选课表两张表。

3NF是工程上最常用的标准，要求非主键字段之间不能存在传递依赖。比如订单表里有（订单ID，客户ID，客户姓名，客户地址），客户姓名和客户地址其实都依赖客户ID，而不是直接依赖订单ID。如果客户改了地址，订单表里的地址不会跟着变，就会产生数据不一致。正确做法是拆出客户表，订单表只保留客户ID。

但实际项目里，完全不违反3NF的设计也很少。最典型的就是冗余字段：订单表里故意冗余一个“商品名称快照”，因为商品名称可能被商家修改，而你希望订单历史记录里保留用户下单那一刻的名称。这个冗余是业务需求驱动的，属于合理的反范式设计。关键在于，你要能说清楚“为什么这个地方要冗余”，而不是因为“懒得拆表所以都放一起”。

提示：判断反范式是否合理，就问你一句话——这个冗余字段如果变了，业务上能不能接受不一致？订单快照可以接受，用户的实时等级就不能接受。

2.2 命名规范：一套能坚持十年的命名约定

命名规范这些年我被问过很多次，也踩过不少坑。最糟心的是接手一个库，表名一会儿用单数一会儿用复数，一会儿驼峰一会儿下划线，字段名缩写毫无规律，有的叫uid，有的叫user_id，有的叫userId。这种表结构，神仙来了也得先花三天摸清家底。

我推荐一套在多个项目里验证过、比较靠谱的命名约定：

• 表名使用复数还是单数都可以，但团队必须统一。我个人习惯用单数，比如user、order，因为ORM映射类名时不用额外处理。如果你偏爱复数，users、orders也没问题，关键是统一。
• 一律使用小写字母加下划线（snake_case），不要用驼峰，因为MySQL在Linux下对表名大小写敏感，Windows下不敏感，同一套代码在两个环境里跑，容易出诡异问题。
• 表名建议加业务前缀或模块前缀，比如sys_user、biz_order、log_operate。一个中大型系统有上百张表，不加前缀的话，光看名字很难区分是核心业务表还是系统配置表。
• 字段名要自解释，别用a、b、temp这类无意义命名。表示时间的字段统一用create_time、update_time，表示状态用status，表示类型的用type，全库统一。
• 布尔字段推荐用is_前缀，比如is_deleted、is_enabled，配合TINYINT(1)使用，各ORM框架都认识这种命名。
• 外键字段建议是“关联表名_关联字段名”，比如user_id、order_id。这样一看就知道它是外键，关联的是哪张表的哪个字段。
• 每个表和每个字段都必须写注释。MySQL的COMMENT语法支持得很完善，建表时顺手写上，后面能省无数沟通成本。

这套规范本身不复杂，难的是团队所有人都遵守。建议把命名规范写进团队开发手册，并在Code Review阶段坚持检查。数据库表结构一旦上线，改名成本极高，所以宁可建表前多花十分钟确认命名，也别上线后再纠结。

2.3 主键与外键策略：选错主键后面全是泪

主键选型是数据库设计里决策成本最高、改造成本也最高的问题。常见的方案有自增主键、UUID、雪花ID和业务主键，我把它们的适用场景整理一下：

我先说结论：大多数中小型项目，老老实实用自增主键就够了。别为了“以后可能分库分表”提前上雪花ID，那属于过度设计。等业务量真的到了需要分库分表的那一天，再做ID改造也不迟，而且到那时候大概率会有更成熟的中间件帮你处理。

再说业务主键，这个我强烈建议谨慎。有人觉得身份证号、手机号这种天然唯一的字段可以直接当主键，省得再加一个冗余ID。但实际上，手机号可以换、身份证号涉及隐私不能明文存储、用户的业务标识可能会随规则调整而变化。一旦业务主键变化，所有关联表都要跟着改，牵一发动全身。正确做法是保留一个无意义的自增主键作为内部标识，同时给手机号、身份证号这类字段建立唯一索引。

外键的问题要分开看。在OLTP（在线事务处理）系统里，我建议适度使用外键约束，尤其是在核心业务表之间。外键约束确实会带来一点性能开销，但它能保证数据一致性，防止应用层逻辑出现漏洞时产生脏数据。在OLAP（在线分析处理）或大数据量写入的场景下，外键约束带来的写入开销会被放大，这时可以用应用层逻辑代替外键，但必须有配套的定期数据质量检查机制。

2.4 数据类型选择：字段类型决定了存储和索引效率

数据类型选择的本质是：在保证业务需求的前提下，用最紧凑的类型存储数据，同时保证运算效率。很多人建表时无脑用VARCHAR(255)或者BIGINT，这也是一种懒。给一个字段选类型，背后其实是在做存储成本和查询效率的权衡。

整数类型按取值范围选就行：状态、类型、开关用TINYINT（0-255），年龄、数量、小范围统计用INT，订单号、雪花ID、大表主键用BIGINT。要特别小心INT和BIGINT的隐式坑：如果应用层用Long类型接收了一个INT字段，某些ORM框架在插入时会自动转成BIGINT，但如果两边元数据不一致，查询时就可能发生隐式类型转换，导致索引失效。

小数问题我只想说一句：金额一律用DECIMAL，别用FLOAT或DOUBLE。DECIMAL是定点数，精度可控，适合货币、利率、百分比等精确计算场景。FLOAT/DOUBLE适合科学计算，但在金额上就是灾难。

字符串类型要区分CHAR、VARCHAR和TEXT。CHAR适合定长字符串，比如手机号、身份证号（但身份证号建议密文存储）、固定状态码；VARCHAR适合变长字符串，注意要设置合理的最大长度，不要一上来就VARCHAR(5000)；TEXT类型不要直接当普通字段用，因为它不能有默认值、索引效率低，而且大字段放主表里会拖慢全表扫描。如果确实要存大文本，考虑拆到单独的表，或者干脆用文件存储、数据库只存路径。

时间类型在MySQL里主要是DATETIME和TIMESTAMP的选择。DATETIME不依赖时区，存的是字面值；TIMESTAMP依赖时区，范围到2038年。我建议大部分业务场景用DATETIME，配合应用层统一用UTC时间存储、展示层转本地时间，这样跨时区不会出问题。另外，所有表都建议加create_time和update_time两个审计字段，MySQL 5.6以上可以设置DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP来自动维护。

3. 从需求到表结构：一套可落地的五步设计流程

3.1 第一步：把业务规则问透

这一步经常被跳过的原因是：开发人员觉得需求文档都写清楚了，“不就是几张表嘛”。但实际上，数据库设计阶段多问一个问题，后面就能少改一次表。设计表结构前，你必须搞清楚这些业务规则：

• 这个实体的核心属性有哪些？哪些是创建后不可变的？哪些会频繁更新？
• 属性之间是否存在依赖关系？比如收货地址是否依赖用户？订单是否依赖商品？
• 是否存在一对多、多对多的关系？中间表需要记录哪些附加信息？
• 数据量预估是多少？未来一年、三年大概什么量级？
• 哪些查询是高频的？查询条件是什么？排序字段是什么？
• 哪些数据只需要保留最新的，哪些需要保留全量历史？

举个实际场景：设计一个订单系统。如果只问“订单有哪些字段”，你会得到一份很粗的字段清单。但如果你追问“订单状态经历了哪些状态流转”“订单和商品的关系是下单时确定还是发货时确定”“用户修改收货地址是否影响历史订单”，你就能发现订单需要状态机字段、需要商品快照字段、需要独立的收货地址快照。这些都是在需求沟通阶段就能预判到的设计决策。

3.2 第二步：实体与关系建模，核心是找到业务中的“名词”

实体识别的核心是梳理业务流程中的名词。用户、订单、商品、支付单、发票、优惠券、库存、物流单，这些都是候选实体。然后梳理它们之间的关系。

一对多关系最简单，比如一个用户有多个订单——“多”的一方加外键user_id。多对多关系需要一个中间表，比如“用户和角色”就是典型的多对多，中间表叫user_role，里面放user_id和role_id，额外还可以放create_time。一对一关系在业务上比较少见，通常是出于性能或安全考虑，把不常访问的大字段或者敏感字段拆到独立的表里，比如user_profile和user_credential。

这里要特别提醒：不要为了“省表”把多对多关系硬塞进两个表。我见过有人把用户拥有的多个角色直接拼成一个逗号分隔的VARCHAR字段，比如roles = "1,2,3"。表面上看省了一张中间表，但查询时无法用索引匹配单个角色，更新时还要先读后写再拼接字符串，并发操作时还会互相覆盖。这就是典型的“设计时省事、维护时遭罪”。

3.3 第三步：字段级设计，该冗余的快照必须冗余

实体和关系定了之后，就是字段级设计。这个阶段核心是检查每个字段是否满足三方面要求：含义清晰、类型合适、默认值合理。

关于默认值：能用NOT NULL DEFAULT就尽量不用NULL。NULL在SQL里是个很麻烦的东西，聚合函数会忽略它，索引处理效率低，ORM映射时容易出NPE，而且业务含义不明确——到底是“没有值”还是“值为空”？比如remark字段，如果绝大多数订单没有备注，可以设计成remark VARCHAR(500) NOT NULL DEFAULT ''，这样既满足业务需求，又避免了NULL带来的各种问题。

还有一个容易忽略的点：冗余快照字段。订单系统里，用户下单时看到的商品名称、单价、优惠金额，都应该在订单明细表里冗余一份。这是因为商品信息、价格策略随时可能调整，而订单是历史事实，不应该随商品主数据的变化而变化。从3NF角度看，这是违反范式的，但从业务角度看，这是必要的。这类字段的命名建议带上“快照”语义，比如goods_name_snapshot、price_snapshot，让后续维护的人一眼就知道它的用途。

3.4 第四步：评审与反推，用真实SQL验证设计

字段设计完了，不要急着写CREATE TABLE，先拿真实的业务查询去反推一遍设计。你可以列出系统里最高频的5个查询，比如“查询某个用户最近的20笔订单”“统计某个商品某个月的销量”等，然后手写SQL，看这些SQL能不能在两三张表以内完成、能不能走索引、有没有隐式类型转换。

举个例子，如果“按订单状态分组统计金额”是高频查询，而订单表的status字段是VARCHAR且存的是中文状态名，那这个字段要么改成TINYINT存状态码，要么干脆拆成状态码和状态描述两个字段。再比如“查询某时间段内创建的订单”，你就要确认create_time字段是不是DATETIME类型，有没有建索引，不能依赖VARCHAR的时间字符串做范围比较。

这个评审环节能提前发现很多设计缺陷，而且成本极低——你只是花半小时写几条SQL，而不是等系统上线后花几天做数据订正。

3.5 第五步：上线后的持续演进，用版本化管理表结构

数据库设计和代码一样，不可能一次做对，关键在于后续演进要有章法。我强烈建议团队引入数据库迁移工具，比如Flyway或Liquibase，用版本化脚本管理所有表结构变更。

这样做的三个直接好处：第一，每次变更都有记录，可以追溯“这张表为什么加了那个字段”；第二，团队多人协作时，不会出现“你的本地表结构和我的不一样”的问题；第三，发版时可以自动执行增量脚本，降低上线操作风险。很多人图省事，直接在数据库客户端里手动ALTER TABLE，改完也不记录，等到了生产环境发现忘了执行、或者执行顺序错了，又得花大量时间排查。用迁移工具虽然是“多一道工序”，但从长期来看是稳赚不赔的。

注意：任何生产环境的表结构变更，绝对不要在高峰期直接执行。尤其是ALTER TABLE在MySQL 5.7以下版本会锁表，即使5.7以上用了Online DDL，也建议在低峰期操作，并提前备份。

4. 索引设计：性能好不好的关键在索引，不在SQL

4.1 索引必须有的放矢，不是越多越好

很多人的索引设计思路是“把查询涉及到的字段都建上索引”，结果一张表建了十几个索引，写入性能严重下降，每个索引还占着几倍的磁盘空间。实际上，索引设计的第一步是做减法——每个索引都要有明确的“服务对象”。

索引最核心的价值是加速查询的定位过程。在决定给哪些字段建索引时，你应该问自己：这个字段在WHERE条件里出现频率高吗？是不是ORDER BY或GROUP BY的字段？是不是JOIN的关联字段？这三个问题的答案决定了一个字段是否值得建索引。而对于区分度很低的字段，比如性别、状态（只有几个固定值），除非是组合索引的前缀字段，否则单独建索引几乎没意义——比如你要在100万行里查“男性用户”，可能返回50万行，走索引还不如全表扫描快，优化器不会选择走这种索引。

我建议给索引建立一套命名规范，比如idx_表名_字段名表示普通索引、uk_表名_字段名表示唯一索引。这样在查看执行计划或者排查慢查询时，看一眼索引名字就知道它的类型和作用。

4.2 联合索引的最左前缀原则，以及字段顺序怎么排

联合索引（a, b, c）听起来是给三个字段各建了一个索引，其实它是按照(a)、(a, b)、(a, c)、(a, b, c)的顺序来支持查询的，这就是最左前缀原则。也就是说，只有查询条件里包含了a，或者同时包含a和b，才能走到这个联合索引。如果跳过a直接查b或c，这个索引就用不上。

所以联合索引的字段顺序排列有一个核心经验：优先把等值查询的字段放在前面，把范围查询（>、<、BETWEEN）的字段放在后面。因为联合索引在遇到范围查询后，后面的字段就无法用于索引定位了。举个例子，索引(a, b)，查询条件是a = 1 AND b > 2，a能走索引等值匹配，b只能做索引扫描后的过滤；但如果索引是(b, a)，查询条件a = 1 AND b > 2`时，b走范围，a反而用不上了。

另外有一个很实用的小技巧：如果某个高频查询只需要返回少量字段，你可以把这些字段加进联合索引里，做一个“覆盖索引”，让查询完全不用回表。比如订单表上有一个高频查询是“按用户ID查订单金额”，建索引(user_id, amount)后，这个查询可以完全在索引里拿到数据，省掉回表访问主表的那一次IO。这就是所谓的用空间换时间，在实际项目里收益很明显。

4.3 索引失效的常见场景，踩一次就够你记一辈子

就算索引建了，SQL写得不对，照样走不上索引。我在项目里踩过最经典的几个坑：

第一个是隐式类型转换。比如user_id字段是VARCHAR，但查询条件写的是WHERE user_id = 123（数字），MySQL会先把字段转成数字再比较，导致索引失效。反过来如果是把数字参数转成字符串，那索引可能还好。这种问题在联调阶段往往测不出来，因为数据量小，等生产数据大了才露馅。

第二个是前导通配符。LIKE '%关键词'这种写法，因为不知道匹配前缀，索引用不上。解决办法是改用全文索引或者ES；如果数据量不大的话，LIKE '关键词%'是可以走索引的。

第三个是对索引字段使用函数。比如WHERE DATE(create_time) = '2024-01-01'，你在字段上套了函数，索引就失效了。正确写法是WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，这样既能走索引，语义也更清晰。

4.4 一次真实的索引优化案例

有一次我在优化一个后台报表接口，查询条件是“按部门、时间段统计订单金额”，初始SQL跑了三秒多。EXPLAIN一看，核心订单表走了全表扫描。原来的索引只有主键和order_no唯一索引，而查询条件是dept_id和create_time。我的调整是：新建一个联合索引(dept_id, create_time)，把范围条件字段放在第二位。结果查询时间从三秒降到了八十毫秒，接口整体响应时间降了一个量级。

这类优化的核心其实是先看执行计划，再看索引设计。别拿SQL层面能改一个子句来糊弄，你要通过EXPLAIN看清它现在的执行路径是什么，然后设计一个能让优化器“高概率选中的路”。

5. 并发与事务设计：多用户环境下的稳定性怎么保证

5.1 事务隔离级别，选错了怎么死的都不知道

关系型数据库的ACID里，I代表隔离性。SQL标准定义了四个隔离级别：读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）、可重复读（REPEATABLE READ）、串行化（SERIALIZABLE）。隔离级别越低，并发能力越强，但脏读、不可重复读、幻读这些异常就越多。

MySQL默认是REPEATABLE READ，PostgreSQL和Oracle默认是READ COMMITTED，这个差异很多人不知道，跨库迁移时特别容易踩坑。在REPEATABLE READ下，同一个事务里多次读取同一行，结果是一致的，这对业务逻辑有好处，但也意味着锁的持有时间更长、死锁的几率更高。

实际的选型建议很直接：绝大多数业务系统，用READ COMMITTED就够用了。它能避免脏读，读到的都是已提交的数据，事务内的多次读取可能会不一致，但只要你的业务对“同一事务内两次读的结果一致”没有硬性要求，READ COMMITTED带来的并发性能收益更划算。只有资金类、库存类等强一致场景，才需要把关键事务提高到REPEATABLE READ或使用SELECT FOR UPDATE显式加锁。

5.2 死锁是怎么产生的，以及怎么避免

死锁是数据库并发场景里最常见的“隐形杀手”。核心原因是两个事务各自持有一把锁，同时又在等对方手里的锁，形成循环等待，谁也走不下去。

最经典的生产案例是：事务A先UPDATE订单表再UPDATE库存表，事务B先UPDATE库存表再UPDATE订单表。如果两个事务同时提交，就可能死锁。遇到这个问题的第一反应不是“加大锁超时时间”，而是统一加锁顺序——所有事务都先操作订单表再操作库存表，死锁的触发条件就消失了。

第二个常见原因是事务太长。一个事务里做了几十步操作，锁覆盖的行范围越来越大，遇到其他事务的概率自然飙升。解决思路是尽量缩小事务边界，把无关操作全部移出事务，只在真正需要保证一致性的几行操作上开启事务。

第三个是隔离级别导致的范围锁。在REPEATABLE READ下，MySQL的InnoDB会使用间隙锁（Gap Lock）来防止幻读，这在范围查询时会锁住一些并不存在的记录，更容易引起阻塞和死锁。如果业务对幻读不敏感，把隔离级别降到READ COMMITTED能显著降低死锁概率。

5.3 连接池配置的几个关键参数，别再默认走天下了

数据库连接池是应用和数据库之间的桥梁，配置是否合理直接影响系统的稳定性。现在Java生态最常用的是HikariCP，它的默认参数在多数场景下表现不错，但你也得知道它关键参数的含义。

maximum-pool-size是最大连接数，不是越大越好。每个连接在数据库端都是一条线程、一块内存，连接分配太多，数据库反而先扛不住。业界一个经验公式是：核心数乘以2加磁盘数，比如8核机器，建议16个左右的最大连接数。这个值要结合应用实际并发量和数据库规格来调，不能照搬。

minimum-idle是最小空闲连接数，建议和最大值保持一致，避免频繁创建销毁连接。connection-timeout是获取连接的超时时间，默认30秒有点长，改成3到5秒更合理，否则在高并发时，应用线程会长时间卡在等待连接上，积压越来越多。max-lifetime是连接最大存活时间，默认30分钟，建议比数据库的wait_timeout短一些，防止连接被数据库端回收后，应用还在使用已经失效的连接。

拿一个真实案例说话：有个系统偶尔报“Connection is not available, request timed out”，业务高峰期一过又恢复正常。排查后发现是连接池最大值配成了10，但应用高峰期的并发请求超过了20，大量线程在等待连接。后来把maximum-pool-size调到20，并加了监控报警，问题就消失了。这类问题不是SQL慢，也不是数据库挂了，纯粹是连接池配置不合理。

6. 不同数据库环境下的设计差异与迁移注意点

6.1 MySQL、PostgreSQL、Oracle、SQLite，设计时有哪些不同

很多人以为一套表结构设计能通吃所有数据库，实际上每个数据库都有自己的“脾气”。

MySQL是最常用的，InnoDB引擎支持事务和行级锁，设计时要注意它默认的字符集排序规则、大小写敏感的差异。Linux下MySQL的表名区分大小写，Windows下不区分，跨平台部署时要统一用小写表名。另外MySQL没有真正意义上的“序列”，自增主键用AUTO_INCREMENT实现，批量插入时要注意自增步长和缓存设置。

PostgreSQL在数据类型上比MySQL丰富得多，有原生JSONB、数组类型、范围类型，而且在约束和索引方面更强大，支持部分索引、表达式索引。如果一个项目有很多复杂查询和地理空间数据，PostgreSQL会是比MySQL更合适的选择。设计时需要转换一个惯性思维：MySQL里用TINYINT存布尔值，PostgreSQL可以直接用BOOLEAN类型；MySQL里为了性能经常做冗余字段，PostgreSQL里可以通过视图或物化视图来解耦。

Oracle是老牌企业级数据库，设计上对序列（SEQUENCE）、同义词、分区表的支持非常完善。它的VARCHAR2最大长度是4000字节（12c之后扩展了），和MySQL的VARCHAR行为有差异。Oracle默认排序是按照二进制值来的，中文字段排序和MySQL不太一样，做系统迁移时需要注意。

SQLite则是嵌入式数据库的代表，不需要独立服务，一个文件就是整个库。它适合做桌面工具、移动端本地存储、嵌入式设备，但它并发写性能较弱，锁粒度和MySQL完全不同。设计时要注意：SQLite对ALTER TABLE的支持很有限，改字段类型可能得重建整张表。

6.2 国产数据库（达梦、人大金仓）的兼容性问题，越来越不能忽视

最近几年国产数据库的使用频率明显上升，达梦数据库和人大金仓数据库在很多政企和金融项目中已经成了标配。它们都做了Oracle兼容模式或MySQL兼容模式，但兼容不等于完全一致，设计时还是要注意几个典型差异点。

达梦数据库的SQL语法接近Oracle，支持包、存储过程、序列等，但如果你的应用是给MySQL写的，迁移到达梦时千万不能直接导入建表脚本。字段类型映射要逐个检查：MySQL的AUTO_INCREMENT要改成达梦的IDENTITY或序列，TINYINT(1)在达梦里可能被解析成数值类型，会影响ORM的判断。字符串拼接语法从CONCAT换成||，分页写法也要改成ROWNUM或者达梦自己的分页语法。

人大金仓（KingbaseES）兼容PostgreSQL和Oracle两种模式，但在使用之前一定要确认当前建库时选的是哪种兼容模式，因为这会影响大小写敏感性和系统视图的名字。金仓在一些高级功能上，比如物化视图的自动刷新、外部表JSON解析，表现不如原生PostgreSQL丰富。设计阶段如果目标就是国产数据库，建议先下载试用版，把核心表的DDL和关键查询在目标数据库上真实跑一遍，不要想当然地以为“文档说兼容就没问题”。

6.3 数据迁移时容易踩的五个坑

无论从MySQL迁到PostgreSQL、Oracle迁到达梦，还是老系统重构后迁到新库，数据迁移都是高风险操作。我总结这些年经历过的常见坑：

第一是类型映射不完整。MySQL的DATETIME迁到Oracle就变成DATE，精度和时区行为有差异。TINYINT(1)迁到PostgreSQL，可能被映射成SMALLINT，导致应用层拿到的类型不对。迁移前要列一个完整的字段类型映射表。

第二是字符集与排序规则不一致。源库是UTF8MB4，目标库是UTF8，遇到生僻字或者特殊Emoji字符，数据就丢了。迁移前检查源库和目标库的字符集，最好都统一成UTF8MB4。

第三是自增主键的步进冲突。MySQL的AUTO_INCREMENT迁移到Oracle需要重建序列，而且要把序列的起始值设置成源表当前最大值加一，否则插入新数据时主键冲突。

第四是数据校验缺失。迁移完成后要抽样验证数据量、关键字段的分布值，不能只看看行数对得上就完事。建议写一套对比脚本，分别在源库和目标库执行，比对关键业务表的记录数、SUM值、COUNT DISTINCT值。

第五是回滚方案缺失。迁移脚本要在测试环境完整演练，生产迁移前必须保留源库的物理备份或逻辑备份。一旦迁移后出现严重问题，要能快速回滚到源库，而不是在目标库里边查边修。

7. 常见设计问题排查与设计自检清单

7.1 慢查询背后的设计缺陷，怎么一步步定位

慢查询是数据库设计问题的直接体现。我的排查思路是“先看执行计划，再看表结构，最后看SQL写法”。

先用EXPLAIN SELECT ...看一眼执行计划，重点关注type列。如果看到ALL（全表扫描）或者type为index（全索引扫描），说明索引设计或者查询条件有问题。再看key列，如果明明有索引但没走，说明有隐式类型转换或者这个查询不适合用当前索引。最后看rows列，它表示预计扫描的行数，如果扫描行数和返回行数差距在一个数量级以上，大概率是索引选择不对或者说“设计时就缺一个复合索引”。

排查到这里，下一步是分析这条SQL对应的业务逻辑，反推表结构设计。比如“为什么查询用户订单要关联三张表？”“为什么日期条件要CAST一下才能比？”这些问题往往暴露的是表设计阶段的字段类型、关联方式、索引规划这些问题。SQL层面能做的优化有限，真正有效的优化往往要落到表结构上。

7.2 一个数据库设计自检清单，建表前逐条过一遍

我把这些年的经验沉淀成一份表结构设计自检清单，每次设计新表或者评审别人的建表脚本时，都会拿着它逐条核对：

7.3 最后再分享一个实际经验：设计评审不能省

很多人觉得设计评审是走形式，浪费时间。但我可以明确告诉各位，数据库设计的评审是所有评审里性价比最高的一环。一次一小时的评审，可能就帮你避开了上线后的一个通宵。而且参加评审的人里，总有一两个能问出你从没想过的问题，比如“这个状态字段未来会不会多一种调度状态？”“这个冗余字段在退货流程里需不需要更新？”这些问题在业务设计阶段容易被忽略，但在评审阶段被提出来，修改成本几乎为零。

如果你是一个人在写个人项目，没有评审伙伴，那就把自检清单自己过一遍，然后模拟三天后的自己来审查这张表：如果你拿到这张表，要理解每个字段的含义，需要花多少时间？如果要做一次新需求改造，这张表要动多少地方？这些问题一问，你自然会发现设计里的不足之处。

我在实际工作中见过太多因为一开始图省事、后面花几倍时间补债的案例。数据库设计确实是个“前期多花一小时、后期省一百小时”的领域。把它当成一门手艺来对待，每次设计完都做一次复盘，你会发现自己的判断力越来越准，出的表结构也越来越稳。希望这篇内容能帮你在设计新表的时候少踩几个坑，也欢迎你把自检清单直接拿去用，有需要调整的地方按自己团队的情况改就是。