Mysql逻辑设计与物理设计

一、逻辑设计

1.范式设计

（1）数据范式设计一

• 数据库表中的所有字段都只具有单一属性
• 单一属性的列是由基本的数据类型所构成
• 表是简单的二维表
  如：

错误的范式
字段name-age不是单一属性

id	name-age
1	xiaoming-18

正确的范式

id	name	age
1	xiaoming	18

（2）数据范式设计二

• 表中只存在一个业务逐渐，而不能存在非主键列只对部分主键的依赖关系。
  错误范式：产品与订单的ID没有直接的关联关系
  产品表

id	name
1	游戏机
2	手机

订单表

id	address	prd_id
1	北京	1
2	上海	1

正确范式：
产品表

id	name
1	游戏机
2	手机

订单表

id	address
1	北京
2	上海

订单中间表

id	order_id	prd_id
1	1	1
2	2	1

（3）数据范式设计三

• 非主键列不能依赖其他表的非主键列。
  错误范式：
  订单与客户姓名关联
  订单与客户编号关联
  客户姓名和客户编号关联。
  不应该将客户编号和客户姓名存放在订单中，如果修改用户表中的姓名和编号修改
  则需要对订单中的客户编号和姓名进行修改。

id	address	客户姓名	客户编号
1	北京	小明	bj123
2	上海	如花	sh123

2.反范式设计

• 反范化设计为了提高范式化导致性能和读取的效率问题，从而适当的对数据范式设计进行违反。
• 通过少量的冗余数据，提高读取效率和性能上的问题，这种方式就是空间换时间。

3.范式化与反范式化的优缺点

范式设计

优点：

• 尽可能减少数据的冗余
• 范式化比反范式化的更新操作更快
• 范式化的表比反范式化的表更小。
  缺点：
• 对于表的查询需要对多个表进行关联
• 更难进行索引优化

反范式设计

优点：

• 减少表的关联
• 可以更好的进行索引的优化
  缺点：
• 存在数据冗余和冗余数据的维护
• 多数据的修改需更多的成本去处理

二、物理设计

（1）物理设计的过程

• 定义数据、表和字段的命名规范
• 选择合适的存储引擎
• 字段选择适合的数据类型
• 根据业务设计合理表和表之间的关联关系
• 建立数据库结构

（2）命名规范

• 数据库、 表、字段必须遵循可读性原则。
• 数据库、 表、字段必须遵循表意性原则，表的名字能够描述表的功能、模块等。
• 数据库、 表、字段必须遵循长名原则，尽可能的少用缩写的名字。
• 数据库、 表、字段应使用英文或者拼音的专有名词。不要使用拼音。

（3）存储引擎的选择

对比项	MyISAM	InnoDB
主外键	不支持	支持
事务	不支持	支持
行表锁	表锁，不适合高并发操作	行锁，适合高并发操作
缓存	缓存索引，不缓存查询的数据	不仅缓存索引，还会缓存查询数据，对内存要求较高，而且内存的大小会对性能造成影响
表空间	小，因为MyISAM会压缩	大
关注点	性能	事务

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
仅从锁的角度来说：
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用。
行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理系统。

（4）数据类型的选择

• 优先考虑使用数字类型
• 其次日期和时间类型
• 最后字符串类型
• 对于相同级别的数据类型，优先考虑使用占用空间较少的数据类型。
• 对精度有要求的时候，选择精度高的数据类型。 int

datetime 与timestamp 都是日期类型，datetime与时区无关，而timestamp与时区有关。timestamp本质是使用int进行存储。所以效率会比datetime高。但是要考虑时区的问题。