MySQL 通过将值填充到固定列宽来优化超过 2.5 亿行的表？

Question

我将使用一个非常大的 MySQL 数据库，我必须尽可能对其进行优化。我读到，使用固定的列宽度是逻辑上优化 MySQL 性能的好方法。例如，CHAR 比 VARCHAR 或 BLOB 更好。然而，当这些静态宽度列中的值全部相同宽度时，MySQL 的性能是否会更好，例如填充整个列宽度？

例如，假设我有一个像这样的表结构

|ID(BIGINT) |Integer (CHAR[5])|Integer2(CHAR[5])|etc...
|1          |45896            |47736            |etc...
|2          |577              |77               |etc... <-- is such a row bad practice looking at performance?
|3          |47732            |85773            |etc...

例如如下所示填充短值会更好吗？ (我的表上有索引需要优化。我正在寻找进一步的优化，因为它进入了大型 MySQL 表的部分？)

|ID(BIGINT) |Integer (CHAR[5])|Integer2(CHAR[5])|etc...
|1          |45896            |47736            |etc...
|2          |00577            |00077            |etc...
|3          |47732            |85773            |etc...

我要使用的表将包含 250+ 百万 行和多个整数列，如上所示。我将该字段定义为 CHAR，因为我将自己以字节为单位存储整数。我会告诉你这样做的原因，但我的应用程序需要这种方法才能正常工作。那么，从 MySQL 的性能来看，填充一个与列宽不匹配的值，这样固定宽度列中的所有值都具有相同的宽度，这样好吗？

宽度也可以读作长度？

我希望我的问题很清楚。如果不是，请告诉我，我会尝试进一步解释我的问题。

总结:固定列宽内的值宽度如何影响 MySQL 在查看行数超过 2.5 亿的表时的性能？例如。将较小的整数填充到列宽以优化性能是否明智？

Answer 1

表没有性能——查询有性能。

表只是存储。您可能关心插入数据、更新或各种 SELECT 查询的性能。但您还没有描述任何查询，因此无法知道您想要优化什么。

所有优化都会提高一种类型数据访问的性能，但会牺牲其他类型数据访问的性能。

固定宽度

整个“固定宽度更快”优化仅适用于 MyISAM 存储引擎，并且仅当表中的所有列都是固定宽度(因此整行都是固定宽度)时。此处描述:https://dev.mysql.com/doc/refman/5.7/en/static-format.html

InnoDB 对于固定宽度的行没有性能优势。您应该使用 InnoDB，因为它现在是默认存储引擎，它支持并发请求的性能和可扩展性的良好功能:

• 行级锁定
• 读者不会阻止作者
• 在 RAM 中缓存数据和索引页

整数与 Char/Varchar

你写道:

I defined the field as a CHAR, since I will store the integers in bytes myself

那么我猜你的意思是你存储为 BINARY ，它类似于 CHAR 但没有经过字符集编码。

这正是 INT 和 BIGINT 类型的作用。它们将整数值转换为二进制并分别存储在 4 字节或 8 字节中。除非您需要存储过大的整数(大于 2⁶⁴-1)，否则您就是在浪费时间。

如果您仅存储整数值，请勿将它们存储在字符串中。与以二进制数据类型 INT 或 BIGINT 存储相比，这至少使用两倍的存储空间。更多的值存储需要更多的 RAM 来进行缓存。如果您可以更紧凑地存储，您的 RAM 将得到更有效的使用，因为它将在相同数量的 RAM 中缓存更多行。

这比选择固定宽度与可变宽度数据类型的微观优化更有利于性能。

在提问之前，您应该知道 INT(4) 和 INT(8) 完全相同。 number 参数看起来可能会影响整数的大小或最大长度，但事实并非如此。请参阅我对 Types in MySQL: BigInt(20) vs Int(20) 的回答

更重要的优化

与正确的索引设计相比，上述所有优化的性能优势都微不足道。您只能设计索引来支持您想要优化的特定查询。