SQLite - 即使选择查询速度很快,我是否应该添加一些索引?

mon*_*ona 3 sqlite performance index performance-tuning

我有一个 SQLite DB,其中只有一个大小约 1.5 MB 的表(实际上,总共有约 30 个表,但每个表都存储在一个单独的 .db 文件中)。

当我EXPLAIN QUERY PLAN用于任何表时,它显示全表扫描,据我所知这是不好的。但是,没有一个表有索引,而且选择查询的速度很快。

所以,我想知道我是应该在我们的表上添加一些索引还是保持它们原样?(现在,表最多有 5k 行,将来它们最多可能有 100k 行)。

附注。选择和插入的数量几乎相同..

所有的想法都受到高度赞赏。

Dav*_*ett 5

现在,表最多有 5k 行,将来它们可能最多有 100k 行

在这种情况下,在时间和资源允许的情况下,检查这一点的最佳方法是制造具有该大小的逼真数据,并根据该数据测试您的应用程序以查看其扩展性如何(或者如果不是,则瓶颈所在)。但请确保您的数据是真实的:约 100,000 行相同的行不会是一个好的测试,因为索引的选择性不够有用,同样,列中数据预计“聚集”的真正随机数也不会成为最有用的测试。

  • 不幸的是,创建好的测试数据本身就是一种艺术形式,并且在很大程度上取决于数据的实际内容和引用方式。完全复制数据通常是可以接受的,而且通常已经足够好,但有时会为某些索引优化测试产生不切实际的结果(因为它可能过于人为地拥有许多相同的值和相同数量的每个值,因此查询规划器可能会在以下情况下采取不同的路线)寻找单个值)。有像 http://www.fakenamegenerator.com/ 这样的工具可以帮助处理某些数据类型,但我通常自己动手。 (3认同)
  • @monamona:我的意思是,如果您希望数据随着时间的推移扩展到 100K 行,您应该在这些表中创建一个包含 100K 行的应用程序的开发/测试副本。数据应该尽可能看起来像真实数据(不是数千个相同的行,具有类似的短/长/高/低/空值等平衡)。这样您就无需猜测数据库和应用程序在预期规模下的行为方式 - 您可以使用该大小的数据运行它并在它成为生产问题之前直接测试其性能。 (2认同)