数据类型和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