3mysql 六大约束和三大范式

六大约束

• 默认约束
• 非空约束 NOT NULL
• 主键约束
• 外键约束
• CHECK约束 mysql不支持
• UNIQUE约束

三大范式

• 属性的原子性 字段内容不可再分解
• 记录的唯一性 字段与字段之间不可存在部份依赖（学分依赖课程号，姓名依赖与学号）
• 字段的冗余性 一个字段不可由其他字段推算出来

表设计中忘记范式的原则

使用 BIGINT 的自增类型作为主键的设计仅仅适合非核心业务表，比如告警表、日志表等。真正的核心业务表，一定不要用自增键做主键，主要有 6 个原因：

• 自增存在回溯问题；
• 自增值在服务器端产生，存在并发性能问题；
• 自增值做主键，只能在当前实例中保证唯一，不能保证全局唯一；
• 公开数据值，容易引发安全问题，例如知道地址http://www.example.com/User/10/，很容猜出 User 有 11、12 依次类推的值，容易引发数据泄露；
• MGR（MySQL Group Replication） 可能引起的性能问题；
• 分布式架构设计问题。

推荐使用uuid作为主键
不过uuid是以时间低位为首，所以前四位会发生随机的变化，并非单调递增。而非随机值在插入时会产生离散 IO，从而产生性能瓶颈。这也是 UUID 对比自增值最大的弊端。
MYSQL8.0以后出现了uuid-to-bin，实现以高位为首
优点：

• 以高位为首，没有离散io，性能提高了
• 删减了-分隔符
• 用二进制存储，存储空间由36字节（ e0ea12d4-6473-11eb-943c-00155dbaa39d）变为16字节（ 0x11EB6473E0EA12D4943C00155DBAA39D ）

分布式数据库架构，仅用 UUID 做主键依然是不够的。业务上建议在耦合一些业务相关的信息以及一个随机码。

数据库表设计：

• 每张表一定要有一个主键；
• 自增主键只推荐用在非核心业务表，甚至应避免使用；
• 核心业务表推荐使用 UUID 或业务自定义主键；
• 一份数据应尽可能保留一份，通过主键关联进行查询，避免冗余数据；
• 在一些场景下，可以通过 JSON 数据类型进行反范式设计，提升存储效率；