SQL性能治理经验谈

原创

后台技术汇

发布于 2024-09-19 23:26:40

1180

发布于 2024-09-19 23:26:40

背景

SQL数据类型

数值

这些类型包括严格数值数据类型(INTEGER、SMALLINT、DECIMAL 和 NUMERIC)，以及近似数值数据类型(FLOAT、REAL 和 DOUBLE PRECISION)。

类型	大小	范围（有符号）	范围（无符号）	用途
TINYINT	1 Bytes	(-128，127)	(0，255)	小整数值
SMALLINT	2 Bytes	(-32 768，32 767)	(0，65 535)	大整数值
MEDIUMINT	3 Bytes	(-8 388 608，8 388 607)	(0，16 777 215)	大整数值
INT或INTEGER	4 Bytes	(-2 147 483 648，2 147 483 647)	(0，4 294 967 295)	大整数值
BIGINT	8 Bytes	(-9,223,372,036,854,775,808，9 223 372 036 854 775 807)	(0，18 446 744 073 709 551 615)	极大整数值
FLOAT	4 Bytes	(-3.402 823 466 E+38，-1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38)	0，(1.175 494 351 E-38，3.402 823 466 E+38)	单精度浮点数值
DOUBLE	8 Bytes	(-1.797 693 134 862 315 7 E+308，-2.225 073 858 507 201 4 E-308)，0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308)	0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308)	双精度浮点数值
DECIMAL	对DECIMAL(M,D) ，如果M>D，为M+2否则为D+2	依赖于M和D的值	依赖于M和D的值	小数值

字符串

字符串类型指CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM和SET

类型	大小	用途
CHAR	0-255 bytes	定长字符串
VARCHAR	0-65535 bytes	变长字符串
TINYBLOB	0-255 bytes	不超过 255 个字符的二进制字符串
TINYTEXT	0-255 bytes	短文本字符串
BLOB	0-65 535 bytes	二进制形式的长文本数据
TEXT	0-65 535 bytes	长文本数据
MEDIUMBLOB	0-16 777 215 bytes	二进制形式的中等长度文本数据
MEDIUMTEXT	0-16 777 215 bytes	中等长度文本数据
LONGBLOB	0-4 294 967 295 bytes	二进制形式的极大文本数据
LONGTEXT	0-4 294 967 295 bytes	极大文本数据

时间

表示时间值的日期和时间类型为DATETIME、DATE、TIMESTAMP、TIME和YEAR。

类型	大小( bytes)	范围	格式	用途
DATE	3	1000-01-01/9999-12-31	YYYY-MM-DD	日期值
TIME	3	'-838:59:59'/'838:59:59'	HH:MM:SS	时间值或持续时间
YEAR	1	1901/2155	YYYY	年份值
DATETIME	8	'1000-01-01 00:00:00' 到 '9999-12-31 23:59:59'	YYYY-MM-DD hh:mm:ss	混合日期和时间值
TIMESTAMP	4	'1970-01-01 00:00:01' UTC 到 '2038-01-19 03:14:07' UTC结束时间是第 2147483647 秒，北京时间 2038-1-19 11:14:07，格林尼治时间 2038年1月19日凌晨 03:14:07	YYYY-MM-DD hh:mm:ss	混合日期和时间值，时间戳

SQL治理的几条特殊建议

【建议】表中的自增列（auto_increment属性），推荐使用bigint类型。

因为无符号int存储范围为-2147483648~2147483647（大约21亿左右），溢出后会导致报错。

真实项目运维会复杂一点：

主键溢出问题暴露，往往意味着生产环境已经有脏数据产生，需要考虑数据回滚恢复
对大表而言，修改表结构意味着大量binlog产生，要考虑主从同步延迟，带来的影响
生产环境和灰度环境的代码兼容问题

【建议】业务中IP地址字段推荐使用int类型，不推荐用char(15)。

因为int只占4字节，可以用如下函数相互转换，而char(15)占用至少15字节。

一旦表数据行数到了1亿，那么要多用1.1G存储空间。

举例子，通过SQL的内置函数：inet_aton 和 inet_ntoa，完成数值到ip地址，以及ip地址到数值的转换。

原理：ip地址的数字总是按照网络字节顺序存储，那么我们可以按照二进制规律去进行数值转换。

如ip地址（209.207.224.40），是按照 209×2^24 + 207×2^16 + 224×2^8 + 40 进行计算得出结果。

【建议】不推荐使用blob，text等类型，且文本数据尽量用varchar存储。

它们都比较浪费硬盘和内存空间。在加载表数据时，会读取大字段到内存里从而浪费内存空间，影响系统性能。建议和PM、RD沟通，是否真的需要这么大字段。

另外，因为varchar是变长存储，比char更省空间。MySQL server层规定一行所有文本最多存65535字符（实际上InnoDB并不支持65535长度的VARCHAR，因为还有别的开销，实际测试是能存放最大长度是65532字符），因此在utf8字符集下最多存21844个字符，超过会自动转换为mediumtext字段。

而text在utf8字符集下最多存21844个字符，一般建议用varchar类型，字符数不要超过2700。

注意：char(n) 和 varchar(n) 中括号中 n 代表字符的个数，并不代表字节个数，比如 CHAR(30) 就可以存储 30 个字符。

行记录格式概念

Compact行记录格式

是Mysql5.0+引入的，设计目的是高效存储数据，一个页存放行数据越多，性能越好。

变长字段长度列表 + NULL标志位 + 记录头信息 + 列1数据 + 列2数据 + ...

Innodb中当一行记录超过8098字节时，会将该记录中选取最长的一个字段将其768字节放在原始page里，该字段余下内容放在overflow-page里。在compact行格式下，原始page和overflow-page都会加载。

上面讲的blob或变长大字段类型包括blob、text、varchar，其中varchar列值长度大于某数N时也会存溢出页；如果有TEXT、BLOB、VARCHAR列，Compact格式会存放768个前缀字节的列数据，行溢出数据则存放到overflow-page；

Dynamic行记录格式

对blob采用完全行溢出，即聚集索引记录（数据页）只保留20字节的指针，指向真实存放它的溢出段地址：

dynamic行格式，列存储是否放到off-page页，主要取决于行大小，它会把行中最长的那一列放到off-page，直到数据页能存放下两行。TEXT/BLOB列 <=40 bytes 时总是存放于数据页。可以避免compact那样把太多的大列值放到 B-tree Node，因为dynamic格式认为，只要大列值有部分数据放在off-page，那把整个值放入都放入off-page更有效。

【建议】时间类型尽量选取timestamp。

因为datetime占用8字节，timestamp仅占用4字节，但是范围为1970-01-01 00:00:01到2038-01-01 00:00:00。

更为高阶的方法，选用int来存储时间，使用SQL函数unix_timestamp()和from_unixtime()来进行转换。

CREATE TABLE `test` (  `id` bigint NOT NULL AUTO_INCREMENT,  `name` varchar(30) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '名字',  `desc` text COLLATE utf8mb4_unicode_ci,  `birthday` timestamp NULL DEFAULT CURRENT_TIMESTAMP,  `birthday_time` int DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;