请考虑这是一个用于Web开发的MySQL问题。
目前我正在为用户身份验证系统设计数据库结构，我遇到了一个问题，我自己无法理解：
拥有重复数据而不是进行更多查询会更好吗？
这是一个小背景，目前我的用户表看起来像这样（伪代码）：
id mediumint
username varchar(15)
password varchar(100)
email varchar(80)
status tinyint(1) <- is the user banned?
language varchar(100)
private_message_counter mediumint
notify_email tinyint(1)
Extra rows
我正在尝试将所有“最常用”的行放入users表中，以防止更多查询，例如：
With Indicator on users table:
-
User Logged on? (query Sessions)
Get User Data (query Users)
Get User Permissions (query permissions)
-
Without indicators:
-
User Logged on? (query Sessions)
Is the user Banned? (query Bans)
Get User Data (query Users)
Get User Permissions (query Permissions)
Get Private Message information (query private_messages table)
一个小“问题”是用户表以很多行结束。显而易见的是，我需要运行更多检查以防止数据不匹配，但改进方式不是更好吗？
注意：我的网站有大约14,500个并发用户连接。所以我需要知道它是否会改善或完全相反。
欢迎任何意见或建议。
答案 0 :(得分：2)
非常非常非常很少是正确的答案数据重复。我们经常谈论normalization的原因。
通常，您只在离线数据仓库情况下复制数据，在这种情况下，您要处理10s +数百万行，并且聚合的处理时间太长。在一个在线系统中，数据失去同步的风险几乎总是太大，无法从复制数据中获得任何感知收益。一些额外的查询不会杀了你。
答案 1 :(得分：1)
是否存在一个实际的性能问题，即聪明的UNION语句无法解决？
我不会超载表以获得短期性能。你的桌子越大，你就会牺牲你的正常运行时间（发生在我身上）。您的应用程序中可能需要多层缓存。 （对于会话+权限的禁止状态和物化视图的memcached的某种组合可能吗？）
我建议运行测试，以便在将表中数据的行数和100,000个并发用户的数量比例缩放后查看结果。您可以通过在当前用户和频繁用户之间以及用户频率较低的情或者遵循拥有处理会话的服务器和处理规范数据的服务器的概念。
在我的项目中，我的用户中只有约0.01％的用户同时登录。如果您有1％的用户登录，则您将扩展到百万行范围。我建议考虑如何保持正常运行时间要求和一些基本性能要求。表修复，优化和备份：这些操作在多主机架构中并不便宜并且很棘手。 （考虑表分区？）
在较小的表上执行时，更新（和修复）操作的成本较低。他们不仅不太可能从mysql查询缓存中删除大量缓存查询，还可以保持更好的密钥缓存性能。如果您的用户表经常更新，则应将经常更新的列与不常见的更新列分开。您的密钥缓存命中率将会提高，查询缓存命中率也会提高。
如果你真的计划发展这个应用程序，你必须每天处理更多的查询，无论如何。如果您的应用程序在查询率仅加倍时遭受损失，则表示出现问题。根据我的经验，将数据复制到用户表中（主数据模型）会使执行其他数据表变得更加困难 - 这可能很难摆脱。