T31学习笔记D03

T31第二天笔记

强制建表规约

必须使用小写字母或者数字：t31_user

禁止出现数字开头

禁止出现两个下划线中间只出现数字。反例：3s

不使用复数名词，反例statuses

禁用保留字：如desc

是与否概念的字段，必须使用is_xxx的方式命名。

数据类型：

小数:decimal

货币数据使用最小货币单位，数据类型为bigint。比如rmb最小单位为分：￥100.05，存为10005，显示的时候先使用公式：10005/100，再显示。

字符串长度几乎相等使用char。ps“char长度为10，存入数据长度为5，后面会补空格，取出来需要trim();

varchar长度不要超过5000

表必备三个字段:id，create_time, update_time

建表推荐规约：

1.表的命名最好遵守"业务名称_表的作用"

2.库名与应用名称尽量一致

3.如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

4.字段允许适当冗余，以提高性能，但必须考虑数据一致。

5.单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。

为什么varcahr最好不超过5000：varchar有可能会建立索引，如果数据量太大索引意义不大。如果varchar数据太大，应该考虑建新表，数据类型用text。

索引规约

聚簇索引：主键

非聚簇索引：非主键

innoDB不可以创建的索引：覆盖索引。

具有唯一性的字段都应该建立唯一索引。几个字段组合起来具有唯一性也应该建立一个组合索引。

索引分类

存储形式：

1.聚簇索引

2.非聚簇索引

数据约束：

1.主键索引

2.唯一索引

3.非唯一索引

索引列的数量：

1.单列索引

2.组合索引

innoDB可以创建的索引：

1.主键索引

2.唯一索引

3.普通索引

索引的数据结构

二叉查找树：类似哈希。平衡二叉树，层级差超过1的时候会滚动数据树，建立新的平衡。

btree：在二叉排序上优化出btree，一个节点存储多个数据

b+tree：在btree上升级出b+tree。只存储键值。

索引名称规约

pk：主键索引

uk：唯一索引

idx：普通索引

创建索引规约

1.有唯一特性的字段必须建成唯一索引

2.在varchar字段上建立索引时，必须指定索引长度

3.建组合索引的时候，区分度最高的在最左边

创建索引避免如下极端误解

1.索引宁滥勿缺，认为一个查询就需要建一个索引

2.吝啬索引创建，认为索引回消耗空间、严重拖慢记录的更新以及行的新增速度

3.抵制唯一索引，认为唯一索引一律需要在应用层通过“先查后插”的方式解决

SQL规约

1.注意字段类型导致的隐式转换导致索引失效。

2.利用覆盖索引来进行查询操作，避免回表

3.利用有序性，如果有order by的场景，注意利用索引的有序性

4.禁模糊查询，页面搜索严谨左模糊或者全模糊，如果需要可以走搜索引擎解决

SQL规约-count

1.使用count(*)

2.count(distinct col)计算该表的不重复行数是除null之外的

3.当值全是null时，count(col)的结果是0，但是sum(col)的结果是null

SQL规约-分页

1.若count为0，应该直接返回

2.优化超多分页场景，利用延迟关联或者子查询优化

SQL规约-null值

使用ISNULL() 来判断是否为null值。

 NULL与任何对象计算返回结果都是null

SQL规约-避坑指南

1.不得使用外键

2.禁用存储过程

3.update前先select，确认数据无误再执行更新语句，避免误操作数据

4.涉及多个表，字段前应当加别名进行限定

5.sql语句中表别名前加as，以t1，t2，t3.。。命名

6.in哦吼边的集合元素数量，应当控制在1000个以内。

SQL性能优化目标

使用explain工具，将每一句关联优化到至少达到range级别。

ORM映射规约

1.在表查询中，一律不要使用*作为查询的字段列表

2.POJO类的布尔属性不能加is，而数据库的字段必须加is_，因为某些框架使用is有限制

3.查询返回加过都需要使用resultMap映射

4.不要用${}，会导致sql注入

5.不要使用mybatis自带的queryForList方法，他会先查出所有数据，然后用sublist方法截取，数据量过大。

6.不允许直接使用HashMap和Hashtable接收结果集

7.更新表数据记录时，必须同时更新update_time

8.不要写一个大而全的数据更新接口。

数据库三大范式

在范式的基础上根据实际需求设计数据库。