Mysql：字段大小/显示宽度是否影响索引性能？

假设我想在

grade

列上添加一个索引。如果它具有较小的显示宽度（例如，

int（4）

），是否会产生差异

编辑：

• 这里所说的性能是指查询时间

• 此外，不清楚列显示宽度是否影响索引大小。我们关注的是一个至少有数百万行的非常大的表。如果答案能说明这一点，那就太好了

---

首先，显示在任何情况下都没有区别——它只是用于在查询响应中如何表示字段。

int

是静止的，

int

使用4个字节，

bigint

是使用8个字节的

bigint

您从哪方面考虑“绩效”？总的请求时间、保持加载或缓存数据和索引所需的内存使用情况？磁盘空间

我猜你的意思是，它会影响查询响应的速度吗

然而，这个问题相当广泛，真正的答案是，这要看情况而定。您的系统是64位还是32位？我们在谈多少张唱片？该领域是一个更大的综合指数的一部分，但仍然是它的一小部分

（注意：需要对此声明进行检查，就像对字符进行散列以获取索引一样）从或字符（4）到字符（32），当然您可能会发现一些不可忽略的性能影响，但这并不是因为复杂性，而是操作系统和体系结构处理这些问题的额外开销

然而，我要冒险提出一个建议，除非改变类型（int到varchar），这可能会改变索引的方法或索引的存储大小的巨大变化，否则您可能不会“看到”任何区别。我怀疑在不同的整数类型之间，您是否能够轻松地显示一致的减速。

简短的回答：

（4）

对

INT

没有任何意义

龙雄回答:

列大小影响行的大小，行的大小会影响表的大小，表的大小会影响查询的速度。但是

如果桌子是“小”的，那么在性能上几乎没有差别

如果表的大小超过了RAM中可以缓存的大小，那么差异可能会很大——因为您可能会受到I/O限制。在某些情况下，这是十倍的减速

要缩小始终为4字节的

INT

，请切换到

TINYINT UNSIGNED

（1字节，范围：0..255）、

SMALLINT UNSIGNED

（2字节，0..65K）或

MEDIUMINT UNSIGNED

（3字节，0..16M）

假设

grade

为0..100，则

TINYINT

（有符号或无符号）是最优的

同时，您可以更改您的

id

INT（4）

的唯一目的是与

ZEROFILL

结合使用，您希望将12显示为

0012

。这是极为罕见的

不要使用

CHAR

，除非字符串确实是固定长度字符串。然后可能应该显式声明它

字符集ascii

，因为它是十六进制、所有数字或两个字母的国家/地区代码（etc）。不管怎么说，utf8的杀伤力太大了

---

假设您使用的是InnoDB，“次要”索引（等级）将隐式包含

主键（id）

。因此，每个索引项的大小是

grade

的大小加上

id

的大小加上一堆开销。假设成绩正常且学生人数不超过65K，则可以使用3个字节，而不是原来的8个字节。但是表很小，因此您不太可能受到I/O限制。因此，8而不是3的开销很小。

谢谢您的回复。你为什么要发布第二个回复而不是编辑第一个呢？是的。我指的是查询响应时间。@JunjiZhi我认为这是一个错误。我删除了另一个错误。因此，即使

grade

是大型复合索引的一小部分，显示宽度也不应该影响索引。是吗？

int（4）

除了将完全可用的

int

字段转换为不可用的信息之外，什么都不做。数百万行不是很大，它在小的范围内。数据库的性能将由I/O子系统和CPU的速度决定，而不是在这里或那里削减一个或两个字节。数据库是为了保存数据并加以利用而设计的，通过降低其字段的有用性来设计数据库以提高性能并不是工具的正确使用。您在错误的地方进行优化，特别是如果您计划为数据库使用单个服务器。

CREATE TABLE student(
`id` int(11) auto_increment PRIMARY KEY
`grade` int(11)
)