本文作者:我爱技术网

MySQL数据库设计总结

我爱技术网 3个月前 ( 01-03 02:19 ) 383
摘要: 规则1:一般情况可以选择MyISAM存储引擎,如果需要事务支持必须使用InnoDB存储引擎。注意:MyISAM存储引擎 B-tree索引有一个很大的限制:参与一个索引的所有字段的长...

MySQL数据库设计总结         第1张

规矩1:一般状况能够挑选MyISAM存储引擎,假如需求业务支撑有必要运用InnoDB存储引擎。

留意:MyISAM存储引擎 B-tree索引有一个很大的束缚:参与一个索引的一切字段的长度之和不能超过1000字节。另外MyISAM数据和索引是分隔,而InnoDB的数据存储是按聚簇(cluster)索引有序排列的,主键是默许的聚簇(cluster)索引,因此MyISAM虽然在一般状况下,查询功能比InnoDB高,但InnoDB的以主键为条件的查询功能是十分高的。

规矩2:命名规矩。

1、数据库和表名应尽或许和所效劳的业务模块名共同

2、效劳与同一个子模块的一类表应尽量以子模块名(或部分单词)为前缀或后缀

3、表名应尽量包括与所寄存数据对应的单词

4、字段称号也应尽量坚持和实践数据相对应

5、联合索引称号应尽量包括一切索引键字段名或缩写,且各字段名在索引名中的次序应与索引键在索引中的索引次序共同,并尽量包括一个相似idx的前缀或后缀,以标明期目标类型是索引。

6、束缚等其他目标也应该尽或许包括所属表或其他目标的称号,以标明各自的关系

规矩3:数据库字段类型界说

1、常常需求核算和排序等耗费CPU的字段,应该尽量挑选更为敏捷的字段,如用TIMESTAMP(4个字节,最小值1970-01-01 00:00:00)代替Datetime(8个字节,最小值1001-01-01 00:00:00),经过整型代替浮点型和字符型

2、变长字段运用varchar,不要运用char

3、关于二进制多媒体数据,流水行列数据(如日志),超大文本数据不要放在数据库字段中

规矩4:业务逻辑履行过程有必要读到的表中有必要要有初始的值。防止业务读出为负或无穷大的值导致程序失利

规矩5:并不需求必定遵守范式理论,适度的冗余,让Query尽量削减Join

规矩6:拜访频率较低的大字段拆分出数据表。有些大字段占用空间多,拜访频率较其他字段明显要少许多,这种状况进行拆分,频繁的查询中就不需求读取大字段,形成IO资源的糟蹋。

规矩7:大表能够考虑水平拆分。大表影响查询功率,依据业务特性有许多拆分方法,像依据时刻递加的数据,能够依据时刻来分。以id区分的数据,可依据id%数据库个数的方法来拆分。

规矩8:业务需求的相关索引是依据实践的设计所结构sql句子的where条件来断定的,业务不需求的不要建索引,不允许在联合索引(或主键)中存在多于的字段。特别是该字段底子不会在条件句子中呈现。

规矩9:仅有断定一条记载的一个字段或多个字段要树立主键或许仅有索引,不能仅有断定一条记载,为了进步查询功率建一般索引

规矩10:业务运用的表,有些记载数很少,甚至只要一条记载,为了束缚的需求,也要树立索引或许设置主键。

规矩11:关于取值不能重复,常常作为查询条件的字段,应该建仅有索引(主键默许仅有索引),而且将查询条件中该字段的条件置于第一个方位。没有必要再树立与该字段有关的联合索引。

规矩12:关于常常查询的字段,其值不仅有,也应该考虑树立一般索引,查询句子中该字段条件置于第一个方位,对联合索引处理的方法相同。

规矩13:业务经过不仅有索引拜访数据时,需求考虑经过该索引值返回的记载稠密度,准则上或许的稠密度最大不能高于0.2,假如稠密度太大,则不适宜树立索引了。

当经过这个索引查找得到的数据量占到表内一切数据的20%以上时,则需求考虑树立该索引的价值,一起由于索引扫描发生的都是随机I/O,生其功率比全表次序扫描的次序I/O低许多。数据库系统优化query的时分有或许不会用到这个索引。

规矩14:需求联合索引(或联合主键)的数据库要留意索引的次序。SQL句子中的匹配条件也要跟索引的次序坚持共同。

留意:索引的顺势不正确也或许导致严峻的后果。

规矩15:表中的多个字段查询作为查询条件,不含有其他索引,而且字段联合值不重复,能够在这多个字段上建仅有的联合索引,假定索引字段为 (a1,a2,...an),则查询条件(a1 op val1,a2 op val2,...am op valm)m<=n,能够用到索引,查询条件中字段的方位与索引中的字段方位是共同的。

规矩16:联合索引的树立准则(以下均假定在数据库表的字段a,b,c上树立联合索引(a,b,c))

1、联合索引中的字段应尽量满意过滤数据从多到少的次序,也就是说差异最大的字段应该房子第一个字段

2、树立索引尽量与SQL句子的条件次序共同,使SQL句子尽量以整个索引为条件,尽量防止以索引的一部分(特别是首个条件与索引的首个字段不共一起)作为查询的条件

3、Where a=1,where a>=12 and a<15,where a=1 and b<5 ,where a=1 and b=7 and c>=40为条件能够用到此联合索引;而这些句子where b=10,where c=221,where b>=12 and c=2则无法用到这个联合索引。

4、当需求查询的数据库字段悉数在索引中体现时,数据库能够直接查询索引得到查询信息无须对整个表进行扫描(这就是所谓的key-only),能大大的进步查询功率。

当a,ab,abc与其他表字段关联查询时能够用到索引

5、当a,ab,abc次序而不是b,c,bc,ac为次序履行Order by或许group不要时能够用到索引

6、以下状况时,进行表扫描然后排序或许比运用联合索引愈加有效

a.表已经依照索引安排好了

b.被查询的数据站一切数据的许多比例。

规矩17:重要业务拜访数据表时。但不能经过索引拜访数据时,应该保证次序拜访的记载数目是有限的,准则上不得多于10.

规矩18:合理结构Query句子

1、Insert句子中,依据测验,批量一次刺进1000条时功率最高,多于1000条时,要拆分,多次进行相同的刺进,应该兼并批量进行。留意query句子的长度要小于mysqld的参数 max_allowed_packet

2、查询条件中各种逻辑操作符功能次序是and,or,in,因此在查询条件中应该尽量防止运用在大集合中运用in

3、永久用小成果集驱动大记载集,由于在mysql中,只要Nested Join一种Join方法,就是说mysql的join是经过嵌套循环来实现的。经过小成果集驱动大记载集这个准则来削减嵌套循环的循环次数,以削减IO总量及CPU运算次数

4、尽量优化Nested Join内层循环。

5、只取需求的columns,尽量不要运用select *

6、只是运用最有效的过滤字段,where 字句中的过滤条件少为好

7、尽量防止杂乱的Join和子查询

Mysql在并发这块做得并不是太好,当并发量太高的时分,全体功能会急剧下降,这主要与Mysql内部资源的争用锁定控制有关,MyIsam用表锁,InnoDB好一些用行锁。

规矩19:运用系统的优化

1、合理运用cache,关于改变较少的部分活泼数据经过运用层的cache缓存到内存中,对功能的提高是成数量级的。

2、对重复履行相同的query进行兼并,削减IO次数。

3、业务相关性最小准则


文章版权及转载声明:

作者:我爱技术网本文地址:https://www.wajsw.com/blog/410.html发布于 3个月前 ( 01-03 02:19 )
文章转载或复制请以超链接形式并注明出处我爱技术网

赞(0

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏

发表评论

快捷回复:

评论列表 (暂无评论,383人围观)参与讨论

还没有评论,来说两句吧...