【问题标题】:scaleability of failing transactions mysql失败事务mysql的可扩展性
【发布时间】:2011-04-25 15:04:23
【问题描述】:

我有一张表,用于存储从一个用户到另一个用户的消息。消息(用户 ID、朋友 ID、消息、创建日期)。我的主键是(friend_id,created_date)。这可以防止重复消息(AFAIK),因为它们将无法插入。

现在这没问题,因为我的代码每次为每个用户生成大约 20 个这样的查询,而我只有一个用户。但是,如果有成百上千的用户,这会在我的数据库中造成所有失败事务的瓶颈吗?如果我可以做些什么来改善这种情况?

编辑: 归结起来的问题是我应该使用主键约束,在 mysql 之外进行检查,还是使用其他一些 mysql 功能来将重复项排除在数据库之外?

【问题讨论】:

    标签: mysql transactions scalability


    【解决方案1】:

    应该没问题,因为 mysql 只会在内部进行主键查找并忽略记录(我假设您使用的是 INSERT IGNORE)。如果你在插入之前检查它们是否存在,mysql 仍然会在你插入时再次检查。这意味着如果大多数插入都会成功,那么您将节省额外的检查。如果绝大多数插入失败(不太可能),那么不发送不必要的数据所节省的成本可能会超过偶尔的重复检查。

    【讨论】:

    • 每个用户可能失败的事务数不是静态的。检索到的消息数量是静态的。因此,如果用户点击应用程序 2x 并且没有发送新消息,那么所有尝试插入的消息都将失败,因为它们已经在数据库中。所以我想我对你所说的答案感到困惑。我是用一个普通的插入语句保留它并让主键处理它还是我需要做其他事情?
    • @controlfreak123 我通常会说让主键来处理它,但也许你应该多解释一下你在做什么?人们为什么要重新插入消息?
    • @bernace 我无法控制用于检索每个用户的消息的 api。因此,如果我在用户收到其他消息之前请求用户消息,那么集合中将会有已经在数据库中的消息。如果我跟踪插入的最新消息的时间戳,我可以在插入之前将其与每条新消息进行比较。但在这方面,主键方法似乎更简单。尽管依靠插入无法实现我的目标似乎很不自然。因此我的问题
    • 如果你没有办法只选择新条目,那么我说继续使用“INSERT IGNORE”。这并不是一个更好的方法。
    • 好的,这就是我要找的。现在唯一的事情是我需要找到一种新方法来计算插入了多少记录,因为我使用的是 php,并且我正在计算查询返回 true 的次数(在 INSERT 中不使用 IGNORE)。
    猜你喜欢
    • 1970-01-01
    • 2012-05-20
    • 2011-03-02
    • 2012-12-08
    • 1970-01-01
    • 1970-01-01
    • 2019-06-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多