目录
一、为什么需要数据库设计
一、糟糕数据库和良好数据库的区别
如果是糟糕的数据库设计可能会造成以下问题
- 数据冗余、信息重复,存储空间浪费
- 数据更新、插入、删除的异常
- 无法正确表示信息
- 丢失有效信息
- 程序性能差
良好的数据库设计则有以下优点
- 节省数据的存储空间
- 能够保证数据的完整性
- 方便进行数据库应用系统的开发
总之,开始设置数据库的时候,我们就需要重视数据表的设计。为了建立 冗余较小、结构合理 的数据库,设计数据库时必须遵循一定的规则。
二、数据库的设计
二、范式
1、范式中键相关的概念
- 超键: 能唯一标识元组的属性集叫做超键
- 候选键:如果超键不包括多余的属性,那么这个超键就是候选键
- 主键:用户可以从候选键中选择一个作为主键
- 外键:如果数据表 R1中的某属性集不是 R1 的主键,而是另一个数据表 R2 的主键,那么据表 R1 的外键。
- 主属性:包含在任一候选键中的属性称为主届性。
- 非主属性: 与主属性相对,指的是不包含在任何一个候选键中的属性。
通常,我们也将候选键称之为“码”,把主键也称为“主码”。因为键可能是由多个属性组成的,针对单个属性,我们还可以用主属性和非主属性来进行区分。
2、第一范式(1st NF)
- 第一范式主要是确保数据表中每个字段的值必须具有 原子性,也就是说数据表中每个字段的值为 不可再次拆分的最小数据单元。
- 我们在设计某个字段的时候,对于字段 X 来说,不能把字段 X拆分成字段 X-1 和字段 X-2。事实上,任何 DBMS都会满足第一范式的要求,不会将字段进行拆分。
3、第二范式(2nd NF)
- 第二范式要求,在满足第一范式的基础上,还要满足数据表里的每一条数据记录,都是可唯一标识的。而且所有非主键字段,都必须完全依赖主键,不能只依赖主键的一部分。如果知道主键的所有属性的值,就可以检索到任何元组(行)的任何属性的任何值。
- (要求中的主键,其实可以拓展替换为候选键)
4、第三范式(3rd NF)
- 第三范式是在第二范式的基础上,确保数据表中的每一个非主键字段都和主键字段直接相关,也就是说,要求数据表中的所有非主键字段不能依赖于其他非主键字段。(即,不能存在非主属性A 依赖于非主属性 B,非主属性B依赖于主键C的情况,即存在“A一B一C”的决定关系)通俗地讲,该规则的意思是所有非主键属性 之间不能有依赖关系,必须相互独立。
- 这里的主键可以拓展为候选键。
5、小结
关于数据表的设计,有三个范式要遵循
- 第一范式(1NF) ,确保每列保持 原子性数据库的每一列都是不可分割的原子数据项,不可再分的最小数据单元,而不能是集合、数组、记录等非原子数据项。
- 第二范式(2NF),确保每列都和主键 完全依赖。尤其在复合主键的情况下,非主键部分不应该依赖于部分主键。
- 第三范式(3NF)确保每列都和主键列 直接相关,而不是间接相关。
范式的优缺点
- 范式的优点:数据的标准化有助于消除数据库中的 数据几余,第三范式(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。]
- 范式的缺点:范式的使用,可能 降低查询的效率。因为范式等级越高,设计出来的数据表就越多、越精细,数据的几余度就越低,进行数据查询的时候就可能需要 关联多张表,这不但代价昂贵,也可能使一些 索引策略无效。
范式只是提出了设计的标准,实际上设计数据表时,未必一定要符合这些标准。开发中,我们会出现为了性能和读取效率违反范式化的原则,通过 增加少量的冗余 或重复的数据来提高数据库的 读性能,减少关联查询,ioin 表的次数,实现 空间换取时间 的目的。因此在实际的设计过程中要理论结合实际,灵活运用。
范式本身没有优劣之分,只有适用场景不同。没有完美的设计,只有合适的设计,我们在数据表的设计中,还需要根据需求将范式和反范式混合使用。
三、反范式化
1、概括:
有的时候不能简单按照规范要求设计数据表,因为有的数据看似冗余,其实对业务来说十分重要。这个时候,我们就要遵循 业务优先 的原则,首先满足业务需求,再尽量减少元余。
如果数据库中的数据量比较大,系统的UV和PV访问频次比较高,则完全按照MySQL的三大范式设计数据表,读数据时会产生大量的关联查询,在一定程度上会影响数据库的读性能。如果我们想对查询效率进行优化,反范式优化 也是一种优化思路。此时,可以通过在数据表中 增加冗余字段 来提高数据库的读性能。2、规范化 vs 性能:
- 为满足某种商业目标,数据库性能比规范化数据库更重要
- 在数据规范化的同时,要综合考虑数据库的性能
- 通过在给定的表中添加额外的字段,以大量减少需要从中搜索信息所需的时间
- 通过在给定的表中插入计算列,以方便查询
3、增加元余字段的建议
增加冗余字段一定要符合如下两个条件。只有满足这两个条件,才可以考虑增加几余字段。
- 这个几余字段 不需要经常进行修改
- 这个几余字段 查询的时候不可或缺
4、历史快照、历史数据的需要
在现实生活中,我们经常需要一些余信息,比如订单中的收货人信息,包括姓名、电话和地址等。每次发生的订单收货信息 都属于 历史快照,需要进行保存,但用户可以随时修改自己的信息,这时保存这些几余信息是非常有必要的。
反范式优化也常用在 数据仓库 的设计中,因为数据仓库通常 存储历史数据,对增删改的实时性要求不强,对历史数据的分析需求强。这时适当允许数据的冗余度,更方便进行数据分析。
我简单总结下数据仓库和数据库在使用上的区别:
- 数据库设计的目的在于 捕获数,而数据仓库设计的目的在于 分析数据;
- 数据库对数据的 增删改实时性 要求强,需要存储在线的用户数据,而数据仓库存储的一般是 历史数据;
- 数据库设计需要 尽最避免冗余,但为了提高查询效率也允许一定的 冗余度,而数据仓库在设计上更偏向采用反范式设计。
四、ER模型
1、要素
- 实体,可以看作是数据对象,往往对应于现实生活中的真实存在的个体。
- 强实体:不依赖于其他实体的实体;弱实体,则对另一个实体有很强的依赖关系。
- 1对1:只实体之间的关系是一一对应的
- 1对多:指一边的实体通过关系,可以对应多个另外一边的实体;相反,另外一边的实体通过这个关系,则只能唯一对应这一个实体
- 多对多:只关心两边的实体,通过关系,都可以对应多个对方的实体。
2、把ER模型转换为具体的数据表的原则
- 一个实体通常转换为一个数据表
- 多对多的关系,通过也转换为一个数据表
- 1对1或者1对多的关系,往往通过表的外键来表达,而不是设计一个新的数据表
- 属性转换为表的字段
五、数据表的设计原则
1、三少一多
- 数据表的个数越少越好
- 数据表中的字段个数越少越好
- 数据表中联合主键的字段个数越少越好
- 使用主键和外键越多越好
六、数据库对象编写建议
1、关于库
- [强制]库的名称必须控制在32个字符以内,只能使用英文字母、数字和下划线,建议以英文字母开头
- [强制]库名中英文 一小写 ,不同单词采用 下划线 分割。须见名知意
- [强制]库的名称格式:业务系统名_子系统名
- [强制]库名禁止使用关键字 (如type,order等)
- [强制]创建数据库时必须 显式指定字符集,并且字符集只能是utf8或者utf8mb4。创建数据库SQL举例: CREATE DATABASE crm_fund DEFAULT CHARACTER SET 'utf8';
- [建议]对于程序连接数据库账号,遵循 权限最小原则5使用数据库账号只能在一个DB下使用,不准跨库。程序使用的账号 原则上不准有drop权限。
- [建议]临时库以 tmp_ 为前缀,并以日期为后缀;备份库以 bak_ 为前缀,并以日期为后缀。
2、关于表、列
- [强制]表和列的名称必须控制在32个字符以内,表名只能使用英文字母、数字和下划线,建议以英文字母开头。
- [强制] 表名、列名一律小写,不同单词采用下划线分割。
- [强制]表名要求有模块名强相关,同一模块的表名尽量使用统一前缀。比如: crm_fund_item
- [强制]创建表时必须显式指定字符集 为utf8或utf8mb4。
- [强制]表名、列名禁止使用关键字 (如type,order等)。
- [强制]创建表时必须显式指定表存储引擎 类型。如无特殊需求,一律为InnoDB
- [强制]建表必须有comment.
- [强制]字段命名应尽可能使用表达实际含义的英文单词或缩写。如: 公司D,不要使用corporation_id,而用corp_id 即可。
- [强制]布尔值型的字段命名为 is_描述。如member表上表示是否为enabled的会员的字段命名为is_enabled.
- [强制]禁止在数据库中存储图片、文件等大的二进制数据,通常文件很大,短时间内造成数据量快速增长,数据库进行数据库读取时,通常会进行大量的随机IO操作文件很大时,IO操作很耗时。通常存储于文件服务器,数据库只存储文件地址信息。
- [建议]建表时关于主键: 表必须有主键
- 强制要求主键为id,类型为int或bigint,且为auto_increment 建议使用unsigned无符号型
- 标识表里每一行主体的字段不要设为主键,建议设为其他字段如user_id,orderid等,并建立unique key索引。因为如果设为主键目主键值为随机插入,则会导致innodb内部页分裂和大量随机IO,性能下降。
- [建议] 核心表(如用户表)必须有行数据的 创建时间字 (create_time) 和最后更新时间字段(update_time),便于查问题。
- [建议]表中所有字段尽量都是 NOT NULL 属性,业务可以根据需要定义 DEFAULT值。因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题,
- [建议] 所有存储相同数据的 列名和列类型必须一致 (一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查询效率降低)。
- [建议]中间表(或临时表) 用于保留中间结果集,名称以 tmp_ 开头。备份表用于备份或抓取源表快照,名称以 bak_开头。中间表和备份表定期清理。
- 示例
CREATE TABLE user_info ( `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键', `user_id` bigint NOT NULL COMMENT '用户id', `username` varchar(45) NOT NULL COMMENT '真实姓名', `email` varchar(30) NOT NULL COMMENT '用户邮箱', `nickname` varchar(45) NOT NULL COMMENT '昵称', `birthday` date NOT NULL COMMENT '生日', `sex` tinyint DEFAULT '0' COMMENT '性别', `short_introduce` varchar(150) NOT NULL COMMENT '一句话介绍自己,最多50汉字', `user_resume` varchar(300) NOT NULL COMMENT '用户提交的简历存放地址', `user_register_ip` int NOT NULL COMMENT '注册时的源IP', `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间', `user_review_status` varchar(45) NOT NULL COMMENT '用户资料审核状态,1为通过,2为审核中,3为未通过', PRIMARY KEY(`id`), UNIQUE KEY `uniq_user_id`(`user_id`), KEY `idx_username`(`username`), KEY `idx_create_time_status`(`create_time`,`user_review_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='网站用户基本信息';
3、关于索引
- [强制]InnoDB表必须主键为id int/bigint auto_increment,且主键值 禁止被更新。
- [强制]InnoDB和MyISAM存储引擎表,索引类型必须为 BTREE。
- [建议] 主键的名称以 pk_ 开头,唯一键以 n 或 k 开头,普通索引以 dx 开头,一律使用小写格式,以字段的名称或缩写作为后缀。
- [建议]多单词组成的columnname,取前几个单词首字母,加末单词组成column_name。如: sample 表member_id 上的索引:idx_sample_mid。
- [建议]单个表上的索引个数 不能超过6个。
- [建议]在建立索引时,多考虑建立 联合索引,并把区分度最高的字段放在最前面。
- [建议]在多表 JOIN 的SQL里,保证被驱动表的连接列上有索引,这样JOIN 执行效率最高。
- [建议]建表或加索引时,保证表里互相不存在 冗余索引。比如: 如果表里已经存在key(a,b),则key(a)为几余索引,需要删除。
4、SQL编写
- [强制]程序端SELECT语句必须指定具体字段名称。
- [建议]程序端insert语句指定具体字段名称,不要写成INSERT INTO t1 VALUES(...)。
- [建议]除静态表或小表 (100行以内),DML语句必须有WHERE条件,且使用索引查找。
- [建议]INSERT INTO.ALUES(XX),(xX)(xX)..这里xx的值不要超过5000个。值过多虽然上线很快,但会引起主从同步延迟。
- [建议] SELECT语句不要使用UNION,推荐使用UNION ALL,并且UNION子句个数限制在5个以内。
- [建议]线上环境,多表 JOIN 不要超过5个表
- [建议]减少使用ORDER BY,和业务沟通能不排序就不排序,或将排序放到程序端去做。ORDER BY、GROUP BY、DISTINCT 这些语句较为耗费CPU,数据库的CPU资源是极其宝贵的。
- [建议]包含了ORDER BY、GROUP BY、DISTINCT 这些查询的语句,WHERE 条件过滤出来的结果集请保持在1000行以内,否则SQL会很慢。
- [建议]对单表的多次alter操作必须合并为一次对于超过100W行的大表进行alter table,必须经过DBA审核,并在业务低峰期执行,多个alter需整合在一起,因为alter table会产生表锁,期间阻塞对于该表的所有写入,对于业务可能会产生极大影响。
- [建议]批量操作数据时,需要控制事务处理间隔时间,进行必要的sleep。
- [建议]事务里包含SQL不超过5个,因为过长的事务会导致锁数据较久,MySQL内部缓存、连接消耗过多等问题。
- [建议]事务里更新语句尽量基于主键或者UNIQUE KEY,如UPDATE...WHERE id=XX;否则会产生间隙锁,内部扩大锁定范围,导致系统性能下降,产生死锁。