CHAR(5) 与 INT

发布于 2024-09-14 11:58:08 字数 249 浏览 4 评论 0原文

INFORMIX-SE 7.1:

假设 col5 CHAR(5) 将仅包含从 00001 到 99999 的数字:

  1. CHAR(5) 列使用 5 个字节的存储空间,那么 INTEGER 使用多少字节?
  2. INT 列上的 UNIQUE INDEX 的执行速度是否比 CHAR(5) 更快?
  3. INT 列上的 SELECT MAX() 是否比 col5 CHAR(5) 上的 MAX() 更快?

INFORMIX-SE 7.1:

Assume that col5 CHAR(5) will only contain numbers from 00001 to 99999:

  1. a CHAR(5) column uses 5 bytes of storage, how many bytes does an INTEGER use?
  2. Does a UNIQUE INDEX on an INT column perform faster than a CHAR(5)?
  3. Is SELECT MAX() on an INT column faster than MAX() on the col5 CHAR(5)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

等风也等你 2024-09-21 11:58:08

CHAR(5) 将始终使用 5 个字节的空间(自 mySQL 4.1 起,在多字节编码中为 10 个字节),因为每个字符可以存储 255 个不同的字符(在多字节编码中甚至更多)。

无符号 SMALLINT (0..65535) 将占用 2 个字节,无符号 MEDIUMINT (0....1670 万) 需要 3 个字节。

底线:对数字数据使用 CHAR 类型总是浪费空间。

至于另外两个问题:

INT 列上的 UNIQUE INDEX 的执行速度是否比 CHAR(5) 更快?

非常非常有可能是的,因为索引不需要是字母数字,并且可以处理更少量的数据

INT 列上的 SELECT MAX() 是否比 col5 CHAR(5) 上的 MAX() 更快?

可能是的,因为要在 CHAR 列上运行数字函数,必须对每条记录执行类型转换。

参考:

  • mySQL手册中的数字类型
  • < a href="http://dev.mysql.com/doc/refman/5.0/en/char.html" rel="nofollow noreferrer">mySQL 手册中的 CHAR 和 VARCHAR 类型

CHAR(5) will always use 5 bytes of space (10 in multi-byte encodings since mySQL 4.1) because every character can store 255 different characters (or even more in multi-byte encodings).

An unsigned SMALLINT (0..65535) will take 2, an unsigned MEDIUMINT (0.... 16,7 Million) 3 bytes.

Bottom line: Using a CHAR type for numeric data is always a waste of space.

As to the other two questions:

Does a UNIQUE INDEX on an INT column perform faster than a CHAR(5)?

Very, very likely yes, because the index doesn't need to be alpha-numeric and can work with a smaller amount of data

Is SELECT MAX() on a INT column faster than MAX() on the col5 CHAR(5)?

Extremely likely yes, because to run a numeric function on a CHAR column, a type cast has to be performed on every record.

Reference:

缺⑴份安定 2024-09-21 11:58:08

INT 使用 4 个字节。 并且可以存储 0 ... 4294967295(无符号),带 INT

顺便说一句,我不会使用 CHAR、VARCHAR 或任何 string-y 类型来存储数字。你在这里只是自找麻烦。例如,如果使用字符串比较,则 9 大于 10。您还会错过很多算术运算。

INT uses 4 bytes. And you can store 0 ... 4294967295 (unsigned) with INT

By the way I wouldn't use CHAR, VARCHAR, or any string-y type to store numbers. You are just asking for trouble here. For example, 9 is greater than 10 if you use string comparison. You'll also miss out on a lot of arithmetic operations.

沫雨熙 2024-09-21 11:58:08
  • INFORMIX-SE 7.1:

更接近受支持的版本(比 4.10 或 2.10),但仍需要十年或更长时间才能获得支持。

假设 col5 CHAR(5) 仅包含从 00001 到 99999 的数字:

  1. CHAR(5) 列使用 5 个字节的存储空间,INTEGER 使用多少字节?
  2. INT 列上的 UNIQUE INDEX 的执行速度是否比 CHAR(5) 更快?
  3. INT 列上的 SELECT MAX() 是否比 col5 CHAR(5) 上的 MAX() 更快?
  1. Informix DBMS 中的 INTEGER 为 4 个字节。
  2. 勉强算。是否真正可测量还有待商榷,但要比较的数据略少(少一个字节),因此要做的事情也较少。
  3. 同样,不太可能存在可测量的差异。如果列上有索引,则两个操作都只需访问该索引。如果没有索引,则两个操作最终都会读取表(表扫描),并且处理 5 个字符而不是 4 个字节会产生微小的损失。
  • INFORMIX-SE 7.1:

Getting closer to a supported version (than 4.10, or 2.10), but still a decade and more out of support.

Assume that col5 CHAR(5) will only contain numbers from 00001 to 99999:

  1. a CHAR(5) column uses 5 bytes of storage, how many bytes does an INTEGER use?
  2. Does a UNIQUE INDEX on an INT column perform faster than a CHAR(5)?
  3. Is SELECT MAX() on an INT column faster than MAX() on the col5 CHAR(5)?
  1. 4 bytes for INTEGER in the Informix DBMS.
  2. Marginally. Whether it is truly measurable is open to debate, but there is slightly less data to compare (one byte less), so there is less to do.
  3. Again, there is unlikely to be a measurable difference. If there's an index on the column, both operations simply access the index. If there is no index, then both operations end up reading the table (a table scan) and there is a minuscule penalty for dealing with 5 characters instead of 4 bytes.
舂唻埖巳落 2024-09-21 11:58:08

INT 为 4 个字节。 INT 更快!

有关更多详细信息,请查看此问题的选定答案:

4 bytes for INT. INT is faster!

For more detail, check out the selected answer for this question:

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文