Non, il n'y a aucune garantie. Sauf si vous spécifiez une commande à l'aide d'un ORDER BY clause, la commande dépend totalement des détails de mise en œuvre internes. C'est à dire. ce qui est le plus pratique pour le moteur RDBMS.
En pratique, les lignes pourraient être renvoyés dans leur ordre d'insertion d'origine (ou plus précisément l'ordre dans lequel les lignes existent dans le stockage physique), mais vous ne devez pas en dépendre. Si vous transférez votre application vers une autre marque de RDBMS, ou même si vous effectuez une mise à niveau vers une version plus récente de MySQL qui peut implémenter le stockage différemment, les lignes peuvent revenir dans un autre ordre.
Ce dernier point est vrai pour tout SGBDR compatible SQL.
Voici une démonstration de ce que j'entends par l'ordre dans lequel les lignes existent dans le stockage, par rapport à l'ordre dans lequel elles ont été créées :
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 |
+----+---------+
Alors maintenant, nous avons six rangées. Le stockage à ce stade contient un espace entre les lignes 3 et 8, laissé après la suppression des lignes du milieu. La suppression de lignes ne défragmente pas ces espaces.
-- 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 |
+----+---------+
Remarquez comment MySQL a réutilisé les espaces ouverts en supprimant des lignes, avant d'ajouter de nouvelles lignes à la fin de la table. Notez également que les lignes 11 à 14 ont été insérées dans ces espaces dans l'ordre inverse, en remplissant de la fin vers l'arrière.
Par conséquent, l'ordre dans lequel les lignes sont stockées n'est pas exactement l'ordre dans lequel elles ont été insérées.
MISE À JOUR :Cette démonstration que j'ai écrite en 2009 était pour MyISAM. InnoDB renvoie les lignes dans l'ordre de l'index sauf si vous utilisez ORDER BY. Ceci est une preuve supplémentaire du point au début de la réponse que l'ordre par défaut dépend de l'implémentation. L'utilisation d'un moteur de stockage différent signifie une implémentation différente.
