1. 使用Innodb存储引擎
5.5版本开始mysql默认存储引擎就是InnoDB，5.7版本开始，系统表都放弃MyISAM了。
2. 表字符集统一使用UTF8
•UTF8字符集存储汉字占用3个字节，存储英文字符占用一个字节
•校对字符集使用默认的 utf8_general_ci
•连接的客户端也使用utf8，建立连接时指定charset或SET NAMES UTF8;。（对于已经在项目中长期使用latin1的，救不了 了）
•如果遇到EMOJ等表情符号的存储需求，可申请使用UTF8MB4字符集
3. 所有表都要添加注释
•尽量给字段也添加注释
•类status型需指明主要值的含义，如”0-离线，1-在线”
4. 控制单表字段数量
•单表字段数上限30左右，再多的话考虑垂直分表，一是冷热数据分离，二是大字段分离，三是常在一起做条件和返回列的不 分离。
•表字段控制少而精，可以提高IO效率，内存缓存更多有效数据，从而提高响应速度和并发能力，后续 alter table 也更快。
5. 所有表都必须要显式指定主键
•主键尽量采用自增方式，InnoDB表实际是一棵索引组织表，顺序存储可以提高存取效率，充分利用磁盘空间。还有对一些复 杂查询可能需要自连接来优化时需要用到。
•需要全局唯一主键时，使用外部发号器ticket server（建设中）
•如果没有主键或唯一索引，update/delete是通过所有字段来定位操作的行，相当于每行就是一次全表扫描
•少数情况可以使用联合唯一主键，需与DBA协商
6. 不强制使用外键参考
•即使2个表的字段有明确的外键参考关系，也不使用 FOREIGN KEY ，因为新纪录会去主键表做校验，影响性能。
7. 适度使用存储过程、视图，禁止使用触发器、事件
•存储过程（procedure）虽然可以简化业务端代码，在传统企业写复杂逻辑时可能会用到，而在互联网企业变更是很频 繁 的，在分库分表的情况下要升级一个存储过程相当麻烦。又因为它是不记录log的，所以也不方便debug性能问题。如果 使 用过程，一定考虑如果执行失败的情况。
·使用视图一定程度上也是为了降低代码里SQL的复杂度，但有时候为了视图的通用性会损失性能（比如返回不必要的字 段）。
•触发器（trigger）也是同样，但也不应该通过它去约束数据的强一致性，mysql只支持“基于行的触发”，也就是说，触发器 始终是针对一条记录的，而不是针对整个sql语句的，如果变更的数据集非常大的话，效率会很低。掩盖一条sql背后的工 作， 一旦出现问题将是灾难性的，但又很难快速分析和定位。再者需要ddl时无法使用pt-osc工具。放在transaction执 行。
•事件（event）也是一种偷懒的表现，目前已经遇到数次由于定时任务执行失败影响业务的情况，而且mysql无法对它做失败 预警。建立专门的 job scheduler 平台。
8. 单表数据量控制在5000w以内
9. 数据库中不允许存储明文密码