分库分表
分库原则
垂直分库
垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。
它带来的提升是：
-
解决业务层面的耦合，业务清晰
-
能对不同业务的数据进行分级管理、维护、监控、扩展等
-
高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈
垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题。
水平分库
水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
它带来的提升是：
- 解决了单库大数据，高并发的性能瓶颈。
- 提高了系统的稳定性及可用性。
分表原则
垂直分表
可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失。
水品分表
可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。
设计
表设计
范式
1NF：原子性。 字段不可再分,否则就不是关系数据库;；
2NF：唯一性 。一个表只说明一个事物；
3NF：每列都与主键有直接关系，不存在传递依赖。
全局设计
- 数据库级别不设计默认值
- 业务表不做代码值、代码名称此类简单冗余
- 禁止使用触发器
- 必须做增量设计
- 增量设计不规范。请参照《数据增量设计说明书》进行改造
- 不允许存在逻辑删除标志位
- 设计逻辑外键，必须定义索引
- 表必须有主键或唯一约束
- abase表中必须有主键 因GP特性为：若表设计中存在物理主键或唯一约束，则分布键必须包含对应主键或唯一约束列。所以在特定环境下，可以不设置物理主键或唯一约束 sybase ase表中主键必须为“唯一约束+非聚簇索引”，不能存在聚簇索引
- OLTP系统，任意表最大列数不能超过80
- 多级子表逻辑外键设计要求
- 一级子表要有主表的逻辑外键 二级子表要有主表、一级子表逻辑外键 三级子表要有主表、一级子表、二级子表逻辑外键 依次类推
- 超大表建议考虑拆表
- 大表（业务数据预估超过500W（ABase）、200W（ASE））考虑拆表，视具体业务和架构师讨论决定
- 同一表禁止双向复制
- 使用JSONB类型存储JSON数据
冗余设计
数据库冗余，比较典型的是两个表关联的时候，是设置外键ID来查找name，还是直接设置name。
当外键关联表的数据可预计的，少量的时候可以是设置ID。当外键关联表数据是膨胀的，非常多的，直接设置name吧。
主要从join的性能来考虑找个问题。
冗余设计会有可能3NF。
字段设计
- 对于长度小于10位的数值字段应使用integer
- 大于10位的使用number或者numeric
- 金额使用元为单位，使用number(20, 4)存储
- 文本字段设计
- 主键vc32
- 但是代码vc100
- 其他字段设计为 VC300/VC600/VC900
- 超过900的使用text
- 如果使用LOB存储结构化数据，应该与业务数据分开，设计单独表存储；不宜在数据库中存储非结构化数据。
增量设计
每张表必须增加添加：创建时间、最后修改时间、最后修改方式字段。
主键生成规则
外键设计
设计逻辑外键，并加索引
索引设计
- 索引类型
- b-tree 对大多数查询和不同的数据类型使用这个索引
- hash 用于相等运算符
- gin, 倒排索引，用于文档和数组以及json
- gist, 用于全文检索
- BRIN: 用于非常大的顺序排列数据集
- 索引代价
- 更新数据变慢
- 空间占用
- 无法针对索引指端使用hot更新
- 好处
- 索引膨胀
- 索引使用
- 三星索引
触发器和存储过程
-
不适用触发器
-
谨慎使用存储过程
- 存储过程不适用集群部署的数据库系统
- 数据库压力可能过大