在MYSQL中使用SELECT MAX(id)而不是在PHP中使用mysql_insert_id()有多糟糕?

DrM*_*MHC 12 php mysql concurrency mysql-insert-id

背景:我正在开发一个系统,开发人员似乎正在使用一个执行MYSQL查询的函数,就像"SELECT MAX(id) AS id FROM TABLE"他们需要获取LAST插入行的id(具有auto_increment列的表)一样.

我知道这是一种可怕的做法(因为并发请求会使记录混乱),而我正在尝试将其传达给非技术/管理团队,他们的回应是......

"Oh okay, we'll only face this problem when we have 
(a) a lot of users, or 
(b) it'll only happen when two people try doing something
    at _exactly_ the same time"
Run Code Online (Sandbox Code Playgroud)

我不同意这两点,并认为我们会比计划更早地遇到这个问题.但是,我正在尝试计算(或计算一种机制)来计算在我们开始看到混乱链接之前应该使用系统的用户数量.

对此的任何数学见解?再说一次,我知道这是一个可怕的做法,我只是想了解这种情况下的变量......


更新:感谢评论人员 - 我们正朝着正确的方向前进并修复代码!

irc*_*ell 5

如果潜在的不良情况可能发生,那就不是重点.重点是它们是否可行.只要存在问题的非平凡概率,如果知道它应该被避免.

这不像我们正在谈论将一行函数调用更改为5000行怪物来处理远程可能的边缘情况.我们谈论的是实际上缩短了对更可读和更正确用法的调用.

我同意@Mark Ba​​ker的一些性能考虑因素,但由于id它是主键,因此MAX查询速度非常快.当然,它LAST_INSERT_ID()会更快(因为它只是从会话变量读取),但只是一个微不足道的数量.

而且您不需要很多用户就可以实现这一目标.您所需要的只是很多并发请求(甚至不是很多).如果之间的时间开始的插入和选择的开始是50毫秒(假设交易安全DB引擎),那么你只需要每秒20个请求开始打这个问题始终.关键是错误的窗口是非平凡的.如果你说每秒20个请求(实际上并不是很多),并假设普通人每分钟访问一页,你只会说1200个用户.这就是经常发生的事情.只有2个用户可能会发生一次.

关于这个主题MySQL文档:

You can generate sequences without calling LAST_INSERT_ID(), but the utility of 
using the function this way is that the ID value is maintained in the server as 
the last automatically generated value. It is multi-user safe because multiple 
clients can issue the UPDATE statement and get their own sequence value with the
SELECT statement (or mysql_insert_id()), without affecting or being affected by 
other clients that generate their own sequence values.
Run Code Online (Sandbox Code Playgroud)