ad.如果列上有索引，DBMS只需读取几个索引项即可到达所需的行（前提是DBMS优化器在这里做得很好）。不，SQLite不保证没有按排序的任何内容。对于限制1，它更有可能（并且在十秒钟的测试中）返回它找到的第一行，而不是最后一行（即，它将在找到所需行数后立

---

ad.如果列上有索引，DBMS只需读取几个索引项即可到达所需的行（前提是DBMS优化器在这里做得很好）。不，SQLite不保证没有按排序的任何内容。对于

限制1

，它更有可能（并且在十秒钟的测试中）返回它找到的第一行，而不是最后一行（即，它将在找到所需行数后立即停止处理）。@TripeHound，Thorsten这个答案中的假设似乎对SQLite是正确的。我刚刚发现。在这个例子中，他们似乎给出了明确的输出，而不是带有“LIMIT”子句的可能输出。这是否意味着SQLite保证获取最新的按时间顺序排列的行？@iammilind不，这不是真的！首先，该示例显示了前六条（共七条）记录，而不是最后六条，因此（正如我所指出的）限制1通常会返回第一条记录，而不是最后一条记录。第二个“第一个”和“最后一个”没有

orderby

的意义，这是一个很糟糕的教程，暗示它们有意义。最后，虽然SQLite可能会重复返回“first”条目，但这并不能保证。在SQLite的情况下，我们可能不需要“orderby”。您想结合更新您的答案吗。@iammilind您参考的教程没有明确声明在没有

ORDER BY

的情况下进行订购。不幸的是，它通过举例的方式给人留下了错误的印象。请注意，即使它声明了某种形式的自然排序，它也不是第一个出错的教程。对于交叉检查，请考虑：“如果返回不止一行的SELECT语句不具有ORDER BY子句，则返回行的顺序未定义。”（强调雷）作为一个旁注，RDBMS实现中经常发生的一件事是某些事情使得排序看起来是一致的。它们遵循添加数据的特定算法，检索数据的特定算法。因此，它们的操作重复地看起来是相同的。例如，它可能会按顺序从聚集索引页检索，并似乎将聚集索引用作“自然排序”。。。直到有一天，页面拆分会将其中一个页面放在不同的位置。或者新版本的DMB可能会缓存某些数据以提高性能，并突然改变订单。这就是为什么特定订单的唯一保证是使用

orderby

子句。（“真实世界”示例：MS SQL Server 6实现的

groupby

的副作用是，当MS（在版本7 iirc中）时，也会按cols按组排序。）实施了一些性能改进，默认情况下，

groupby

将以散列顺序返回数据。许多人指责微软破坏了他们的查询，而事实上他们做出了错误的假设，并且未能根据需要对结果进行排序。）

SELECT * FROM <table> LIMIT 1;

SELECT  <cols>
FROM    <table>
ORDER BY <sort-cols> [DESC] LIMIT <no-rows>