schema与数据类型的优化
合理使用范式和反范式
- 三范式存在的意义 没有数据冗余
- 企业中范式和反范式需要混合使用
主键的选择
- 代理主键 与业务无关，无意义的数字
- 自然主键 事务属性中的自然唯一标识
- 推荐使用代理主键 他们不与业务耦合，因此更容易维护
一个大多数表，最好是全部表，通用的键策略能够减少需要编写的源码数量，减少系统的总体拥有成本
字符集的选择
- utf8 纯拉丁文能表示的内容，就没必要选择纯latin之外的其它字符编码，减少存储空间
- 如果我们可以确定不需要存放多种语言，就没必要非得使用UTF-8或者其他UNICODE字符类型，这会造成大量的存储空间浪费
- MySQL的数据类型可以精确到字段，所以当我们需要大型数据库中存放多字节数据的时候，可以通过对不同表不同使用不同的数据类型来较大程度减小数据存储量，紧而降低IO操作次数并提高缓存命中率
- utf8(mb4)存在其他字符的时候，最常用 uft8(latin) utf8(gbk)不建议使用
存储引擎的选择
- engine = innodb my.ini default-storage-engine = innodb
- MYISAM
- memory 不能进行持久化
| MyISAM | InnoDB | |
|---|---|---|
| 索引类型 | 非聚簇索引 | 聚簇索引 |
| 支持事务 | 否 | 是 |
| 支持表锁 | 是 | 是 |
| 支持行锁 | 否 | 是 |
| 支持外键 | 否 | 是 |
| 支持全文索引 | 是 | 是 |
| 适合操作类型 | 大量select | 大量insert、delete、update |
聚簇非聚簇：数据文件跟索引文件是否放在一起
锁粒度越小越好，innodb默认给索引加锁
操作列是索引列加行锁，否则加表锁
查询时 like % 开头不会走索引
存储引擎 —— 数据文件的组织形式
适当的数据冗余
&……%￥#@&……%￥#……%￥#
适当拆分
表中存在类似text或者大型varchar的时候，如果我们在访问这张表的时候都不需要这个字段，应该将其拆分到独立的表中，以减少常用数据所占的存储空间，好处是每个数据块中可以存储的数据条数大大减少，既能减少IO次数，能提高内存中的缓存命中率