数据库设计的常见陷阱：从字段类型到事务边界

一、数据库设计的问题，往往几年后才暴露

数据库设计有一个特殊之处：它的错误通常不会立刻显现。一个字段类型选错了，一个索引建错了，一段事务写宽了，项目照样能跑通、能上线、能通过验收。问题会在数据量增长、并发上升、业务变复杂之后，以性能下降、数据不一致、难以演进的形式慢慢浮现。

到那时再改，代价已经完全不同：既要改结构，又要迁移数据，还要保证线上不中断。所以数据库设计里真正值得警惕的，正是那些「当时看起来没问题、后来才知道有代价」的决策。

这篇文章梳理五类反复出现的数据库设计陷阱：字段类型与字符集、索引误用、软删除的代价、大表的演进、事务边界。它们有一个共同点——都不是语法错误，而是设计偏好；不是「能不能跑」的问题，而是「跑得久不久、改得动不动」的问题。

关于我们的整体工程思路，可以参考 工程与质量保障 与 技术能力。

二、陷阱一：字段类型与字符集

字段类型是最基础的选择，也是最容易被随意对待的地方。

用字符串存一切。 把金额、时间、状态都存成字符串，看起来省事，代价是：无法做数值比较与聚合、无法用数据库原生类型约束取值范围、排序结果不符合预期、索引效率下降。金额建议用定点小数（decimal）而不是浮点，因为浮点存在精度误差，累加后可能对不上账。

长度给得过小或过大。 长度太小的字段，业务一扩展就要改结构；长度给到极大值（例如用最大长度存手机号），既浪费空间，也让索引与约束失去意义。合理的做法是按业务含义选择长度，并留出可预期的余量。

字符集不统一。 同一个库、甚至同一次关联查询涉及的表，如果字符集不一致，可能带来乱码、无法比较、关联效率下降等问题。现代项目通常统一使用支持完整 Unicode 的字符集，避免中途混用。

时区处理随意。 时间字段用本地时间还是 UTC、应用层与数据库层是否一致，如果没约定清楚，跨时区或夏令时场景下就会出现难以排查的偏差。建议统一存储时区，展示时再转换。

这些选择单看都很小，但一旦数据积累起来，修改成本会成倍上升。

三、陷阱二：索引误用

索引不是越多越好，也不是建了就一定被用上。

该建没建。 高频查询的过滤字段、关联字段、排序列没有索引，查询只能全表扫描，数据量一大就明显变慢。最常见的遗漏是关联查询里的外键字段。

建了不该建的。 反过来，给每个字段都建索引也是问题。索引会占用空间，更关键的是每次写入都要同步维护索引，索引越多，写入越慢。低频查询、区分度极低的字段（例如性别、状态只有两三个取值），建索引的收益往往有限。

复合索引顺序错误。 复合索引的字段顺序会影响能否被利用。查询条件与索引顺序不匹配时，索引可能部分生效甚至完全失效。这需要结合实际的查询模式来设计，而不是凭字段名推测。

在索引列上做运算。 对索引列使用函数、类型转换或前导通配符匹配，常常会导致索引失效，退化为全表扫描。这类问题在开发阶段不易察觉，只有在数据量上来后才表现为性能问题。

忽略索引的选择性与基数。 区分度低的列上建单独索引，效果通常不好。判断索引是否值得建，要结合查询频次、区分度与写入代价综合评估，而不是「有查询就加索引」。

索引设计的本质是在读写之间做权衡：读多写少的场景可以多用索引，写入密集的场景要克制。

四、陷阱三：软删除的代价

软删除（用标记位表示「已删除」而不是真正删除记录）在很多项目里是默认做法，因为它保留了数据、便于恢复、也符合审计需求。但它带来几项容易忽略的成本。

每个查询都要带条件。 一旦采用软删除，几乎所有查询都必须加上「未删除」的过滤条件。漏掉一处就可能把已删除的数据查出来，这类问题很难靠肉眼保证，通常需要统一的框架层处理。

唯一约束与统计变复杂。 如果某个字段在业务上要求唯一，软删除后新旧记录共存，唯一约束就会冲突。统计类查询也要记得排除已删除记录，否则数字对不上。

数据持续膨胀。 删除本质上是逻辑操作，物理数据仍在增长。长期下来，表会越来越大，查询与索引的效率都会受影响。

关联数据的一致性。 主记录被逻辑删除后，从属记录如何处理、是否需要级联标记、恢复时如何还原，都需要明确定义，否则会留下悬挂数据。

因此，软删除不是「免费的保险」，而是一项需要配套设计的机制。真正需要审计留痕的场景，更稳妥的做法往往是「删除 + 归档/审计日志」，把当前数据与历史数据分开管理，而不是让历史数据一直躺在主表里。

五、陷阱四：大表的演进

数据量增长是数据库设计必须提前考虑的现实。

分页的性能陷阱。 深分页（翻到很后面的页码）在数据量大时会显著变慢，因为数据库仍需扫描前面的数据。常见的优化思路是基于游标（记上一页的最后一条）而不是偏移量分页，但这对业务接口设计有要求，最好在早期就考虑。

表的拆分与归档。 当单表数据量持续增长，需要考虑按时间或业务维度归档历史数据、或者按某种规则拆分。这些方案一旦上线后补做，往往涉及大量改造；如果设计阶段就预留了分区或归档字段，演进会平滑很多。

结构变更的风险。 大表上做结构变更（加字段、改类型、加索引）可能耗时长、锁表，影响线上服务。因此在设计阶段就应当为「未来会怎么变更」留出空间，例如预留扩展字段、避免把易变信息硬编码进结构。

主键与自增的选择。 自增主键简单高效，但在分库分表或数据合并场景下可能冲突；使用全局唯一标识（如 UUID 类方案）能避免冲突，但可能影响索引的局部性。选择取决于业务是否需要拆分，需要在设计阶段判断。

大表问题的核心是一句话：在数据还少的时候就要为数据变多做准备，因为那时的改动成本最低。

六、陷阱五：事务边界

事务是保证数据一致性的手段，但用不好会带来新的问题。

事务过长。 一个事务里包含多个外部调用（网络请求、消息发送），会导致事务长时间持有锁，并发能力下降，一旦外部调用超时还可能引发连锁等待。合理做法是缩短事务，把外部调用移到事务之外，用补偿或状态机来处理一致性。

在事务里做重活。 事务中执行大批量更新、复杂计算或耗时查询，会拉长锁持有时间。事务应尽量只包含必要的读写。

隔离级别理解不足。 不同隔离级别对应的并发行为不同，可能出现的现象（脏读、不可重复读、幻读）也不同。团队应当明确默认隔离级别及其影响，而不是默认「数据库会处理好一切」。

跨库或跨服务的事务。 当操作跨越多个数据库或服务时，单一事务往往无法覆盖。这时需要引入分布式事务方案或最终一致性设计，例如本地消息表、补偿事务等。这类方案复杂度高，因此在设计阶段就应尽量减少跨边界事务的必要性。

幂等与重试。 网络抖动、超时重试都可能导致同一操作被执行多次。涉及写入的接口应具备幂等能力，把判断放在服务端，而不是依赖调用方不重复。

事务设计的取舍很清晰：一致性要求越高、并发能力越受限，需要结合业务重要性来选择，而不是一味追求强一致或一味追求性能。

七、其他容易忽略的细节

除了上面五类，还有一些细节值得在设计阶段留意：

• 命名与注释：字段与表的命名是否表达了业务含义，是否留下了结构性注释。多年后接手的人，靠的就是这些信息。
• 更新时间与操作人：是否记录创建与更新时间、由谁操作。这些字段在排查问题与审计时非常有用。
• 数值精度与舍入规则：金额、比例等字段的精度与舍入方式要统一，否则对账时会出现难以解释的微小差异。
• 默认值与空值语义：默认值和空值代表什么含义，需要明确。「空」是「未知」还是「不适用」，在业务逻辑里往往含义不同。
• 权限与数据边界：数据行是否需要按组织或用户隔离，这会影响表结构与查询方式的设计。

八、落地建议

如果正在设计或评审一个数据库方案，可以参考以下做法。

1. 先画数据模型，再写代码。 明确实体、关系、主要查询模式，再决定字段与索引。
2. 按业务含义选类型。 金额用定点小数，时间统一时区，状态用受约束的类型，避免「一律用字符串」。
3. 索引跟着查询走。 先列出高频查询，再设计索引，避免凭直觉堆索引。
4. 明确软删除策略。 决定是否软删除、如何处理唯一约束与统计、历史数据如何归档。
5. 为大表预留演进空间。 提前考虑归档字段、分区策略、深分页方式与结构变更的影响。
6. 控制事务边界。 事务内只放必要操作，外部调用移出事务，重要写入保证幂等。
7. 做一次设计评审。 请熟悉该业务与数据库的人一起过一遍，尤其是索引与事务部分。这与代码评审的思路一致，属于低成本的早期把关。

数据库设计是「一次投入、长期受益」的典型环节。多花时间在前期，往往能省下后期数倍的改造与排障成本。完整的交付与质量流程可参考 交付流程。

九、小结

数据库设计里最贵的错误，往往不是当下的语法问题，而是当时看似合理、后来才发现有代价的取舍。字段类型与字符集决定了数据能否被正确使用，索引决定了读写能否平衡，软删除与大表演进决定了系统能否长期运转，事务边界决定了并发与一致性能否兼顾。

这些问题没有一个「标准答案」，取决于业务量级与一致性要求。明智的做法不是追求某种完美设计，而是在设计阶段就把这些取舍摆到台面上，明确记录选择与理由。这样即使将来需要调整，也能清楚地知道当初为什么这么选。相关能力说明可见 软件研发服务 与 常见问题。