MySQL存储和优化

我正在查看我正在继承的项目的数据库模式。有很多二进制答案被存储为INT（11）而不是TinyInt（1），这是我通常处理这种类型或存储的方式。MySQL存储和优化

我检查了数据，一切都是“1”或“0”。是否有任何理由要或不要将数据类型更改为TinyInt（1）对于所有这些实例，都是未签名的？

同样，如果像“姓氏”如果当前列允许为varchar（255），将切换为varchar（100）产生任何收益？我对性能/效率更感兴趣，而不是仅仅限制数据存储。

感谢， D.

来源

2011-06-09 Don

我会说肯定继续对布尔列的更改。（注意：其实如果你使用的是MySQL 5+，我会使用bit数据类型而不是tinyint）。

就varchar列而言，它实际上并没有改变255到100的长度。

从SQL文档：

A柱使用一个长度字节如果值不需要超过255字节， 2长度个字节，如果值可能需要超过255个字节。

所以，只要它在255以下，你在内存存储方面真的没什么收获。这就是说，通过限制名称的大小，需要在SQL服务器和应用程序之间传输更少的数据。

来源

2011-06-09 18:14:25 Swift

对varchar列**没有影响，只要它们没有索引**。 – Hammerite 2011-06-09 18:22:42

我会想象这与传输速度有关，而不是内存分配，对吗？ – Swift 2011-06-09 18:27:21

我在问题中没有看到任何内容，表明传输速度是优先考虑的因素。但除此之外，我的印象是，保持指数很小会产生很多好处（虽然是的，主要好处是在内存占用）。 – Hammerite 2011-06-09 20:01:15

切换到TINYINT会为您节省3个字节，我相信，这似乎不是一个对我很重要，但它肯定是一个小更高效。

我总是尝试使VARCHAR列尽可能小，因为我可以逃脱。我会亲自关注你可以从中获得的任何收益。

我能想到的，以避免这些变化的主要原因是，如果你有一个运行的ALTER TABLE会导致显著的停机时间如此多的数据。

这些是否有助于您的应用更好地发挥作用，可以进行辩论。从理论上讲，使用VARCHAR时，MySQL只会通过线路发送实际数据，所以如果所有姓氏的长度都是40个字节，则只能发送40个字节。如果该列未在查找中使用，则不应该对您的性能产生任何影响。在SO上有几个相关的问题like this one已经涵盖了这个问题。

来源

2011-06-09 18:13:09 muffinista

3个字节是很多，如果你一百万/十亿行... – 2011-06-09 18:24:43

可以肯定的相乘，它的很多，如果你需要通过电汇一百万行，但没有太多的每个记录的基础。 – muffinista 2011-06-09 18:28:24

即使在硬盘上。如果你有一百万/十亿行，那么每行3个字节的总和就会增加到3MB/3GB ......我意识到存储是便宜的，但它不是存储除“比特”之外的任何布尔值的理由。 – 2011-06-09 18:30:13

MySQL存储和优化

回答

相关问题