目录
3.3 第三范式(确保每列都和主键列直接相关,而不是间接相关)
1 什么是数据库设计
简单来说，数据库设计就是根据业务系统的具体需要，结合我们所选用的DBMS（数据库管理系统），为这个业务系统构造出最优的数据存储模型。并建立好数据库中的表结构及表与表之间的关联关系的过程。从而可以有效的对应用系统中的数据进行存储，并可以高效的对已经存储的数据进行访问。
2 为什么要进行数据库设计
2.1 数据库设计的步骤
2.1.1 需求分析
2.1.2 逻辑设计
2.1.3 物理设计
2.1.4 维护优化
3.数据库设计遵循的三大范式
3.1 第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
比如该表的省份，城市和详细地址就很好的遵循了三大范式，如果单独用一个字段地址来囊括省份，城市，详细地址的话，以后查询某个省份或者某个城市的用户就会很困难
3.2 第二范式(确保表中的每列都和主键相关)
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。
这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。
3.3 第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
4.数据库优化原则
4.1 总体优化原则
（1）不在数据库中做运算，运算务必移至业务层
（2）库命名简洁明确（长度不能超过30个字符）
（3）控制列数量（字段少而精，建议控制在20个以内）
（4）控制列数量（平衡范式与冗余（效率优先，往往牺牲范式））
（5）拒绝3B（大SQL，大事务，大批量）
4.2 字段类优化原则
（1）用好数据类型（用合适的字段类型节约空间）
（2）字符串转换为数字（节约空间，提高查询性能）
（3）避免使用NULL字段（NULL字段很难查询优化，NULL字段的索引需要额外空间，NULL字段的复合索引无效）
（4）少用text类型（尽量使用varchar代替text字段）
4.3 索引类优化原则
（1）合理利用索引（改善查询，减慢更新，索引不是越多越好）
（2）字符字段建前缀索引
（3）不在索引做列运算
（4）innodb主键推荐用自增列，字符串不应该做主键
（5）避免索引失效
a.复合索引尽量全匹配
b.最佳左前缀法则(带头索引不能死，中间索引不能断)
c.不要在索引上加任何操作（计算、函数、自动/手动类型转换），不然会导致索引失效而转向全表扫描
d.msyql存储引擎不能继续使用索引中范围条件（between、<、>、in等）右边的列
e.尽量使用覆盖索引（索引列和查询列一致）
f.索引字段上使用is Null或者is not null判断时，会导致索引失效而转向全表扫描
g.索引字段使用like以通配符开头，会导致索引失效
h.索引字段是字符串，但查询时不加单引号，会导致索引失效而转向全表扫描
i.索引字段使用or时，会导致索引失效而转向全表扫描
4.4 SQL类优化原则
（1）sql语句尽可能简单
（2）简单的事务
（3）避免使用触发器/函数（客户端程序取代）
（4）不要select *
（5）OR改写为in
（6）OR改写为UNION
（7）使用union all代替union
（8）少用连接join(超过3个join,一般移动到业务代码里执行)
（9）分页limit优化（偏移量越大，执行越慢）
3275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
