MySQL使用规范手册,程序员必知必会( 二 )


为了以防万一 , 比如之后可能Person 表会涉及到毕业院校、工作单位、是否婚配和相片等信息 , 于是就加入5个varchar2 型的字段 , 分别叫做Text1、Text2……Text5;这一手操作看似防范于未然 , 其实也并不见得 , 因为大量预留字段会浪费空间、预留字段不能做到见名知意、预留字段无法确认存储的数据类型且修改其字段类型还可能会造成锁表等问题 。
针对此等情况可以参考以下两点解决方案:

  1. 如果数量很少 , 而且信息的性质与原表密切相关 , 那么就可以直接在原表上增加字段 , 并将相关的数据更新进去;
  2. 如果数量较大 , 或者并非是原表对象至关重要的属性 , 那么就可以新增一个表 , 然后通过键值连接起来;
8、数据库中禁止存储图片、文件等大的二进制数据
若往数据库表中存储文件 , 而文件通常很大 , 当数据库进行读取操作时 , 会进行大量的随机IO操作 , 大文件使得IO操作很耗时耗性能 , 造成短时间内数据量快速增长;所以 , 通常将图片、文件存储在文件服务器中 , 数据库只用于存储文件地址信息 。
三、MySQL数据库字段设计规范
1、优先选择符合存储需要的最小的数据类型 。
主要是考虑索引的性能 , 因为列的字段越大 , 建立索引时所需要的空间也越大 , 这样一页中能存储的索引节点的数量也就越少 , 在遍历时需要的IO次数也就越多 , 索引的性能也就越差 。
2、避免使用TEXT、BLOB数据类型
避免使用TEXT和BLOB数据类型 , 其中最常见的TEXT类型可以存储64K数据 , MySQL内存临时表不支持TEXT、BLOB这样的大数据类型 , 若查询中包含这样的数据 , 在执行排序等操作时就不能使用内存临时表 , 必须使用磁盘临时表执行操作;
TEXT和BLOB类型只能使用前缀索引(当索引是很长的字符序列时 , 这个索引将会很占内存 , 而且会很慢 , 这时候就会用到前缀索引了;所谓的前缀索引就是去索引的前面几个字母作为索引 , 但是要降低索引的重复率 , 所以我们还必须要判断前缀索引的重复率;) , 因为MySQL对索引字段长度是有限的 , 所以TEXT类型只能使用前缀索引 , 并且TEXT列上是不能有默认值的;
若需要使用 , 建议把BLOB或TEXT列分离到单独的的扩展表中 , 且查询时一定不要使用select * , 只需取出必要的列即可 。
3、避免使用ENUM枚举类型
修改ENUM 值需要使用ALTER 语句;
ENUM 类型的ORDER BY 操作效率低;
禁止使用数值作为ENUM 的枚举值 。
4、所有列的默认值定义为NOT NULL
数据库所有为NULL 的列需要额外的空间来存储 , 因此会占用更多的空间;
数据库在进行比较和计算时需要对NULL 值做特别处理 。
5、使用TIMESTAMP(4字节)或DATETIME(8字节)类型存储时间
TIMESTAMP 存储的时间范围为:1970-01-01 00:00:01 ~ 2038-01-19-03:14:07;
TIMESTAMP 占用4字节和INT相同 , 但可读性比INT 类型的高 , 若是超出TIMESTAMP 取值范围的则使用DATETIME 类型存储;
用字符串类型存储时间的缺点:无法使用日期函数进行比较计算、字符串存储占有更多的空间 。
6、财务相关的金额类数据必须使用decimal 类型
精准浮点:decimal
非精准浮点:float、double
Decimal类型为精准浮点数 , 在计算时不会丢失精度;占有空间大小由定义的宽度决定 , 每4个字节可以存储9位数字 , 且小数点也要占有一个字节;另外 , Decimal类型可用于存储比bigint更大的数据类型 。
四、MySQL索引设计规范
1、每张表的索引数量不超过5个
索引可以增加查询效率 , 但同样也会降低插入和更新的效率 , 甚至有些情况下还会降低查询效率 , 因此并不是越多越好 , 要控制其数量 。
2、每个Innodb 表必须有一个主键
Innodb 是一种索引组织表 , 其数据存储的逻辑顺序和索引的顺序是相同的;
每张表可以有多个索引 , 但表的存储顺序只能有一种 , Innodb 是按照主键索引的顺序来组织表的 , 因此不要使用更新频繁的列、UUID、MD5、HASH和字符串列作为主键 , 这些列无法保证数据的顺序增长 , 主键建议使用自增ID 值 。


推荐阅读