数据库设计规范参考
2015-01-15 09:01
253 查看
1、关于表类型
表类型尽是用InnoDB,少用MyISAM
在读取上InnoDB与MyISAM差不了多少,但在update上,MyISAM很吃亏
InnoDB 为行级锁,支持事务,MyISAM为表级锁,有时候会给表带来不可预知的破坏
2、关于索引
索引可以加快我们sql查询的效率,但并不是索引越多越好。索引越多,数据库在写入时就会越慢。
中文字符串不推荐加索引,如果该字符串使用比较频繁,可以加一些辅助的字段来加索引,加快索引速度。例如:目前商家中心的主旺旺查询比较多,增加了一个字段存crc32(主旺旺)并对此字段加索引,查询时使用主旺旺+crc32(主旺旺)的联合条件查询,加快查询速度
多列索引 有一个优点最左前缀,就是如果创建一个有firstname、lastname、age列上的多列索引,就相当于创建了
* firstname,lastname,age
* firstname,lastname
* firstname
这三中相关的查询都能用到这个过引,但这种多列索引也不能使用太多,请参照第一条。
3、关于分表
在设计表的初期就要做一个评估,预估一下表的数据量有多大,能否承载2-3年的数据量。10个字段以内、读写不是很频繁、字段以数字为主的表。在1000万到2000万时,查询还是很快的。但一般的表在500W到1000w就可以考虑分表。
一般分表的方式有,ID取模、按时间段分表(如按天、按月、按年分表)、按量分表(如500万一张表)
分表有好处,也会带来一些问题,如翻页问题 、top问题
4、关于事务
当在同一个操作中操作多个表时,可以使用事务,如:只有当A表写成功的时候才可以写B表,当B表写失败了,则回滚A表。
事务能很好的保证此动作的完整性,但大量使用事务,对数据库的开销也会很大,特别是在高并发的情况下。
一般事务使用在商业应用中以及一些对数据安全要求很高的应用。目前我们的项目中只有资金和报名使用了事务。
5、关于表的设计
注意表的可扩展性,具体可参考分表以及其它,比较你在设计一张支付宝相关的表时,可以考虑一下兼容财付通、银联等其它相关。
注意表字段的冗余,冗余字段可能在维护时比较麻烦,但在后期复杂的业务当中,可能会节省很多的查询开销,所以在条件允许的情况下,尽量多冗余几个字段。
单个字段的设计时,一定要注意字段类型、字段长度。字段类型的类型能节省存储空间、优化查询。
字段长度能一定要预估好,举一个例子:商家中心有一段时间,突然发现好几个商家怎么也无法入驻商家中心,代码也没有动过,找了好久,最后发现,家中心中的一线表里面uid的长充是8位,需用户中心的uid是11位。而该商家的uid正好超过8位,所以无法写入到商家中心的表中。
表字段尽量给默认值,不要给null。
表类型尽是用InnoDB,少用MyISAM
在读取上InnoDB与MyISAM差不了多少,但在update上,MyISAM很吃亏
InnoDB 为行级锁,支持事务,MyISAM为表级锁,有时候会给表带来不可预知的破坏
2、关于索引
索引可以加快我们sql查询的效率,但并不是索引越多越好。索引越多,数据库在写入时就会越慢。
中文字符串不推荐加索引,如果该字符串使用比较频繁,可以加一些辅助的字段来加索引,加快索引速度。例如:目前商家中心的主旺旺查询比较多,增加了一个字段存crc32(主旺旺)并对此字段加索引,查询时使用主旺旺+crc32(主旺旺)的联合条件查询,加快查询速度
多列索引 有一个优点最左前缀,就是如果创建一个有firstname、lastname、age列上的多列索引,就相当于创建了
* firstname,lastname,age
* firstname,lastname
* firstname
这三中相关的查询都能用到这个过引,但这种多列索引也不能使用太多,请参照第一条。
3、关于分表
在设计表的初期就要做一个评估,预估一下表的数据量有多大,能否承载2-3年的数据量。10个字段以内、读写不是很频繁、字段以数字为主的表。在1000万到2000万时,查询还是很快的。但一般的表在500W到1000w就可以考虑分表。
一般分表的方式有,ID取模、按时间段分表(如按天、按月、按年分表)、按量分表(如500万一张表)
分表有好处,也会带来一些问题,如翻页问题 、top问题
4、关于事务
当在同一个操作中操作多个表时,可以使用事务,如:只有当A表写成功的时候才可以写B表,当B表写失败了,则回滚A表。
事务能很好的保证此动作的完整性,但大量使用事务,对数据库的开销也会很大,特别是在高并发的情况下。
一般事务使用在商业应用中以及一些对数据安全要求很高的应用。目前我们的项目中只有资金和报名使用了事务。
5、关于表的设计
注意表的可扩展性,具体可参考分表以及其它,比较你在设计一张支付宝相关的表时,可以考虑一下兼容财付通、银联等其它相关。
注意表字段的冗余,冗余字段可能在维护时比较麻烦,但在后期复杂的业务当中,可能会节省很多的查询开销,所以在条件允许的情况下,尽量多冗余几个字段。
单个字段的设计时,一定要注意字段类型、字段长度。字段类型的类型能节省存储空间、优化查询。
字段长度能一定要预估好,举一个例子:商家中心有一段时间,突然发现好几个商家怎么也无法入驻商家中心,代码也没有动过,找了好久,最后发现,家中心中的一线表里面uid的长充是8位,需用户中心的uid是11位。而该商家的uid正好超过8位,所以无法写入到商家中心的表中。
表字段尽量给默认值,不要给null。
相关文章推荐
- 数据库设计过程中参考的规范
- 数据库设计:数据库设计命名参考规范
- SQL数据库设计规范参考之数据库对象命名详细文档
- 数据库设计规范(参考)
- SQL数据库设计规范参考之数据库对象命名详细文档
- 数据库设计命名参考规范
- SQL数据库设计规范参考之数据库对象命名详细文档
- SQL数据库设计规范参考之数据库对象命名详细文档
- 【转载】数据库设计命名参考规范
- 数据库设计方法、规范与技巧
- 数据库设计方法、规范与技巧(推荐)
- 数据库设计方法、规范与技巧(推荐)
- 数据库设计规范
- 数据库设计方法、规范与技巧
- 数据库设计规范
- 数据库设计规范与技巧
- 数据库设计方法、规范与技巧(1)
- 数据库设计方法、规范与技巧(2)
- 数据库设计规范
- 数据库设计方法、规范与技巧