瓶颈问题mysql答案

【问题标题】：bottleneck issue mysql瓶颈问题mysql
【发布时间】：2012-07-10 06:46:56
【问题描述】：

我有这个项目拍卖门户，问题是有时用户无法出价或更好的词是请求出价有时需要2-3秒才能注册，冲突是在系统检测到有人出价之前，拍卖已经结束。

我添加了一个日志来查看发生了什么，这是我发现的：

Bid insert date        |    Auction close date
2012-06-25 14:40:57         2012-06-25 14:40:54

如您所见，拍卖已经结束，但出价处理晚了 3 秒。澄清一下，如果拍卖已经结束，用户将无法出价，所以我确信该请求是在结束之前提出的。

这发生在每天 1 次拍卖中，我不知道是什么引发了这个问题。我正在使用 PHP 和 MySQL。

【问题讨论】：

您能否提供一些关于您的网站是如何托管的信息？它只是一个 LAMP 服务器还是您有多个服务器，如果您使用哪种硬件和负载平衡。此外，有关您获得多少流量的信息将有助于确定这是否是您的代码或硬件的问题。
我们是否应该想象一下您的硬件、代码、您使用的查询等等？还是我们应该点击您提供的链接？
我们使用的是windows服务器，我对我们的服务器规格不熟悉。但我认为它足以支持每个请求。流量还没有那么高，因为只有不到 200 名成员，而且大多数人都不活跃。有正在运行的 mysql 事件在 X 秒内运行，用于检查每次拍卖的状态以及是否有人代表投标人设置了自动投标。我怀疑是mysql配置，但不知道要检查什么，我已经将一些表迁移到innoDB，因为大多数表都在变化
把问题转过来，有关系吗？如果您只关心用户在拍卖结束之前提交了出价，那么这可能没问题。如果你只是想知道是什么让你的服务器变慢了，那么主要检查的是任何需要几秒钟才能运行并且可能隐式锁定表的 mysql 语句。
服务时间将始终> 0，无论您优化到多少。所以你的业务逻辑必须应对这场竞赛。当您插入出价时，添加一个子句“when now()

【解决方案1】：

一个可能的原因是用户加载了包含“出价”按钮的页面，拍卖结束，按钮仍然存在并且相应地执行了操作。如果您要验证拍卖是否在插入前结束，则永远不会发生这种情况。 SELECT 和 INSERT 之间的时间不应大于 0.1 秒。我假设您在添加最后一个出价之前没有验证拍卖状态。

【讨论】：

正如我所提到的。如果拍卖已经结束，用户将无法出价和登录。有某种过程会导致瓶颈至少在一两天内发生一次。逻辑和验证都是正确的。
@Rafael 很好，你说逻辑是正确的，但如果你知道问题是什么，你就不会在这里问，所以详细说明你正在做的检查可能会有所帮助- 如果可能，最好是实际代码。
@Rafael：这意味着您上次验证和插入之间的时间超过 3 秒。因此，我无视你的说法，即你的逻辑是正确的。我至少有点怀疑。
是mysql函数endtime是拍卖结束时间timenow is now(); IF endtime > timenow THEN /* 处理投标 */ END IF;我在我们的测试服务器上执行相同的程序，这比我们的生产服务器慢得多，但是我没有遇到同样的问题。我需要知道在获取记录以更新拍卖信息时我的表是否锁定，但我已经将引擎类型更改为 innoDB。我很确定这不再是逻辑问题。它更多的是关于 DB 或 apache 配置，但我不知道要检查或配置什么。
@Raphael 相对于数据库插入，您究竟在哪里执行此检查？您在问题 cmets 中说，该请求是在拍卖结束后收到的，因此如果将其保存到数据库中，那么显然此项检查存在问题。

【解决方案2】：

2-3 秒？

您在出价请求时运行了多少查询？我想：

1) 用户是否已登录？ 2) 是否有账户允许出价？ 3) 拍卖还开着吗？ 4) 发布出价

我不会想象这 4 个查询会花费超过一秒钟的时间来运行，除非您编写了非常糟糕的查询。您使用的是什么 MySQL DB 层？您是否确保您的代码尽可能精简？ IE。您多久打开一次数据库等。

如果他们出价并且拍卖在他们的出价被处理之前完成，那就太难了。你没有赢。同样的事情有时会在 eBay 上发生，而且很艰难。如果问题是您的系统允许延迟出价获胜，那么您需要在这方面重新访问您的代码。在保存出价之前，最后一次出价尝试肯定会检查拍卖是否仍在运行。这不应该花费任何时间。

也许您也应该查看表索引。太少，数据搜索慢，太多，影响数据插入速度。

可能有很多错误，从简单的索引错误到狡猾的查询/循环/等等。

【讨论】：

我对“您多久打开一次数据库”感兴趣。我不熟悉线程和/或数据库配置。我确信查询和索引都得到了很好的优化，大多数时候，当我尝试立即注册时。所以意味着处理非常快。但是在随机的时间，有人会抱怨用户出价但没有注册，这种情况每天只会发生1到2次。我不确定他们的互联网连接、打开的连接过多或数据库配置是否导致了这个问题

【解决方案3】：

不匹配确切的结束时间戳，但将其与（关闭时间-turnaround_time）。

假设关闭时间是 14:00:00，请求的周转时间是 10 秒。那么如果在 13:59:50 之前提出请求，则只会考虑。

【讨论】：