我已经在 StackOverflow 上发布了此内容，但被标记为非主题。也许你们可以帮助我。
我目前正在运行 Ubuntu 12.04 的虚拟机上进行一些数据库基准测试。我注意到，第二次执行查询时，它的运行速度明显加快。这很可能是由于操作系统缓存将所有数据都保存在主内存中。为了防止缓存破坏我的测量结果，我希望在后续运行之间清除缓存。
我在谷歌上找到了以下命令来实现这一点：
sync;echo 3 > /proc/sys/vm/drop_caches
和
sysctl -w vm.drop_caches=3
即使我以 root 身份登录，这些都会导致权限被拒绝错误。似乎无法从客户系统清除系统缓存。我猜这是因为它使用了主机缓存。由于我无法访问主机，所以我必须找到一种解决方法。目前我有两个想法。
第一个想法是在运行之间重新启动机器，因为这会清除缓存。因为我想执行几十次运行，所以我确实需要自动执行此操作。所以我可以将程序放入自动启动，让它执行查询并重新启动，然后在下次启动时继续执行下一个查询。感觉就像在写病毒。
第二个想法是将其他数据全部放入内存中。由于我的机器有相当多的 RAM，因此我会生成一些包含随机数据的大型文件，然后将其读入 /dev/null。
所以最后我的问题是，有没有人有更好的办法来清除缓存，或者完全避免使用缓存？或者有人对如何轻松实现我的两个想法之一有什么建议吗？
提前谢谢你，Antigo
答案1
这个问题似乎是基于这样的前提：第二次速度的提高是“由于操作系统缓存将所有数据保存在主内存中”。我不太确定这就是仅有的第一次运行与后续运行之间的差异。如果性能差异是主机缓存 VM RAM，则重新启动 VM 的差异应该可以忽略不计，您需要重新启动主机才能看到任何差异。
一方面，查询编译和解析以及确定合适的执行计划对数据库引擎来说也是相当困难的工作，因此通常会缓存这些结果，这可能会影响第一次和后续运行之间的性能。这方面的影响可能微不足道，也可能很大，具体取决于数据库引擎还需要做什么来满足查询。
如果你有足够的内存，解决缓存问题的一种方法是将数据库文件移动到较大的 RAM 磁盘在测试期间。通过监控 I/O 统计数据，您可以估计查询产生的 I/O 量，从而估计各种优化技术对性能的影响，而不必担心数据缓存的影响，因为所有数据已经是在 RAM 中。
您没有说明您正在运行哪个数据库引擎，因此很难给出具体建议。在 Microsoft SQL Server 中，您可以执行类似SET STATISTICS IO,TIME ONand/or 的操作SET STATISTICS PROFILE在执行查询之前，获取有关数据库服务器执行相关查询的工作量的数据；其他数据库引擎几乎肯定具有类似的功能（这是查询性能调优的基本先决条件）。请注意，此类统计数据通常包括实际 I/O 请求的数量，并且由于这些 I/O 请求能但不一定将要任何操作系统级缓存都无法满足这些要求，这些数字可以作为查询执行涉及多少数据的有用指标。查询计划和实际结果之间的巨大差异，特别是在各种情况下的 I/O 量或行数，将对性能产生影响，因为这意味着数据库引擎在使用哪种算法方面做出了错误的决定。任何地方的大量 I/O 都可能意味着你对磁盘的访问次数超过了必要的次数，这将要以性能为代价。