随机慢速MySQL查询

Question

我知道这类问题经常出现。但我做了很多研究，尝试了很多不同的设置，但仍然有相同的问题:查询通常是非常快的，可以花3s到5s似乎是随机的。

服务器是一个具有32 an的i7-3770 (8核)。CPU使用率约为50%空闲，而不是CPU尖峰。不使用交换，空闲内存平均约10 is。我在CentOS 6上运行MySQL5.5.32。

已经为MySQL分配了9GB内存，它使用了大约2GB的内存。所有数据都应该存储在内存中(600 of的数据，700 of的索引)。

平均每秒的查询次数(没有真正的峰值)：

• 1.5选择
• 0.2更新
• 0.05插入

下面是一个查询示例，它只需几毫秒，但有时超过3s：

# Query_time: 4.337884  Lock_time: 0.050146 Rows_sent: 1  Rows_examined: 1
SELECT me.id, me.url, me.filename, me.instance_id, me.virtual_id, me.status, me.user_id, me.time_added, me.time_finished, me.priority, me.size, me.delay, me.flash_delay, me.tries, me.details, me.json_file, me.html, me.shots, me.shot_interval, me.screen_width, me.screen_height FROM Screenshots me WHERE ( me.id = '5992705' ); 

id是主键。

虽然我有比INSERT查询更多的SELECT，但是插入速度比SELECT慢。

我试过和测试的是：

• 确保所有必需的索引都在那里，但没有多余的索引，也没有未使用的索引。
• 当时没有CPU尖峰，没有IO尖峰，没有交换
• 作为从MySQL的第二个实例，大多数选择查询都是在从服务器上完成的。
• 删除和文本及等效数据类型
• 调my.cnf

调优my.cnf很有帮助。我试过启用和禁用查询缓存，差别不大。

使用奴隶进行选择实际上使事情变得更糟了:我对主程序的查询较少，但它们可能高达12s！

下面是我当前的my.cf (本例中有查询缓存)：

tmp_table_size                 = 32M
max_heap_table_size            = 32M
query_cache_type               = 1
query_cache_size               = 1M
thread_cache_size              = 50
open_files_limit               = 65535
table_definition_cache         = 1024
table_open_cache               = 4096

innodb_flush_method            = O_DIRECT
innodb_log_files_in_group      = 2
innodb_log_file_size           = 256M
innodb_log_buffer_size         = 8M
innodb_thread_concurrency      = 8
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table          = 1
innodb_buffer_pool_size        = 9G

max_connections=1000
transaction-isolation          = READ-UNCOMMITTED 
innodb_locks_unsafe_for_binlog = 1
innodb_io_capacity             = 1000
innodb_change_buffering        = inserts
innodb_fast_shutdown           = 0

key_buffer_size                = 2G

我没有主意了。我找不到任何图案(频率、间隔等)。这将解释这些缓慢的查询。

Answer 1

你的磁盘设置是什么？你没提过。听起来像是它的IO绑定。

innodb_io_capacity --在默认情况下，除非您有充分的理由或基准来证明您的设置是正确的，否则没有理由更改它。

我怀疑你把这个设定得太高了。InnoDB写线程每秒钟可以向磁盘抛出比它们所能处理的更多的数据，从而导致I/O排队。