MySQL(二)数据类型和schema优化

数据类型和schema优化

数据类型的优化

更小的通常更好

<高性能MySQL>
应该尽量使用可以正确存储数据的最小数据类型，更小的数据类型通常更快，因为它们占用更少的磁盘、内存和CPU缓存，并且处理时需要的CPU周期更少，但是要确保没有低估需要存储的值的范围，如果无法确认哪个数据类型，就选择你认为不会超过范围的最小类型
案例：
设计两张表，设计不同的数据类型(tinyInt, int, bigInt)，查看表的容量
可以看到,两张表的数据文件,大小是一样的 因为存储的数据一样,但是占用空间不一样.
(为啥使用空间和占用空间不一样?磁盘4K对齐,按页读取,提高效率;可以读取4K的整数倍)

InnoDB的数据存储, .frm是存储表结构的文件, .ibd是存储具体数据的文件和索引
MyISAM, .frm存储的表结构, .MYI是索引文件, .MYD是数据文件

简单就好

简单数据类型的操作通常需要更少的CPU周期，例如，
1、整型比字符操作代价更低，因为字符集和校对规则是字符比较比整型比较更复杂，
2、使用mysql自建类型而不是字符串来存储日期和时间
3、用整型存储IP地址
案例：
1.创建两张相同的表，改变日期的数据类型(date和varchar)，查看SQL语句执行的速度(show profiles)
2.INET_ATON(‘192.168.200.11’) 把IP转换成整形;INET_NTOA(‘3232257391’) 把整形转换成IP

尽量避免使用null

数据库里面,null != null
如果查询中包含可为NULL的列，对mysql来说很难优化，因为可为null的列使得索引、索引统计和值比较都更加复杂，
设计新的表是尽量不使用NULL,从业务上避免;
已经存在的表一般没有再改的必要,坦白来说，通常情况下null的列改为not null带来的性能提升比较小，所有没有必要将所有的表的schema进行修改，但是应该尽量避免设计成可为null的列

实际细则

整形类型

可以使用的几种整数类型：TINYINT，SMALLINT，MEDIUMINT࿰