总结一些 Mysql 数据库的设计规范和注意事项

基本设计规范

  • 数据库和表的字符集统一使用UTF8，兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效
  • 所有表和字段都需要添加注释，使用comment从句添加表和列的备注 从一开始就进行数据字典的维护
  • 尽量控制单表数据量的大小，建议控制在500万以内，500万并不是MySQL数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题，可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小
  • 谨慎使用MySQL分区表，分区表在物理上表现为多个文件，在逻辑上表现为一个表 谨慎选择分区键，跨分区查询效率可能更低 建议采用物理分表的方式管理大数据
  • 尽量做到冷热数据分离，减小表的宽度，MySQL限制每个表最多存储4096列，并且每一行数据的大小不能超过65535字节 减少磁盘IO,保证热数据的内存缓存命中率（表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO） 更有效的利用缓存，避免读入无用的冷数据 经常一起使用的列放到一个表中（避免更多的关联操作）
  • 禁止在表中建立预留字段。预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型，所以无法选择合适的类型 对预留字段类型的修改，会对表进行锁定
  • 禁止在数据库中存储图片，文件等大的二进制数据。通常文件很大，会短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机IO操作，文件很大时，IO操作很耗时。通常存储于文件服务器，数据库只存储文件地址信息

数据库字段设计规范

  • 优先选择符合存储需要的最小的数据类型。列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少也越少，在遍历时所需要的IO次数也就越多， 索引的性能也就越差

  • 避免使用TEXT、BLOB数据类型，最常见的TEXT类型可以存储64k的数据。建议把BLOB或是TEXT列分离到单独的扩展表中，Mysql内存临时表不支持TEXT、BLOB这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。而且对于这种数据，Mysql还是要进行二次查询，会使sql性能变得很差，但是不是说一定不能使用这样的数据类型。如果一定要使用，建议把BLOB或是TEXT列分离到单独的扩展表中，查询时一定不要使用select * 而只需要取出必要的列，不需要TEXT列的数据时不要对该列进行查询。TEXT或BLOB类型只能使用前缀索引。因为MySQL对索引字段长度是有限制的，所以TEXT类型只能使用前缀索引，并且TEXT列上是不能有默认值的。

  • 避免使用ENUM类型。修改ENUM值需要使用ALTER语句，ENUM类型的ORDER BY操作效率低，需要额外操作。禁止使用数值作为ENUM的枚举值，尽可能把所有列定义为NOT NULL，因为索引NULL列需要额外的空间来保存，所以要占用更多的空间；进行比较和计算时要对NULL值做特别的处理

  • 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间。TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。TIMESTAMP 占用4字节和INT相同，但比INT可读性高，超出TIMESTAMP取值范围的使用DATETIME类型存储。

  • 同财务相关的金额类数据必须使用decimal类型。Decimal类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每4个字节可以存储9位数字，并且小数点要占用一个字节。可用于存储比bigint更大的整型数据。

索引设计规范

  • 限制每张表上的索引数量，建议单张表索引不超过5个。索引并不是越多越好！索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。因为mysql优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加mysql优化器生成执行计划的时间，同样会降低查询性能。

  • 禁止给表中的每一列都建立单独的索引。5.6版本之前，一个sql只能使用到一个表中的一个索引，5.6以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。

  • 每个Innodb表必须有个主键。不要使用更新频繁的列作为主键，不适用多列主键（相当于联合索引） 不要使用UUID、MD5、HASH、字符串列作为主键（无法保证数据的顺序增长），主键建议使用自增ID值。