问题标签 [database-performance]

我有一个用户驱动的网站。我想添加消息传递功能。我的担忧围绕着我的数据库的可管理性和性能。

我正在考虑这样组织它：我有我的用户表，我的所有用户都有唯一的 id 两个用户之间的任何用户发起的对话都会在“对话”中记录，并且该对话中的所有消息都将使用引用的外键那个conversation_id。

谁能想到不采用这种方法的任何理由？我想知道如果我使用索引并将查询限制为每页约 20 个结果，它的长期性能会如何。

编辑：我意识到我无法追踪谁是发件人/收件人。我的第一直觉是简单地添加一个“发件人”列到 conversations_messages

我正在尝试针对由 6 个表构建的 Oracle 视图优化一些遗留 SQL SP，每个表由相同的字段连接，一个数字 ID。视图中的一些表有一个索引，它完全是这个 ID 字段，其他的则没有。

如果我只使用此字段在视图中的其余表上创建索引，然后使用此字段作为唯一参数执行实际的选择查询，它会显着提高性能吗？如果有必要，我可以发布 s.proc，因为 SP 中可能存在其他可能无法通过单独索引来解决的缺陷。有问题的查询需要大约 6 秒才能返回 1 行，没有一个表包含大量记录，无论如何也不超过 100,000 条记录。

提前致谢，

斯科特

我们一直在经历 SQL 超时，并确定瓶颈是审计表——我们系统中的所有表都包含插入、更新和删除触发器，这些触发器会导致新的审计记录。

这意味着审计表是系统中最大和最繁忙的表。然而，数据只进不出（在这个系统下），所以不需要select性能。

运行select top 10返回最近插入的记录而不是“第一条”记录。 order by当然可以，但我希望 select top 应该根据它们在磁盘上的顺序返回行——我希望这会返回最低的 PK 值。

有人建议我们删除聚集索引，实际上也删除主键（唯一约束）。正如我之前提到的，select在这个系统中不需要从这个表中获取。

聚集索引会对表产生什么样的性能影响？拥有一个无索引、非集群、无键表的（非选择）后果是什么？还有其他建议吗？

编辑

我们的审计涉及 CLR 功能，我现在正在使用和不使用 PK、索引、FK 等进行基准测试，以确定 CLR 功能和约束的相对成本。

经调查，性能不佳与insert报表无关，而是与协调审计的 CLR 功能有关。移除 CLR 并使用直接的 TSQL proc 后，性能提高了 20 倍。

在测试期间，我还确定聚集索引和标识列对插入时间的影响很小或没有影响，至少相对于发生的任何其他处理而言。

我有这个查询来检索（见下文，为简单起见）搜索工作数据。我们正在处理大约一百万条记录。

笔记：

我不能使用常规联接，因为我需要通过将 jobId 传递给 REETEXTTABLE 来找到加权等级。

问题：

它非常慢。

显然问题是比较计算列。

如果我起飞 Where SearchKeyMatchRank>0 它需要不到一秒钟。

有人知道我们如何改进这一点吗？

现在建议的表结构是：-

或者

执行了哪些查询？展示次数每秒大约有 500 次更新。每秒大约有 1 次点击更新。ctr 每秒大约有 500 次更新。

现在我的应用程序使用 ctr 对数据进行排序。ctr 是由 计算得出的点击率ctr = clicks/impressions。现在我意识到，除非有点击更新，否则 ctr 不需要更新，因为文章的所有印象都在增加，这会降低相同关系中的 ctr，所以除非有点击，否则 ctr 不需要被更新。

目前更新查询类似于“UPDATE data_table SET 展示次数 = 展示次数 + 1，ctr = 点击次数 / 展示次数 WHERE something = something

这意味着尽管一次更新了 2 个字段，但只执行了 1 个查询。

现在的瓶颈是这 500 次更新导致此表上的选择变慢。每秒大约有 20 次选择。所以我想把桌子分开。新的表格样式建议更新发生在单独的表格上，选择发生在单独的表格上。包含展示次数的数据表更新非常频繁，因此对其执行的展示次数进行更新确实加快了该表的性能。这意味着 data_table_2 上的选择也会更快，并且每次有人点击时都可以更新 ctr。

所以，我只是想知道我是否应该使用新的表结构。你有什么建议？我的建议的优点和缺点！

I am building a community site where logon will be by email and members will be able to change their name/nick name.

Do you think I should keep member name/nick name in my members table with other properties of member or create another table, write member name/nick name on that table and associate member’s id.

I am in favour of second option because, I think it would be faster to pull members name from it.

Is it right/better way?

Update: reason is for other table is that I need to pull username for different sections. For example forums. Wouldn't it be faster to query a small table for each username for each post in a from topic?

我将 URL 保存在数据库中，当我插入一个新 URL 时，我想检查该 url 是否已存在于数据库中。

一种常见的做法（如果我没记错的话）是使用 md5 或 sha-1 等对 url 进行哈希处理......并在插入新字段之前检查数据库中的该字段是否重复。

我知道 md5 会产生碰撞，sha-1 也...

你对我有什么建议？我的需求是：

• 数据库大小：数据库上最终有 10 到 20 百万条记录

• 性能/速度：小哈希大小，因此数据库不会对重复项进行繁重的负载检查（该字段当然会有索引）

• 容忍度：我不在乎每 100,000 条记录是否有 1 次碰撞。我的需求更多的是性能（小哈希）而不是 0% 冲突（大哈希）。

• 恶意 URL 攻击以故意产生冲突的可能性：极低

• 在这种成功攻击的情况下可能造成的最大伤害：极低

问题：

• 你相信 md5 就足够了吗（有更好的建议）？

• 也许 md5 对我来说甚至是矫枉过正，我真的可以通过使用更简单的东西来获得性能优势？

提前谢谢你们！

我在排序的查询上遇到了一些负面的表现。

这是 NHibernate 生成和呈现查询的方式：

粗体部分（在 ** 符号内）正在获取所有结果并将它们按顺序排列 - 这需要时间。有什么办法可以让这个查询更有效率吗？我只是想让排序和分页成为可能，而不必产生太多开销。

我正在使用 NHibernate 2.1。未来版本中与我的问题相关的任何改进？

最好的问候， 马蒂亚斯

我检查了这个 SO 帖子：

MySQL中的主键、唯一键和索引有什么区别？

并找到了声明：

另请注意，定义为主键或唯一键的列会在 MySQL 中自动建立索引。

基于此，我有两个问题：

• 我是否可以安全地假设在主键本身上创建索引没有性能优势，因为根据设计，主键是索引？

也许更重要的问题是：

• 如果您正在做人们引用的经典示例，基于 lastName 和 firstName 执行 SELECT，并且该表也有一个您经常选择的主键，您会将索引创建为 (primary_key, lastName, firstName) 还是仅创建 (lastName , firstName) 因为主键已经是索引？

尽管像 Joomla 这样的一些主要系统将标签作为逗号分隔的文本存储在主文章数据库中，但首选三张表作为文章、标签和标签关系的规范化系统（正如 Wordpress 等其他系统所使用的那样）。有很多关于结构和阅读的讨论和问题；但我找不到最好的 INSERT 命令，因为我们需要插入三个表。如何通过一次 SQL 运行快速运行这个过程？或者我们需要先插入文章，然后每个标签，最后写关系？

另一个问题是关于标签的唯一性。这个系统的主要优点是我们只需要存储每个术语一次（然后连接到相应的文章）。使用 mysql UNIQUE 避免重复是否可行？或者（正如我在某处读到的）我们需要将整个标签列表作为数组读取，以查找任何重复项以捕获标签 ID 并避免存储该术语？

将整个过程分为三个单独的步骤：

1. 插入文章
2. INSERT 带有 UNIQUE 的标签，但不管它们的关系如何
3. 查找每个标签 ID 并与文章 ID 建立关系

我对吗？我问的原因是我看到人们将标签作为数组捕获并进行比较。对我来说它非常慢，并且会影响性​​能，尤其是对于 UPDATE。