LES REQUÊTES NE S'EXÉCUTENT PAS TOUJOURS EN PARALLÈLE
Cela dépend du moteur de base de données. Avec MyISAM, presque chaque requête acquiert un verrou au niveau de la table, ce qui signifie que les requêtes sont exécutées séquentiellement en file d'attente. Avec la plupart des autres moteurs, ils peuvent fonctionner en parallèle.
echo_me dit nothing happens at the exact same time and a CPU does not do everything at once
Ce n'est pas tout à fait vrai. Il est possible qu'un SGBD puisse s'exécuter sur une machine avec plus d'un processeur et avec plus d'une interface réseau. C'est très improbable que 2 requêtes puissent arriver en même temps - mais pas impossible, il existe donc un mutex pour s'assurer que la transition paring/exécution ne s'exécute que comme un seul thread (d'exécution - pas nécessairement le même processus léger).
Il existe 2 approches pour résoudre le DML simultané - soit utiliser des transactions (où chaque utilisateur obtient effectivement un clone de la base de données) et lorsque les requêtes sont terminées, le SGBD essaie de réconcilier les modifications - si la réconciliation échoue, le SGBD annule l'un des les requêtes et les signale comme ayant échoué. L'autre approche consiste à utiliser le verrouillage au niveau des lignes - le SGBD identifie les lignes qui seront mises à jour par une requête et les marque comme réservées pour la mise à jour (les autres utilisateurs peuvent lire la version originale de chaque ligne mais toute tentative de mise à jour des données sera bloqué jusqu'à ce que la ligne soit à nouveau disponible).
Votre problème est que vous avez deux clients mysql, chacun ayant récupéré le fait qu'il reste un article en stock. Ceci est encore compliqué par le fait que (puisque vous mentionnez PHP) les niveaux de stock peuvent avoir été récupérés dans une session SGBD différente de l'ajustement de stock ultérieur - vous ne pouvez pas avoir une transaction s'étendant sur plus d'une requête HTTP. Par conséquent, vous devez revalider tout fait maintenu en dehors du SGBD au sein d'une seule transaction.
Le verrouillage optimiste peut créer un pseudo - mécanisme de contrôle des transactions - vous marquez un enregistrement que vous êtes sur le point de modifier avec un horodatage et l'identifiant de l'utilisateur (avec PHP, l'ID de session PHP est un bon choix) - si lorsque vous venez de le modifier, quelque chose d'autre l'a changé, alors votre code sait que les données qu'il a récupérées précédemment sont invalides. Cependant, cela peut entraîner d'autres complications.
