いいえ、保証はありません。 ORDER BY
を使用して注文を指定しない限り 条項では、順序は内部実装の詳細に完全に依存しています。つまりRDBMSエンジンにとって最も便利なものは何でも。
実際には、行は可能性があります 元の挿入順序(より正確には、行が物理ストレージに存在する順序)で返されますが、これに依存しないでください。アプリを別のブランドのRDBMSに移植した場合、またはストレージの実装が異なる可能性のある新しいバージョンのMySQLにアップグレードした場合でも、行が別の順序で戻ってくる可能性があります。
後者の点は、SQL準拠のRDBMSに当てはまります。
これは、行がストレージに存在する順序と、行が作成された順序の意味を示しています。
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 |
+----+---------+
これで6行になりました。この時点でのストレージには、中央の行を削除した後に残った行3と8の間にギャップがあります。行を削除しても、これらのギャップは最適化されません。
-- 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 |
+----+---------+
テーブルの最後に新しい行を追加する前に、MySQLが行を削除して開いたスペースをどのように再利用したかに注目してください。また、行11から14がこれらのスペースに逆の順序で挿入され、最後から後ろに向かって埋められていることにも注意してください。
したがって、行が格納される順序は、行が挿入された順序と正確には一致しません。
更新:2009年に私が書いたこのデモンストレーションは、MyISAM用でした。 ORDER BYを使用しない限り、InnoDBはインデックス順に行を返します。これは、デフォルトの順序が実装に依存するという回答の開始時のポイントのさらなる証拠です。別のストレージエンジンを使用するということは、別の実装を意味します。