上海腾科【专家点评】：MySQL开发规范.docx

上海腾科【专家点评】MySQL开发规范 大多数MySQL规范在网上也都能找得到相关的分享，在这里要分享的是个人认为比较重要的，或者容易被忽视的，以及容易被混淆的一些地方。【本文转自mysql中文网】 　　1、默认使用InnoDB引擎 已多次呼吁过了，InnoDB适用于几乎99%的MySQL应用场景，而且在MySQL 5.7的系统表都改成InnoDB了，还有什么理由再死守MyISAM呢。 此外，频繁读写的InnoDB表，一定要使用具有自增/顺序特征的整型作为显式主键。 　　当然了，也不是说MyISAM就一无是处，比如之前就把MyISAM用于临时导数据数据(把数据导入MyISAM，一番处理后再入到InnoDB表)、或者一些特殊的数据统计类场景用MyISAM(大数据量下MyISAM全表顺序读取比InnoDB有明显优势)可能比较合适。前提是，你得非常清楚MyISAM引擎的优势在哪里。 　　【参考】：[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键。 　　2、InnoDB表行记录物理长度不超过8KB 　　InnoDB的data page默认是16KB，基于B+Tree的特点，一个data page中需要至少存储2条记录。因此，当实际存储长度超过8KB(尤其是TEXT/BLOB列)的大列(large column)时会引起“overflow存储”，类似ORACLE中的“行迁移”。 　　因此，如果必须使用大列(尤其是TEXT/BLOB类型)且读写频繁的话，则最好把这些列拆分到子表中，不要和主表放在一起存储。如果不太频繁，可以考虑继续保留在主表中。 　　当然了，如果将 innodb_page_size 选项修改成 8KB，那么行记录物理长度建议不超过4KB。 　　【参考】：[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率。 　　3、是否使用表分区(partition) 　　在一些使用表分区后明显可以提升性能或者运维便利性的场景下，还是建议使用表分区。 　　比如就在zabbix的数据库采用TokuDB引擎的前提下，又根据时间维度使用了分区。这样的好处是保证zabbix日常应用不受到影响前提下，方便管理员例行删除过去数据，只需要删除相应分区即可，不需再执行一个非常慢的DELETE而影响整体性能。 　　当然了，使用表分区可能不利于物理扩展，比如大数据量下想要做哈希水平拆分，这个就见仁见智了，如果你的业务场景下使用表分区更有好处，就放心大胆的用吧。该进行拆分就用拆分方案，不要继续抱着表分区方案不放。 　　【参考】迁移Zabbix数据库到TokuDB。 　　4、是否使用存储过程、触发器 　　在一些合适的场景下，用存储过程、触发器也完全没问题。 　　我们以前就是利用存储完成游戏业务逻辑处理，性能上不是问题，而且一旦需求有变更，只需修改存储过程，变更代价很低。我们还利用触发器维护一个频繁更新的表，对这个表的所有变更都将部分字段同步更新到另一个表中(类似物化视图的变相实现)，也不存在性能问题。 　　有同行认为存储过程和触发器的应用可能会导致发生锁等待、死锁时排查问题上的困惑。嗯，这个是有这个可能性，不过如果真发生时，根据当时现场记录的SQL反查对应的存储过程或触发器，应该也不是难事，只不过要求DBA对线上业务环境更要了然于胸了。 　　总的来说，不要把MySQL的存储过程和触发器视为洪水猛兽，用好的话，没有问题的，真遇到问题了再优化也不迟。另外，MySQL因为没有物化视图，因此视图能不用就尽量少用吧。 　　5、选择合适的类型 　　除了常见的建议外，还有其他几个要点： 　　5.1、用INT UNSIGNED存储IPV4地址，用INET_ATON()、INET_NTOA()进行转换，基本上没必要使用CHAR(15)来存储。 　　5.2、枚举类型可以使用ENUM，ENUM的内部存储机制是采用TINYINT或SMALLINT(并非CHAR/VARCHAR)，性能一点都不差，记住千万别用CHAR/VARCHAR 来存储枚举数据。 　　5.3、还个早前一直在传播的“常识性误导”，建议用TIMESTAMP取代DATETIME。其实从5.6开始，建议优先选择DATETIME存储日期时间，因为它的可用范围比TIMESTAMP更大，物理存储上仅比TIMESTAMP多1个字节，整体性能上的损失并不大。 　　5.4、所有字段定义中，默认都加上NOT NULL约束，除非必须为NULL(但我也想不出来什么场景下必须要在数据库中存储NULL值，可以用0来表示)。在对该字段进行COUNT()统计时，统计结果更准确(值为NULL的不会被COUNT统计进去)，或者执行 WHERE column IS NULL 检索时，也可以快速返回结果。 　　5.