本文由云 + 社区发表

作者：漆洪凯

规则 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.

二.Query 语句与应用系统优化

规则 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. 事务相关性最小原则

此文已由腾讯云 + 社区在各渠道发布

获取更多新鲜技术干货，可以关注我们腾讯云技术社区 - 云加社区官方号及知乎机构号