我有一个mysql数据库，其中保存了项目的信息并且还保留了描述。字段长度对查询时间的影响
问题是说明栏最多可容纳150个字符，我认为它很长，我想知道是否会减慢查询时间。另外我想知道它是否建议缩短int的大小，我的意思是如果我的价格通常不是那么大，我应该将列限制为small/medium int吗？
的列是这样的：
id name category publisher mail price description
在此先感谢。
只有你认为150长 - 数据库最有可能不会，因为它们旨在一次处理更多。 不要考虑牺牲你的数据来“表现”。如果您的应用程序的性质要求您一次存储多达150个字符的文本，不要害怕这样做，但要查看优化提示。
尽管使用正确的数据类型可以帮助您节省空间。例如，如果您有一个字段用于存储值0到20，则不需要INT字段类型。一个TINYINT会做。
documentation列出了数据类型，并提供了他们使用多少空间以及他们如何管理的信息。
将您的字符数据存储为varchar()而不是char()并阅读关于这些数据类型的MySQL文档（here）。这只会将字符实际存储在描述中，另外还会有几个字节的开销。
至于较长的字段是否意味着性能较差的查询。这是一个复杂的主题。显然，在极端情况下，拥有最大容量的记录会使事情减慢，而不是10个字节的记录。原因与I/O性能有关。 MySQL读入页面并且页面可以包含一个或多个记录。然后处理页面上的记录。
适合页面的记录越多，I/O越少。
但随后它变得更加复杂，这取决于硬件和存储引擎。现在，磁盘和操作系统一样都是预读。因此，下一次阅读的页面（如果页面没有碎片并且彼此相邻）可能比读取初始页面快得多。实际上，在第一页上的处理完成之前，您可能会在内存中拥有下一页。在这一点上，每页上有多少记录并不重要。
而且，200个字节的记录并不是很大。您应该首先考虑让您的应用程序正常工作，然后再担心要使其达到性能目标。一路走来，做出合理的选择，例如使用varchar()而不是char()和适当大小的数字（您可能会考虑定点数字类型而不是浮动的货币值）。
全心全意同意第1部分;但与第2部分强烈反对。现在所有硬件都是32位或64位，只有当你拥有数以亿计的这些表示时，才会考虑使用较小的int表示，并且知道你有性能问题。对可能的数据量使用较小的int表示可能会损害性能并提高性能。 – 2013-04-20 16:53:51
迄今为止我所读过的和学过的所有东西都得出结论：使用专门适合应用程序需求的字段类型仅对内存使用（以及缓存和更少的磁盘访问）有利。如果你能指点我（并且每个人都阅读这些内容）以获取有关该主题的材料，我会非常高兴！ – 2013-04-20 19:39:54