同类型整数不同数值范围的MySQL查询性能差异探究

Great question—let's break this down step by step, since it touches on how databases handle numeric comparisons under the hood, and how that differs from string comparisons.

1. 非索引场景：数值大小不影响比较性能 #

首先要明确：整数类型（INT/BIGINT）的比较不是逐字节扫描的，这和字符串有本质区别。

• 对于INT（32位）：现代CPU会用一条32位比较指令（比如x86架构的CMP指令）直接对比整个32位二进制值，不管你的数值是1（二进制00 00 00 01）还是39亿（接近0xF0 00 00 00），这条指令的执行耗时完全一致。不存在“数值越大，越早发现差异”的情况——因为CPU是一次性对比整个32位数据，而不是从左到右逐字节检查。
• 对于BIGINT（64位）：在64位CPU上，同样是一条64位比较指令完成操作；即使在32位CPU上，也只需要两条32位指令（先对比高32位，再对比低32位），耗时也是固定的，和数值大小无关。

这和字符串比较完全不同：字符串是按字节顺序逐位对比，直到找到第一个不同的字节为止，所以前缀相同的字符串比较会更慢。但整数类型的比较逻辑是硬件级别的整体对比，没有逐字节的过程。

2. 索引场景：差异来自数据量，而非数值范围位置 #

当查询涉及索引（比如B+树索引，这是数据库最常用的索引结构）时，情况会稍微复杂一点，但核心逻辑还是和数值大小无关：

• 索引定位：不管你查询的是1-1亿还是39亿-40亿，数据库都需要在B+树中定位到范围的起始节点。B+树的高度通常只有3-4层，所以不管是树的头部还是尾部，定位所需的IO（如果索引不在内存中）或内存访问次数几乎一致，耗时差异可以忽略。
• 范围扫描：真正的性能差异只来自扫描的行数多少。比如如果1-1亿的范围包含1亿条数据，而39亿-40亿的范围只有1000条数据，那前者的扫描耗时肯定更长——但这是数据量的问题，不是数值本身的大小导致的。如果两个范围的行数相同，性能几乎没有差异。

3. 总结 #

• 不管是INT还是BIGINT，数值大小本身不会影响比较性能，整数比较是通过固定数目的CPU指令完成的，和字符串的逐字节扫描逻辑完全不同。
• 非索引场景：性能完全一致，和数值范围无关。
• 索引场景：性能差异仅取决于扫描的行数，而非数值范围的位置（开头还是结尾）。

内容的提问来源于stack exchange，提问作者Krupp