AS CONSULTAS NEM SEMPRE SÃO EXECUTADAS EM PARALELO

Depende do mecanismo de banco de dados. Com o MyISAM, quase todas as consultas adquirem um bloqueio de nível de tabela, o que significa que as consultas são executadas sequencialmente como uma fila. Com a maioria dos outros motores, eles podem funcionar em paralelo.

echo_me diz nothing happens at the exact same time and a CPU does not do everything at once

Isso não é exatamente verdade. É possível que um DBMS possa ser executado em uma máquina com mais de uma CPU e com mais de uma interface de rede. É muito improvável que 2 consultas possam chegar ao mesmo tempo - mas não impossível, portanto, há um mutex para garantir que a transição de paring/execução seja executada apenas como um único thread (de execução - não necessariamente o mesmo processo leve).

Existem 2 abordagens para resolver DML concorrente - ou para usar transações (onde cada usuário efetivamente obtém um clone do banco de dados) e quando as consultas forem concluídas, o DBMS tenta reconciliar quaisquer alterações - se a reconciliação falhar, o DBMS reverterá um dos as consultas e relata como falha. A outra abordagem é usar o bloqueio em nível de linha - o SGBD identifica as linhas que serão atualizadas por uma consulta e as marca como reservadas para atualização (outros usuários podem ler a versão original de cada linha, mas qualquer tentativa de atualizar os dados será bloqueado até que a linha esteja disponível novamente).

Seu problema é que você tem dois clientes mysql, cada um dos quais recuperou o fato de que há um item de estoque restante. Isso é ainda mais complicado pelo fato de que (já que você mencionou PHP) os níveis de estoque podem ter sido recuperados em uma sessão DBMS diferente do ajuste de estoque subsequente - você não pode ter uma transação abrangendo mais do que uma solicitação HTTP. Portanto, você precisa revalidar qualquer fato mantido fora do SGBD em uma única transação.

O bloqueio otimista pode criar um pseudo - mecanismo de controle de transações - você sinaliza um registro que está prestes a modificar com um carimbo de data e hora e o identificador de usuário (com PHP, o ID de sessão PHP é uma boa escolha) - se quando você for modificá-lo, outra coisa mudou, então seu código sabe que os dados recuperados anteriormente são inválidos. No entanto, isso pode levar a outras complicações.