2023年7月27日发(作者：)

MySQL数据库设计总结规则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，不要使⽤char3. 对于⼆进制多媒体数据，流⽔队列数据(如⽇志)，超⼤⽂本数据不要放在数据库字段中规则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,whereb>=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_packet2. 查询条件中各种逻辑操作符性能顺序是and,or,in,因此在查询条件中应该尽量避免使⽤在⼤集合中使⽤in3. 永远⽤⼩结果集驱动⼤记录集，因为在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. 事务相关性最⼩原则