MySQL 表定义的性能建议答案

【问题标题】：Performance suggestions for a MySQL table definitionMySQL 表定义的性能建议
【发布时间】：2012-10-10 19:01:24
【问题描述】：

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

我有一个数据库表，用于存储客户对调查的回复。由于调查问题会根据客户 i 而变化，而不是定义表模式使用每个 questionid 作为列来定义它如下

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

地点：

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

questionkey：是问题的简码例如年龄、性别等

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

在这个设计中，customerid、partkey、questionkey 和 version 是主键。

我担心这种设计的性能。我应该将其他主键定义为索引吗？那会有帮助吗？到目前为止，对于 30 个客户，我有 7000 条记录。我预计最多有300-500。你怎么看？

【问题讨论】：

这种大小的数据库对于 mysql 即使在速度较慢的标准笔记本电脑上也不是挑战。
请发布您的架构，也许还有一些示例查询！

标签： mysql sql normalization

【解决方案1】：

听起来像一个很小的数据库。我怀疑您会遇到性能问题，但如果您稍后在查询partkey、questionkey 或version 时检测到任何问题，您可以随时添加一个或多个索引来解决问题。没有必要解决您没有并且可能永远不会遇到的性能问题。

只有当您必须执行不使用customerid 字段作为主要过滤器的时间敏感查询时，才会出现性能问题。我怀疑你会有一些这样的查询（当你想在客户之间聚合数据时），但我怀疑它们的时间敏感度足以受到我期望从这样的一秒或更短的响应时间的影响小数据集合。如果是，则添加索引。

另外，请注意一个表只有一个主键。该键可以使用多个列，因此您可以说列 customerid、partkey、questionkey 和 version 是主键的一部分，但你不能说出他们所有的“主键”。

【讨论】：

我明白了，所以在这种情况下，由于大多数查询都是使用 where 子句中定义的 customerid、partkey、questionkey 和 version 进行的。因此，将 partkey、questionkey 和 version 作为索引肯定会有所帮助。正确吗？
不，相反。如果您的所有查询都以可以使用索引的形式涉及 customer_id（如果条件为 customer_id =，则始终为真），那么您已经获得了使用由主键创建的索引进行索引的大部分好处。只有当您有不包含customer_id =的查询时，您可能需要考虑其他索引。

【解决方案2】：

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

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

【讨论】：