MySQL数据库设计总结

1.一般情况可以选择MyISAM存储引擎，如果需要食物支持必须使用InnoDB存储引擎。

MyISAM 存储引擎B-tree索引有个很大的限制：参与一个索引的所有字段的长度之和不能超过1000字节。另外MyISAM数据和索引是分开，而InnoDB的数据存储是按聚簇索引有序排列的，主键是默认的聚簇索引，因此MyISAM虽然在一般情况下，查询性能比InnoDB高，但InnoDB的以主键为条件的查询性能是非常高的。

2.命名规则

数据库和表名应尽可能和所服务的业务模块名一致。

服务与同一个子模块的一类表应尽量以子模块名。

表名应尽量包含与所存放数据对应的单词。

字段名称应尽量保持和实际数据相对应。

联合索引名称应尽量包含所有索引键字段名或缩写。

约束等其他对象也应该尽可能包含所属表或其他对象的名称。

3.数据库字段类型定义

经常需要计算和排序等消耗CPU的字段，应该尽量选择更为迅速的字段，如 TIMESTAMP（4个字节）代替Datetime（8个字节），通过整形替代浮点型和字符型

变长字段使用varchar,不要使用char

对于二进制多媒体数据，流水队列数据，超大文本数据不要放在数据库字段中

4.业务逻辑执行过程必须读到的表中必须要有初始的值。避免业务读出为负或无穷大的值导致程序失败。

5.并不需要一定遵守凡是理论，适度的冗余，让查询尽量减少join

6.访问频率较低的大字段拆分出数据表。有些大字段占用空间多，访问频率较其他字段明显要少得很多，这种情况进行拆分，频繁的查询中就不需要读取大字段，造成IO资源的浪费。

7.大表可以考虑水平拆分。大表影响查询效率，根据业务特性有很多拆分方式，根据时间递增的数据，可以根据时间来分。以id划分的数据，可以根据 id % 数据库个数的方式来拆分。

 

数据库索引

8.业务需要的相关索引是根据实际的设计所构造sql语句的where条件来确定，业务不需要的不要建索引，不允许在联合索引中存在多余的字段。特别是该字段根本不会再条件语句中出现。

9.唯一确定一条记录的一个字段或多个字段要建立主键或唯一索引，不能唯一确定一条记录，为了提高查询效率建普通索引。

10.业务使用的表，有些记录数很少，甚至只有一条记录，为了约束的需要，也要建立索引或者设置主键。

11.对于取值不能重复，经常作为查询条件的字段，应该建唯一索引，并且将查询条件中该字段的条件置于第一个位置。没有必要再建立与该字段有关的联合索引。

12.对于经常查询的字段，其值不唯一，应考虑建立普通索引，查询语句中该字段条件置于第一个位置，对联合索引处理的方法相同。

13.业务通过不唯一索引访问数据时，需要考虑通过该索引值返回的记录稠密度，原则上可能的稠密度最大不能高于0.2，如果稠密度太大，则不合适建立索引。

14.需要联合索引的数据库要注意索引的顺序。SQL语句中的匹配条件也要跟索引的顺序保持一致。

15.表中的多个字段查询作为查询条件，不含有其他索引，并且字段联合值不重复，可以在这多个字段上建唯一的联合索引。

16.重要业务访问数据表时。但不能通过索引访问数据时，应该确保顺序访问的记录数目是有限的，原则上不得多于10。

 

查询语句与应用系统优化

17.合理构造Query语句

insert语句中，根据测试，批量一次插入1000条时效率最高，多于1000条时，要拆分，多次进行同样的插入，应该合并批量进行。

查询条件中各种逻辑操作符性能顺序是and，or ，in 因此在查询中应该尽量避免使用在大集合中使用 in

永远用小结果集驱动大记录集，因为在mysql中，join是通过嵌套循环来实现的。

只取需要的columns，尽量不要使用select *。

仅仅使用最有效的过滤字段，where字句中的过滤条件少为好。

尽量避免复杂的join和子查询。

18.应用系统的优化

合理使用cache，对于变化较少的部分活跃数据通过应用层的cache缓存到内存中，对性能的提升是成数量级的。

对重复执行相同的query进行合并，减少IO次数。

事务相关性最小原则。