1、基本规则
1.1 、尽量不在数据库做运算
运算尽可能移到程序端CPU。
1.2、 控制单表数据量
1.2.1、一年内的单表数据量预估
>纯INT不超过1000W
>含CHAR不超过500W
1.2.2、合理分表不超载
> 取模
例如:id%n=0 —> tabel0;
id%n=1 —> tabel1;
id%n=2 —> tabel2;
…
> 时间
例如可以根据月份、季度、年进行分表
> 哈希
例如一个电商网站,需要记录用户的所有购买记录,如果将所有的记录放到
一张userBuy表中,势必会非常巨大,所以我们可以通过对userid进行分表处
理,将不同的用户购买记录放到不同的分表中,比如对userid做crc32的hash
计算,然后用得到的哈希值进行取余,取余的余数就是你的分表数,余数则
是该userid需要记录进入的表。
> 区域
例如主键id范围进行分表
> 引擎.
可以使用Mysql的MyISAM存储引擎,因为其支持MERAGE类型,结合
UNION来实现数据表的分割和数据同步。这种方式的优点就是可以保留表
的外键、事务以及其它属性,但是缺点就是查询性能比较低,同步也不够
灵活,所以大多不推荐这种方式实现分表。
1.3、遵循三大范式
> 第一范式(1NF)
1NF是指数据库中表的每一列都是不可分割的基本数据项,同一列的数据不
能有多个值。如果出现重复,就可能需要定义一个新的实体(即:生成一
个新的表)来描述关系。
例如:公司中某个人员隶属于多个部门,那么在人员中,这个人部门字段
可以存储多个值,但是这样违反了1NF。
解决办法:此时可以生成一个新表,表示人员与部门的关系。
> 第二范式(2NF)
2NF是在1NF的基础上建立的,所以满足2NF的必须满足1NF;
2NF要求数据库中表的每个实例或行必须能唯一的区分。为实现区分通 常需要为表加上一个列(主键)或多列(联合主键);
2NF要求实体的属性完全依赖于主键。如果存在依赖主键一部分的属性
那么这个属性和主键应该分离出来形成一个新的实体,新实体于原实体之间
是一对多的关系。简而言之,就是2NF非主属性不能部分依赖于主键。
> 第三范式(3NF)
3NF依赖于2NF;
3NF要求一个数据库表中不包含在其他表中已经存在的非主键的字段;
3NF表属性不能依赖其他表中非主键的属性;
1.4、拒绝3B
>大SQL(Big SQL)
>大事务(Big Transaction)
>大批量(Big Batch)
2、字段规则
>将字符串转化为数字:查询快、占用空间小,比如无符号INT存储IP。
>优先使用Enum或SET:可能值已知且有限的字符串类型。
>避免使用NULL字段:很难进行查询优化、NULL列加索引,需要额外的
空间、含NULL复合索引无效。
>少用并拆分TEXT/BLOB
Text类型处理性能远低于VARCHAR(强制生成临时表、浪费更多空间)
>不在数据库中存图片
3、索引规则
>谨慎合理添加索引
改善查询
减慢更新
能不加索引则不加索引
>大量重复值索引无效
例如:性别列
>不在索引列做数学或函数运算
无法使用索引
导致全表扫描
>尽量不用外键
可到达其它表意味着“锁”
高并发容易死锁
4、SQL优化
4.1、OR
· 同一字段将OR改写为IN
· 不同字段将OR改写为UNION
举例:Select * from opp where phone=‘010-88886666’ or cellPhone=
‘13800138000’;
优化:
Select * from opp where phone=‘010-88886666’
union
Select * from opp where cellPhone=‘13800138000’;
4.2、避免负向查询和%前缀查询
>NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等
>%前缀:使用不了索引、导致全表扫描。
国庆就要放假了,提前一天回家,啊啊啊啊啊啊啊,没心情写了,暂时就这些吧先,祝万千猿友假期愉快!