我有几个关于不使用索引是否最好的问题。
背景：我的记录有时间戳属性，记录会按照时间戳的顺序插入（即按时间顺序插入）。
问题：
如果我不使用索引，数据库是否通常按照插入的顺序插入记录？
如果对#1 的回答是肯定的，那么当我执行“SELECT .. WHERE timestamp > X”类型查询时，数据库是否会有效，或者它是否必须遍历每条记录，因为它没有被索引？我假设如果没有索引，数据库将不会“知道”记录是按排序顺序插入的，因此无法使用数据库的排序属性。
我认为聚集索引最适合这些类型的记录及其插入。
请让我知道你们的想法。
谢谢，jbu
以我的经验，是的，数据库会按时间顺序插入内容，尤其是在您从不删除任何内容的情况下。但是，这并不能保证，并且尝试依赖无法保证的行为是一个非常糟糕的主意。
此外，查询规划器不会知道这一事实，因此您在没有索引的情况下执行的任何查询都会导致全表扫描。这是否比索引查询慢在很大程度上取决于您拥有的数据类型，以及查询中“X”之后的百分比。
聚集索引是记录在磁盘上存在的顺序。无论您是否指定一个，总会有一个，因为磁盘上必须有一个订单。
主键也是聚集索引是正常的，但不一定是这种情况。
如果您正在执行批量插入，您可能会插入多个具有相同时间戳的记录。显然，这不能成为主键。
为了执行像“SELECT .. WHERE timestamp > X”这样的查询，“timestamp”字段上的索引将提高该查询的性能，无论它是否是集群的。
'timestamp' 字段上的索引是否应该聚集以及是否还需要其他索引将取决于您需要对数据执行的所有查询。
当然，这取决于您使用的数据库！
一般来说，如果你有很多插入要做，最好禁用索引，执行插入，然后重新创建索引
使用时间戳作为聚集索引（即存储行的顺序）仅在您最常见的查询按时间顺序（而不是检索此行）并且没有重复的时间戳时才重要
如果表中从未有任何删除，您可以假设数据库将简单地将新块添加到表的末尾。但是，不能保证磁盘上的这些块是否是连续的，或者是否正确推进（即，表很可能会随着时间的推移而碎片化）。
来自没有索引的表的任何 SELECT 都将导致表扫描。索引是您如何“告诉”数据库有关“时间戳按升序排列”之类的信息。
聚集索引可以很好地告诉数据库您希望在表中保持行的索引顺序。但是，它通常（取决于您的实现）仅对合理的静态数据有价值，因为这是数据库确保表的行确实按索引顺序排列的唯一方法，因为它通过重建表来做到这一点。
什么数据库？
1）
没有索引的表称为堆。堆将按照插入的顺序存储记录。只要您不从多个线程插入，您就可以预测数据库存储记录的顺序。正如其他人指出的那样，这确实假定您不进行删除，在这种情况下您的 DBMS 可能用新行填充空白页面。
2)
如果没有索引，DBMS 将不得不进行一次完整的表扫描（它以与记录数相关的线性时间运行）。对于插入时间戳增加的记录的记录，聚集索引会很好。只要您不插入旧时间戳，DBMS 就必须重新排列由于聚集索引而物理上的行。
我是帖子创建者jbu。
感谢大家的快速输入。
要解决更多问题：
是的，我有静态数据 - 我不会删除。
我正在测试几个不同的数据库：Sybase SQL Anywhere、Oracle Berkeley DB、H2、Firebird、SQLite，可能还有其他一些。
致 Steven Lowe：我的表将有数百万条记录（最多会增长到 32GB）。如果我关闭索引一段时间，然后重新创建索引，那会不会需要很长时间 - 至少几分钟（我会假设它可能需要更长的时间）？另外，我认为您假设插入的连续流动将会中断。我几乎会一直使用批量插入提交进行插入，所以我认为我的 CPU 和磁盘永远不会真正有休息时间来重新索引。
再次，感谢输入的家伙。
朱布
这是典型的，但任何特定的实现都不能保证，AFAIK。因此，依赖它是不明智的。查询优化器也不依赖它，因此它会进行表扫描。
在您的情况下，时间戳上的聚集索引确实没有缺点。你可以填满 100% 的数据页，但你仍然不会比堆更糟。然而，查询可以利用它，并且可以从略微（如果您返回，例如，90% 的表格）到可笑（如果您要返回，例如，1% 的表格）更快.
我相信根据 sql 标准，您永远无法确定在非有序列中选择行的顺序。即使您测试给定的数据库并发现它当前是正确的，但在数据库的下一个修订版中可能并非如此。我的经验秒 Steven Lowe's。如果要在表中插入大量行，请在插入之前禁用（或删除）这些行。插入后重新创建索引将比打开索引的插入花费更少的时间。
艾伦
您需要在时间戳列上创建一个索引才能搜索我的时间戳。做它（TM）。
聚集索引仅在您按主键搜索时对您有帮助。您可以将时间戳作为主键来利用它。