
1. checksum table.
checksum table 会对表一行一行进行计算,直到计算出最终的 checksum 结果。
比如对表 n4 进行校验(记录数 157W,大小为 4G)
我自己笔记本上的测试结果,速度挺快。
不过checksum的限制比较多。罗列如下,
A、不能对视图进行校验。
B、字段顺序不同,校验结果也会不一致。
C、CHAR(100) 和 VARCHAR(100) 存储相同的字符,校验结果也会不一致。
D、在执行 checksum 同时,会对表所有行加共享读锁。
E、还有就是 MySQL 版本不同,有可能校验结果不一致。比如手册上说的, MySQL 5.6.5 之后的版本对时间类型的存储格式有变化,导致校验结果不一致。
那 checksum 的 限制这么多,我们是不是有其方法来突破所有限制呢? 比如说可以模拟 checksum table 的原理来手工计算。
2. 自己计算 checksum 值。
这里用了 MySQL 自身的几个特性:session 变量;通用表达式;窗口函数以及 MySQL 的 concat_ws 函数。实现非常简单。
比如我们用 sha 函数来计算校验值。
如果在 MySQL 老版本运行,可以利用 MySQL 的黑洞引擎,改下 SQL 如下:
对于表要计算校验数据一致性的需求,首选第二种自己写 SQL 的方法。
1. ASCII用途:用来映射简单的单字节字符,比如大小写英文字母、阿拉伯数字、常用的标点符、运算符、控制字符等。
编码范围:U+0000 - U+007F
注意:对于用这类字符的场景够用了,但是却无法表达比如汉字,日文等编码。
2. UNICODE
用途:用来映射包含 ASCII 以内的其他的所有字符。
编码范围:U+0000 - U+10FFFF
注意:ASCII 是 UNICODE 的子集,ASCII 编码的字符可以无损转换为 UNICODE 编码的字符。
MySQL 常用字符集
1. Latin1
Latin1 是 cp1252 或者 ISO-8859-1 的别名。ISO-8859-1 编码是单字节编码,向下兼容 ASCII。
编码范围:U+0000 - U+00FF
ISO-8859-1 收录的字符除 ASCII 收录的字符外,还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。
单字节内的空间都被 ISO-8859-1 编码占用,所以能够用 ISO-8859-1 编码存储、传输其他任何编码的字节流。
比如把一个 Utf8mb4 的编码或者 GBK 的编码存入 Latin1,不会有任何问题。因为 Latin1 保留了原始的字节流,这也就是 MySQL 长期以来把 Latin1 做默认字符集的原因。
但是由于 Latin1 对任何字符都存放字节流,造成了字符个数的浪费。
比如:
CHAR(10) CHARACTER SET LATIN1CHAR(10) CHARACTER SET UTF8
该字段中存储字符个数 UTF8 是 Latin1 的三倍!!!
2. GB18030
GB18030 是中国官方标准字符集,向前兼容 GBK、GB2312,是这两个的超集。用 1、2、4 个字节分别表示一个符号。比如对一般中文字符,默认是用两个字节编码存储。Windows 系统,默认用的就是 GB18030。
若只是存储中文字符,那 GB18030 最佳。
原因有两点:
1)占用空间小,比如比 UTF8 小。
2)存储的汉字根据拼音来排序,检索快。
3. UTF8
UTF8 是 Unicode 的编码实现,可以存储 UNICODE 编码对应的任何字符, 这也是使用最多的一种编码。最大的特点就是变长的编码方式,用 1 到 4 个字节表示一个符号,可以根据不同的符号编码字节长度。
字母或数字用 1 字节,汉字用 3 字节,emoji 表情符号用 4 字节。UTF8 字符集目前是使用最广泛的。
注意!MySQL 里常说的 UTF8 是 UTF8MB3 的别名,UTF8MB3 是 UTF8MB4 的子集,UTF8MB4 才是真正的 4 字节 UTF8 字符集!
UTF8MB3 表示最大支持 3 个字节存储字符,UTF8MB4 表示最大 4 个字节存储字符。根据实际需要和未来展望,MySQL 8.0 已经默认用 UTF8MB4 基础字符集。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)