MySQL表定义的性能建议

时间:2012-10-09 20:39:27

标签: mysql sql normalization

我关注数据库表的性能,我必须存储相关的数据 与客户调查应用程序。

我有一个数据库表,用于存储调查中的客户响应。由于调查问题根据客户而改变,而不是定义 使用每个questionid作为列的表模式将其定义如下

    customerdata(customerid  varchar, 
         partkey varchar, 
         questionkey varchar, 
         value, varchar,
         version, int,
         lastupdate, timestamp)

其中:

partkey:是零件的短代码(part1,part2 ......)

问题键:是问题的简称 例如年龄,性别等

由于一些客户填写了调查两次,三次等我添加了版本列。

使用此设计,customerid,partkey,questionkey和version是主键。

我担心这种设计的表现。我应该将其他主键定义为索引吗?那会有帮助吗?到目前为止,已有30位客户拥有7000条记录。我希望最多300-500。你怎么看 ?

2 个答案:

答案 0 :(得分:1)

听起来像一个非常小的数据库。我怀疑你会遇到性能问题,但如果你在以后查询partkeyquestionkeyversion时发现任何问题,你可以随时添加一个或多个索引来解决问题。时间。没有必要解决您没有的性能问题,也可能永远不会解决。

只有在必须执行不使用customerid字段作为主过滤器的时间敏感查询时,才会出现性能问题。我怀疑你会有一些类似的问题(当你想要跨客户汇总数据时)但我怀疑它们是否会对时间敏感度足以受到我希望从这样一个时间看到的一秒钟或更短的响应时间的影响小数据集。如果是,则添加索引。

另请注意,表只有一个PRIMARY KEY。该密钥可以使用多个列,因此您可以说列customeridpartkeyquestionkeyversion 的一部分PRIMARY KEY,但你不能说他们所有的“主键”。

答案 1 :(得分:-1)

rownumber-wise,我经历过超过100.000行的mysql数据库,它运行得很好所以你应该没问题。

虽然如果你运行复杂的查询是一个不同的情况,这更多地取决于数据库设计而不是行号。