对于持续时间非常短的数据，我更喜欢使用Redis或Memcached这样的缓存服务器。（虽然Redis有一个永久存储的选项，但默认情况下不使用）。它们非常快，它们有自动过期数据的选项，而且在你删除数据后恢复内存方面也很高效。缺点是如果服务器重新启动，RAM中的所有数据都将丢失。
但是你提到你的令牌需要存储30天。我认为使用持久存储会更安全。很多应用确实使用数据库，但是你也可以使用文件系统上的简单文件。或者Redis，启用持久选项。
如果在InnoDB存储引擎中使用MySQL，则可以删除行。（虽然这有点不可预测）。随着时间的推移，一个有大量周转的InnoDB表空间往往会变得碎片化，同样数量的行会占用更多的存储空间。最终，您可能会发现使用OPTIMIZE TABLE是有益的。这将以更紧凑的方式将数据复制到一个新的表空间，并删除原始表空间。
不幸的是，没有办法检查表空间以确定它是否需要优化，您只需尝试一下，看看它是否显著缩小。
OPTIMIZE TABLE的步骤有效地重建了一个表的所有索引。这就是索引“维护”所需要的全部。

InnoDB没有问题。
案例1：应用程序花了一个月的时间添加60 K行，然后突然删除所有行并重新开始：
使用TRUNCATE TABLE进行删除。
案例2：每一个数据列都使用其自己的时间范围。例如，在1月12日新增的数据列会在2月12日删除：
当行过期时，只需对行进行DELETE操作，不用担心碎片、漏洞、索引等; InnoDB将足够有效。无论如何，60 K行是“小”的。一定要有一个索引，它的设计是为了帮助找到要删除的行时，它的时间。
也就是说，每一分钟只增加一两行，每一分钟只删除一两行。即使是“每一秒”，我也会给出同样的答案。如果是“每一毫秒”，我可能会建议其他的答案。
在这两种情况下，我都不会为OPTIMIZE TABLE费心。