我有一个非常简单的表来记录传感器的读数。一列用于传感器 ID 号，一列用于传感器读数，一列用于时间戳。该列是 SQL 类型时间戳。表中数据量很大，有几百万行。
当我使用特定传感器 ID 号查询特定时间戳之前的所有行时，有时可能需要很长时间。如果时间戳距过去很远，则查询速度相当快，但如果是最近的时间戳，则最多可能需要 2 或 3 秒。
看起来好像 SQL 引擎正在迭代表，直到找到第一个大于查询时间戳的时间戳。或者更大的查询数据量可能会减慢速度，我不知道。
无论如何，我在这里寻找设计建议，特别是为了解决以下问题:为什么这么慢？我怎样才能让它更快？
有什么设计技巧可以应用在这里吗？我对 SQL 不太了解，也许有一种方法可以让 SQL 引擎知道数据是有序的(现在不是，但我猜我可以在插入时对其进行排序)并加快查询速度。也许我应该更改查询的完成方式或更改时间戳列的数据类型。
最佳答案
使用EXPLAIN查看执行计划，并验证查询是否使用合适的索引。如果没有，请验证是否有适当的索引可用。
INDEX 是“按顺序”存储的，MySQL 可以有效地利用某些查询模式。 (InnoDB 表也按簇键按顺序存储，簇键是表的主键(如果存在)或非 NULL 列上的第一个 UNIQUE KEY。)
对于某些查询模式，通过使用索引，MySQL 可以消除大量行的检查。当MySQL无法使用索引时(或者因为不存在合适的索引，或者因为查询有阻止它的结构)，执行计划将进行全面扫描，即检查表中的每一行。当这种情况发生在非常大的表上时，事情就会变得很慢。
编辑
问:为什么这么慢？
答:有几个因素会影响耗时。这可能是争用，例如，另一个 session 获取独占表锁，也可能是 I/O(磁盘读取)时间，或大型“使用文件排序”操作。通过慢速网络连接返回结果集的时间。
无法利用所提供的有限信息来诊断问题。我们只能针对一些常见问题提供一些建议。
问:怎样才能让它更快？
答:无法提出具体建议。我们需要找出瓶颈在哪里、是什么，并解决它。
查看 EXPLAIN 的输出来检查执行计划。是否使用了适当的索引，或者是否进行了全面扫描？正在检查多少行？是否有“使用文件排序”操作？等人。
问:有什么设计技巧可以应用到这里吗？
答:一般来说，有一个合适的可用索引，并精心设计 SQL 语句，以便启用最有效的访问计划。
问:也许我应该改变查询的完成方式
A:更改 SQL 语句可能会提高性能，这是一个很好的起点，在查看执行计划之后...可以修改查询以获得更高效的计划吗？
问:或者更改时间戳列的数据类型。
答:我认为更改 TIMESTAMP 列的数据类型不太可能提高性能。那只有 4 个字节。你会把它改成什么？使用 DATETIME 将占用 7 个字节。
一般来说，我们希望行尽可能短，并将尽可能多的行打包到一个 block 中。还希望表的物理组织方式能够通过更少的 block 满足查询...查询所需的行可以在更少的页面中找到，而不是将行分散在大量页面上。
对于 InnoDB，增加缓冲池的大小可能会减少 I/O。
来自固态硬盘 (SSD) 的 I/O 将比来自旋转硬盘 (HDD) 的 I/O 更快，如果 HDD 上存在来自其他进程的 I/O 争用，则尤其如此。
关于传感器时间戳数据表中 MySQL 查询时间太长，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50010194/