Ok, è quanto sapevo anch'io infatti.
Il mio obiettivo era quello di ottenere la certezza di poter estrarre l'ultimo inserimento nella tabella; normalmente ci si affida all'auto increment, oppure, se presente, ad un campo dedicato al datetime di inserimento, ma se parliamo di situazioni di grosso traffico aka inserimenti massivi in concorrenza, allora il dettaglio a livello di ora:minuti:secondi non è più sufficiente.
Avevo pensato perciò di usare i microsecondi, ma nella versione mysql che ho io non è ancora disponibile.
Ho usato quindi quelli restituiti da php (e anche qui sarebbe da aprire una parentesi tra le varie possibilità delle funzioni, gli arrotondamenti, i tipi di var restituite, etc.), ed è a questo punto che si sono evidenziati queste incongruenze.

L'unica spiegazione che mi sono dato è che il processo di inserimento, in quelle circostanze, è stato qualcosa di simile:

  1. per generare il next autoincrement l'engine esegue un MAX(id)+1
  2. il next autoincrement generato viene memorizzato temporaneamente nello schema db per poi essere usato per valorizzare il relativo campo
  3. collo di bottiglia
  4. nel frattemmpo viene memorizzata un'altra tupla, con lo stesso procedimento ovviamente, e che quindi prende o stesso next autoincrement precedentemente memorizzato dall'altro processo
  5. il collo di bottiglia finisce e il primo processo riprende
  6. al momento della memorizzazione si accorge che l'autoincrement non è valido poichè già presente
  7. ne genera un altro e lo usa per memorizzare la tupla


in questo modo è comprensibile il motivo per cui un record viene memorizzato dopo rispetto al suo successore (in termini temporali).


Ciao!!!