本文由云 + 社区发表作者：漆洪凯
规则 1：一般情况可以选择 MyISAM 存储引擎，如果需要事务支持必须使用 InnoDB 存储引擎。
注意：MyISAM 存储引擎 B-tree 索引有一个很大的限制：参与一个索引的所有字段的长度之和不能超过 1000 字节。另外 MyISAM 数据和索引是分开，而 InnoDB 的数据存储是按聚簇 (cluster) 索引有序排列的，主键是默认的聚簇 (cluster) 索引，因此 MyISAM 虽然在一般情况下，查询性能比 InnoDB 高，但 InnoDB 的以主键为条件的查询性能是非常高的。
规则 2：命名规则。
数据库和表名应尽可能和所服务的业务模块名一致
服务与同一个子模块的一类表应尽量以子模块名 (或部分单词) 为前缀或后缀
表名应尽量包含与所存放数据对应的单词
字段名称也应尽量保持和实际数据相对应
联合索引名称应尽量包含所有索引键字段名或缩写，且各字段名在索引名中的顺序应与索引键在索引中的索引顺序一致，并尽量包含一个类似 idx 的前缀或后缀，以表明期对象类型是索引。
约束等其他对象也应该尽可能包含所属表或其他对象的名称，以表明各自的关系
规则 3：数据库字段类型定义
经常需要计算和排序等消耗 CPU 的字段, 应该尽量选择更为迅速的字段，如用 TIMESTAMP(4 个字节，最小值 1970-01-01 00:00:00)代替 Datetime（8 个字节，最小值 1001-01-01 00:00:00）, 通过整型替代浮点型和字符型
变长字段使用 varchar，不要使用 char
对于二进制多媒体数据，流水队列数据(如日志)，超大文本数据不要放在数据库字段中
规则 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))
联合索引中的字段应尽量满足过滤数据从多到少的顺序，也就是说差异最大的字段应该房子第一个字段
建立索引尽量与 SQL 语句的条件顺序一致，使 SQL 语句尽量以整个索引为条件，尽量避免以索引的一部分 (特别是首个条件与索引的首个字段不一致时) 作为查询的条件
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 则无法用到这个联合索引。
当需要查询的数据库字段全部在索引中体现时，数据库可以直接查询索引得到查询信息无须对整个表进行扫描(这就是所谓的 key-only)，能大大的提高查询效率。当 a，ab，abc 与其他表字段关联查询时可以用到索引
当 a，ab，abc 顺序而不是 b，c，bc，ac 为顺序执行 Order by 或者 group 不要时可以用到索引
以下情况时，进行表扫描然后排序可能比使用联合索引更加有效 a. 表已经按照索引组织好了 b. 被查询的数据站所有数据的很多比例。
规则 17：重要业务访问数据表时。但不能通过索引访问数据时，应该确保顺序访问的记录数目是有限的，原则上不得多于 10.
二.Query 语句与应用系统优化
规则 18：合理构造 Query 语句
Insert 语句中，根据测试，批量一次插入 1000 条时效率最高，多于 1000 条时，要拆分，多次进行同样的插入，应该合并批量进行。注意 query 语句的长度要小于 mysqld 的参数 max_allowed_packet
查询条件中各种逻辑操作符性能顺序是 and,or,in, 因此在查询条件中应该尽量避免使用在大集合中使用 in
永远用小结果集驱动大记录集，因为在 mysql 中，只有 Nested Join 一种 Join 方式，就是说 mysql 的 join 是通过嵌套循环来实现的。通过小结果集驱动大记录集这个原则来减少嵌套循环的循环次数，以减少 IO 总量及 CPU 运算次数
尽量优化 Nested Join 内层循环。
只取需要的 columns，尽量不要使用 select *
仅仅使用最有效的过滤字段，where 字句中的过滤条件少为好
尽量避免复杂的 Join 和子查询 Mysql 在并发这块做得并不是太好，当并发量太高的时候，整体性能会急剧下降，这主要与 Mysql 内部资源的争用锁定控制有关，MyIsam 用表锁，InnoDB 好一些用行锁。
规则 19：应用系统的优化
合理使用 cache，对于变化较少的部分活跃数据通过应用层的 cache 缓存到内存中，对性能的提升是成数量级的。
对重复执行相同的 query 进行合并，减少 IO 次数。
事务相关性最小原则
此文已由腾讯云 + 社区在各渠道发布
获取更多新鲜技术干货，可以关注我们腾讯云技术社区 - 云加社区官方号及知乎机构号