No, non ci sono garanzie. A meno che non specifichi un ordine utilizzando un ORDER BY clausola, l'ordine è totalmente dipendente dai dettagli interni di attuazione. Cioè. ciò che è più conveniente per il motore RDBMS.
In pratica, le righe potrebbero essere restituiti nell'ordine di inserimento originale (o più precisamente nell'ordine in cui le righe sono presenti nella memoria fisica), ma non dovresti dipendere da questo. Se porti la tua app su un'altra marca di RDBMS, o anche se esegui l'upgrade a una versione più recente di MySQL che potrebbe implementare lo storage in modo diverso, le righe potrebbero tornare in un altro ordine.
Quest'ultimo punto vale per qualsiasi RDBMS conforme a SQL.
Ecco una dimostrazione di cosa intendo per ordine in cui le righe sono in archivio, rispetto all'ordine in cui sono state create:
CREATE TABLE foo (id SERIAL PRIMARY KEY, bar CHAR(10));
-- create rows with id 1 through 10
INSERT INTO foo (bar) VALUES
('testing'), ('testing'), ('testing'), ('testing'), ('testing'),
('testing'), ('testing'), ('testing'), ('testing'), ('testing');
DELETE FROM foo WHERE id BETWEEN 4 AND 7;
+----+---------+
| id | bar |
+----+---------+
| 1 | testing |
| 2 | testing |
| 3 | testing |
| 8 | testing |
| 9 | testing |
| 10 | testing |
+----+---------+
Quindi ora abbiamo sei righe. Lo spazio di archiviazione a questo punto contiene uno spazio tra le righe 3 e 8, lasciato dopo aver eliminato le righe centrali. L'eliminazione di righe non deframmenta questi spazi vuoti.
-- create rows with id 11 through 20
INSERT INTO foo (bar) VALUES
('testing'), ('testing'), ('testing'), ('testing'), ('testing'),
('testing'), ('testing'), ('testing'), ('testing'), ('testing');
SELECT * FROM foo;
+----+---------+
| id | bar |
+----+---------+
| 1 | testing |
| 2 | testing |
| 3 | testing |
| 14 | testing |
| 13 | testing |
| 12 | testing |
| 11 | testing |
| 8 | testing |
| 9 | testing |
| 10 | testing |
| 15 | testing |
| 16 | testing |
| 17 | testing |
| 18 | testing |
| 19 | testing |
| 20 | testing |
+----+---------+
Nota come MySQL ha riutilizzato gli spazi aperti eliminando le righe, prima di aggiungere nuove righe alla fine della tabella. Si noti inoltre che le righe da 11 a 14 sono state inserite in questi spazi in ordine inverso, riempiendo dall'estremità all'indietro.
Pertanto l'ordine in cui sono memorizzate le righe non è esattamente l'ordine in cui sono state inserite.
AGGIORNAMENTO:questa dimostrazione che ho scritto nel 2009 era per MyISAM. InnoDB restituisce le righe nell'ordine dell'indice a meno che non utilizzi ORDER BY. Questa è un'ulteriore prova del punto all'inizio della risposta che l'ordine predefinito dipende dall'implementazione. L'utilizzo di un motore di archiviazione diverso significa un'implementazione diversa.
