使用 EXPLAIN 查看执行计划，并验证查询是否使用了合适的索引。如果没有，请验证是否有适当的索引可用。
一 INDEX 是按“顺序”存储的，mysql可以有效地与一些查询模式一起使用(innodb表也是按顺序存储的，按cluster键存储，cluster键是表的主键（如果存在）或非空列上的第一个唯一键。）
通过一些查询模式，通过使用索引，mysql可以消除大量的行被检查。当mysql无法使用索引时（可能是因为不存在合适的索引，或者是因为查询具有阻止索引的构造），执行计划将执行完全扫描，即检查表中的每一行。当这种情况发生在非常大的table上时，事情会变得很慢。
编辑
问：为什么这么慢？
答：有几个因素会影响经过的时间。它可能是争用，例如，另一个会话占用的独占表锁，也可能是i/o（磁盘读取）时间，或者是一个大型的“using filesort”操作。通过慢速网络连接返回结果集的时间。
提供的信息有限，无法诊断问题。我们只能就一些常见问题提出一些建议。
问：我怎样才能让它更快？
答：不可能提出具体的建议。我们需要找出瓶颈在哪里，是什么，以及解决这个问题的方法。
看一下 EXPLAIN 检查执行计划。是使用了适当的索引，还是正在进行完全扫描？有多少行正在检查？是否有“使用文件排序”操作？等。
问：有什么设计技巧可以在这里应用吗？
答：一般来说，要有一个合适的索引可用，并仔细设计sql语句，以便启用最有效的访问计划。
问：也许我应该改变查询的方式
答：更改sql语句可能会提高性能，这是一个很好的开始，在查看了执行计划之后。。。是否可以修改查询以获得更有效的计划？
问：或者更改timestamp列的数据类型。
答：我认为更改timestamp列的数据类型不太可能提高性能。只有4个字节。你想把它改成什么？使用 DATETIME 需要7个字节。
通常，我们希望行尽可能短，并将尽可能多的行打包到一个块中。表的物理组织方式也很理想，这样可以从更少的块中满足查询。。。查询所需的行位于较少的页面中，而不是分散在大量页面上。
对于innodb，增加缓冲池的大小可能会减少i/o。
而来自固态驱动器（ssd）的i/o将比来自旋转硬盘（hdd）的i/o更快，如果hdd上存在来自其他进程的i/o争用，则更是如此。