char vs varchar用于库存数据库中的性能

时间:2008-12-08 17:11:29

标签: mysql sql performance varchar

我正在使用mySQL来建立股票期权数据库。大约有330,000行(每行是1个选项)。我是SQL的新手,所以我试图决定字段类型,如选项符号(4到5个字符),股票代码(1到5个字符),公司名称(从5到60不等)字符)。

我想优化速度。两者都创建了数据库(当新的价格数据出来时每5分钟发生一次 - 我没有实时数据馈送,但它几乎是实时的,因为我得到一个新的文本文件,其中有330,000行传送给我每5分钟;这个新数据完全取代以前的数据),也用于查找速度(将有一个基于Web的前端,许多用户可以运行即席查询)。

如果我不关心空间(因为数据库生命周期是5分钟,每行包含大约300字节,所以整个事情可能只有100MB)那么构建字段的最快方法是什么?

对于数字字段的同样问题,实际上:int(11)和int(7)之间是否存在性能差异?对于查询和排序,一个长度是否比另一个更好?

谢谢!

5 个答案:

答案 0 :(得分:33)

在MyISAM中,制作固定宽度的记录有一些好处。 VARCHAR是可变宽度。 CHAR是固定宽度的。如果您的行只有固定宽度的数据类型,那么整行是固定宽度的,并且MySQL在计算该表中的行空间要求和偏移量方面获得了一些优势。也就是说,优势可能很小,并且几乎不值得可能的微小增益,其他成本(如缓存效率)超过固定宽度,填充CHAR列,其中VARCHAR可以更紧凑地存储。

它变得更高效的断点取决于您的应用程序,除了您测试两种解决方案并使用最适合您的应用程序数据的数据之外,这不是可以解决的问题。

关于INT(7)与INT(11),这与存储或性能无关。 MySQL的INT类型参数与数据大小有关,这是一个常见的误解 - 它没有。 MySQL的INT数据类型总是32位。括号中的参数指的是使用ZEROFILL显示值时要填充的位数。例如。 INT(7)将显示0001234,其中INT(11)将显示00000001234.但此填充仅在显示值时发生,而不是在存储或数学计算期间。

答案 1 :(得分:6)

如果字段中的实际数据大小变化很大,则varchar更好,因为它会导致更小的记录,而较小的记录意味着更快的DB(更多记录可以适应缓存,更小的索引等)。出于同样的原因,如果您需要最大速度,使用较小的整数会更好。

OTOH,如果方差很小,例如一个字段最多有20个字符,大多数记录实际上是近20个字符,然后char更好,因为它允许DB进行一些额外的优化。但是,这真的只对表格中的所有字段都适用,因为那时你有固定大小的记录。如果速度是您主要考虑的问题,如果您的查询只使用固定大小的字段(或者您只有猎枪查询),那么将任何非固定大小的字段移动到单独的表中甚至是值得的。 / p>

最后,很难概括,因为很大程度上取决于您实际应用的访问模式。

答案 2 :(得分:4)

鉴于您的系统限制,我建议使用varchar,因为您对数据执行的任何操作都必须适应您使用固定宽度char的任何填充。这意味着更多的代码需要更多的代码来调试,并且更容易出错。话虽如此:

  

应用程序的主要瓶颈是每五分钟丢弃并重新创建数据库。你不会通过选择char over varchar等微增强功能获得很多性能优势。我相信你有一些更严重的架构问题需要解决。 - 公主

我同意上述评论。在你可以担心char和varchar之间的区别之前,你有更大的鱼在你的建筑中煎炸。首先,如果您有一个Web用户尝试运行即席查询并且数据库正在重新创建过程中,您将收到错误(即“数据库不存在”或只是“超时”类型问题)。

我建议您(至少)构建最近报价数据(带时间戳)的报价表,股票代码表和历史表。您的Web用户将根据自动收报机表查询以获取最新数据。如果一个符号在你不存在的5分钟文件中出现,那么在将新信息发布到报价表之前让导入脚本创建它就足够简单了。所有其他人都会更新,查询默认为当天的数据。

答案 3 :(得分:1)

我绝对不会每次都重新创建数据库。相反,我会做以下事情:

  • 读入更新/快照文件,并根据每一行创建一些对象。
  • 每行
  • 获取符号/选项名称(唯一)并在数据库中设置

如果是我,我还会有一个内存缓存中的所有符号和当前价格数据。

价格数据绝不是一个整数 - 你可以使用字符。

公司名称可能不是唯一的,因为特定公司有很多选项。这应该是一个索引,您可以使用公司的ID来节省空间。

正如其他人也指出的那样 - 您的Web客户端不需要访问实际数据库并进行查询 - 您可能只需点击缓存即可。 (尽管这实际上取决于您向客户公开的表格和数据以及他们想要的数据)

拥有其他用户的查询权限也是不能继续删除和创建数据库的理由。

答案 4 :(得分:1)

还要记住,创建数据库取决于您使用的任何实际数据库实现。如果你曾经从MySQL移植到Postgresql,你会发现一个非常令人不快的事实,即在postgresql中创建数据库是一个相对非常慢的操作。例如,它比读取和写入表行慢几个数量级。

在优化性能选择正确的数据类型之前,首先要解决应用程序设计问题。