我一直在努力解决只有在数据库空闲了一段时间才能查询数据时才会出现的问题。第一个查询将非常慢,大约30秒,然后相关查询将快速像0.1秒。我假设这与缓存有关,但我一直无法找到它的原因。
将mysql变量tmp_table_size,max_heap_table_size更改为更大的大小除了在内存中创建临时表之外没有任何效果。
我认为这与查询本身无关,因为它已被很好地编入索引,并且在第一次慢查询之后,同一查询的变体不会显示在慢查询日志中。我最感兴趣的是尝试确定此原因或重置违规缓存的方法,以便我可以解决问题。
答案 0 :(得分:9)
innodb数据文件的页面缓存在innodb缓冲池中。这是你所期望的。即使在良好的硬盘驱动器上,读取文件也很慢,特别是随机读取,这主要是数据库看到的。
可能是您的第一个查询正在执行某种表扫描,这会将大量页面拉入缓冲池,然后快速访问它们。或类似的东西。
这是我所期待的。
理想情况下,对所有表使用相同的引擎(例外:系统表,临时表(可能)和非常小的表或短期表)。如果你不这样做,那么他们就必须为公羊而战。
假设您的所有表都是innodb,请使缓冲池最多使用服务器物理RAM的75%(假设您没有在计算机上运行太多其他任务)。
然后你就可以将12G的数据库放入ram中了,所以一旦它“热身”,数据库中“最常用的”12G就会处于ram状态,访问它的过程非常快捷。
一些mysql用户倾向于在重新启动后“预热”生产服务器,将他们从另一台计算机复制的查询发送一段时间(这些将是复制从属服务器),直到他们将它们添加到生产池中。这避免了缓存冷却时看到的极端缓慢。例如,Youtube就是这样做的(至少它已经习惯了;谷歌买了它们,现在他们可能会使用Google-fu)
答案 1 :(得分:3)
你的mysql服务器上还有其他什么东西在运行吗?我的想法是,可能在第一次查询之后,您的表仍然缓存在内存中。一旦它处于空闲状态,另一个进程就会导致它被缓存。只是一个猜测。
你还有多少内存正在运行?
答案 2 :(得分:2)
MySQL Workbench :
以下与此SO问题没有100%相关,但症状非常相关,这是搜索“mysql workbench slow”或相关术语时的第一个SO结果,所以希望它对其他人有用的
清除查询历史记录! - 按照MySql workbench query history ( last executed query / queries ) i.e. create / alter table, select, insert update queries的流程清除MySQL Workbench的查询历史记录,真的为我加快了程序。
总结:将Output
窗格更改为History Output
,右键点击日期并选择Delete All Logs
。
我遇到的问题是“第一次查询速度慢”,即使持续时间/获取时间远低于1秒,加载结果也需要几秒钟。清除查询历史记录后,持续时间/获取时间保持不变(远低于1秒,因此实际上没有更改DB行为),但现在结果立即加载而不是在几秒钟后延迟。
答案 3 :(得分:1)
我有一个超时的SSIS包。查询非常简单,来自单个MySQL表,但它有时会返回大量记录,有时最初需要几分钟才能执行,如果我想再查询一次,则只需几毫秒。我们坚持使用ADO连接,这意味着它会在30秒后超时,因此我们尝试加载的数据库中有一半是失败的。
在我的头撞墙后,我尝试先执行初始查询;很简单,只返几行。由于它非常简单,因此可以快速执行并将表设置在缓存中以便更快地进行查询。在包的下一步中,我将执行更复杂的查询,该查询返回保持超时的大数据集。问题解决了 - 所有表格都已加载我可以定期开始这样做,通过先进行简单的查询,复杂的查询执行得更快。
答案 4 :(得分:0)
在一段时间后运行查询时,测试并比较linux命令行中“vmstat 1”的输出,与重新运行查询并快速获得结果相比较。具体来说,检查“bi”列(即每秒从磁盘读取的kb)。
你可能会发现操作系统在快速情况下缓存磁盘块(因此是低“bi”数字),但不是在慢速情况下(因此是一个很大的“bi”数字)。
您可能还会发现vmstat在任何一种情况下都显示高/低CPU使用率。如果它在快速时很低,并且磁盘吞吐量也很低,那么即使您已指示相关配置值设置为零,您的系统仍可能返回缓存查询。也许检查show engine innodb status
和SHOW VARIABLES
的输出并确认。
innodb_buffer_pool_size也可以设置为高(它应该是......),即使在操作系统返回之前也会缓存这些块。
您可能还会发现“key_buffer”设置为高 - 这会将索引缓存在索引中,这可能会使您的选择速度非常快。
请尝试查看mysql performance blog网站以获取大量有用信息。
答案 5 :(得分:0)
我遇到问题,因为MySQL 5.6在闲置期后第一次查询时速度很慢。这是一个连接问题,而不是MySQL实例问题,例如如果你运行MYSQL查询浏览器执行“select * from some_queue”,单独放置几个小时,然后执行任何查询,它运行缓慢,同时服务器上的进程或浏览器的新实例将从相同的表中选择瞬间。
添加skip-host-cache,skip-name-resolve到my.ini文件解决了这个问题。
我不知道为什么会这样。为什么我试过这个:没有那些选项的MySQL 5.1正在慢慢建立来自其他网络的连接(例如服务器是192.168.1.100,192.168.1.101快速连接,192.168.2.100连接速度慢),MySQL 5.6没有这样的问题开始我们最初没有将这些添加到my.ini。
UPD:实际解决了一半案件。将wait_timeout设置为最大整数固定另一半。也许我现在甚至可以删除skip-host-cache,skip-name-resolve,它不会在100%的情况下减速