MySQL的checksum table机制是如何运作的？

前言：为什么我们要在凌晨三点聊 checksum table？

脑子呢？ 说实话，我写这篇文章的时候，咖啡以经凉了键盘上的灰尘也跟我一起打了个哈欠。可是 MySQL 那颗神秘的 checksum 机制， 实在是太让人又爱又恨了——爱它的“快”，恨它的“奇”。下面就让我们把这段技术八卦掰成碎片，拼凑出一幅不太完整、却极其真实的画面。

一、 checksum table 的“表层”工作原理

一句话概括：把每行数据算个 CRC32，染后把所you行的 CRC32 再 XOR 合并成一个全局值。听起来像是给数据贴上指纹，却又像是给指纹再加盐，官宣。。

其实吧，这一步玩全在 MySQL Server 层完成。存储引擎只负责把「逻辑记录」送到 Server， Server 按照字段定义顺序逐列取值，先处理 NULL 位掩码，再对每个字段Zuo CRC32，再说说用 BIT_XOR 把整行的 CRC 累计，说实话...。

二、 影响 checksum 值的隐藏因子

• NULL 位掩码——每行哪些列为 NULL，者阝要先生成一个 bitmask 并参与 CRC；即使所you可见值相同，只要 NULL 分布不一样，checksum 立马翻车。
• 整数大小端——InnoDB 用大端存储整数，而 MySQL Server 要把它们翻转成小端再算 CRC；有符号/无符号的符号位也会被“调皮”地翻转一次。
• 生成列——不管是 STORED 还是 VIRTUAL， 服务器者阝会把它们当作普通列参与计算，只是 VIRTUAL 不占磁盘，却仍然出现在 bitmask 中。
• 字符集 & 字符串长度——VARCHAR 会根据实际字节数参与 CRC， 而 CHAR 则始终填满固定长度；不同字符集下同样文字对应的字节序列可嫩天差地别。