索引编制

索引是所有优化尝试中经常被推荐但鲜为人知的解决方案，适用于大多数数据库。无论您使用的时间序列数据库是基于MySQL构建的，还是基于其自身的独特体系结构，索引都会影响您的查询。本质上，索引是一种数据结构，用于存储特定列中的值，这意味着当我们通过索引字段进行搜索时，可以方便地使用这些值。当我们通过未索引字段搜索时，我们必须发现该值的完整路径，而没有快捷方式或魔术。搜索未索引的字段就像必须观看未经编辑地走过中土一样-花费很长时间。

虽然索引不是时间序列数据库所独有的

但我们必须记住，索引是一个数据结构，如果我们有太多的索引列或字段，索引将变得过大，太大的索引结构终会占用内存并减慢进程，从而不利于其优势，这里的时间序列问题是，没有关于应为哪些索引建立索引的约定，因此我们需要始终了解我们的架构，当查询使我失望时，我通常会跳入命令行，我在那里很开心。当我次发现时间序列数据库时，我就是这样做的。

时间序列数据的独特品质之一是，它在更大数量时更有价值-我们存储了数百万个点

使用*（全部）运行查询可能会在检索点时锁定数据库，有一些选项可以限制您的查询，同时也可以改善它，使用时间范围，许多时间序列应用程序查询都从一个窗口聚合数据，因此可以利用它来获取优势，添加一个子查询，这将通过添加参数来限制查询的范围，并确保仅获得相关结果，限定查询范围的关键是过滤它们-尽可能具体，以避免应用程序，终端和思维中的数据过载。

在时间序列数据的世界中，数据点的年龄就像保鲜盒中装满袋装沙拉的时间一样

我可能会把它保存的时间长于应有的时间，但终我将需要丢弃它，大量的点使得难以无限期地存储时间序列数据，即使磁盘空间允许存储大量数据，查询也必须遍历庞大的数据集，假设您忽略了我以前的一些建议，并且您需要在没有时间窗口或子查询的情况下运行查询。您可以仅通过设置删除过期数据的过程来控制数据量，这是另一部分，其后勤工作取决于您所使用的数据库，但这是一个常见的时间序列问题，因此，Internet上为您选择的数据库提供了很多解决方案，删除过期的数据并为自己节省一些时间。

即使我们的查询是的，高基数也会使我们慢下来

列或系列中值的数量决定基数-高基数意味着大量值，当我们要查询越来越多的属性组合时，基数往往会增加，这会导致数据库花费大量时间：在一系列中查找适当的值，对这些值执行任何必要的功能（即，对这些值求和），然后重复每个相关的系列，然后根据查询要求将它们组合在一起，随着索引和基数的增加，运行查询的开销也会增加，在列式数据库中，我们可以通过确保具有较少点数的序列而不是具有较少点数的序列来提高性能。时间序列中的压缩技术可以在较长的值上更有效地运行，因此，如果我们想从数据库中获得收益，则需要遵循其规则。

在基于关系数据库的时间序列数据库中

基数对索引的影响比其他任何因素都大，因此我们需要密切注意索引的大小，以免占用我们的资源，您的时间序列应用程序在效率和性能上应具有卓越的表现，并且您可以实现它。注意索引，查询范围，保留策略和基数可能无法解决您的所有问题，但是您对数据了解的越多，就越能进行查询。我们比成为时间序列大师更近了一步。