在最近几天,我们遇到了MySQL的一些奇怪的性能问题(旧版本5.1.69)。 慢日志显示的内容如下:
# User@Host: jboss[jboss] @ localhost [127.0.0.1]
# Query_time: 46.595796 Lock_time: 0.000022 Rows_sent: 0 Rows_examined: 0
SET timestamp=1496127084;
insert into ACTIVE_RENT (LINE_ID, CHARGED_UP_TO, EVENT_ID, NUMBER, RENT_START, TYPE) values (149914, '2017-05-02 00:00:00', 625751, 'ABCD1234567', '2013-08-02 00:00:00', 'DETENTION');
# User@Host: jboss[jboss] @ localhost [127.0.0.1]
# Query_time: 19.401896 Lock_time: 0.000041 Rows_sent: 0 Rows_examined: 0
SET timestamp=1496127084;
delete from ACTIVE_RENT where ACTIVE_RENT_ID=463965;
删除或更新时没有指定级联,它只有一个外键到另一个表,并且没有此表的触发器。这桌真的很基本。而且只有大约14k行。 通常这些插入或删除非常快,但在最后几天它们在高峰时段可能非常慢。
我们已经将innodb_buffer_size增加到20G,但这并没有太大变化(关于这个问题,其他东西更快)。目前数据库大小约为40GB。 下面是my.conf。知道瓶颈可能来自哪里以及该怎么办?我们计划将MySQL升级到5.5,但这不会发生几周。
[client]
default-character-set=utf8
socket=/home/mysql-data/mysql/mysql.sock
[mysql]
default-character-set=utf8
max_allowed_packet=32M
[mysqld]
# these are the install settings
local-infile=0
open_files_limit=8192
query_cache_size = 256M
query_cache_type = 1
query_cache_limit = 6M
query_prealloc_size = 16384
query_alloc_block_size = 2048
tmp_table_size = 128M
max_heap_table_size = 256M
table_cache = 1024
thread_cache_size = 512
key_buffer = 256M
join_buffer_size = 8M
read_buffer_size = 8M
sort_buffer_size = 8M
innodb_lock_wait_timeout = 120
binlog_format=row
max_allowed_packet=32M
log-bin=mysql-bin
server-id=1
#Allow group_concat to return longer data types
group_concat_max_len=16384
default-character-set = utf8
skip-character-set-client-handshake
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
character-set-server = utf8
innodb_buffer_pool_size = 20GB
答案 0 :(得分:0)
query_cache_size = 256M
- 太大了。每当发生写入时,必须清除该表的QC中的所有条目。这样的时间大小与大小成正比。降至50M
。
你的桌子是InnoDB吗?如果服务器具有64GB并且主要用于MySQL,则将buffer_pool设置为70%。
ACTIVE_RENT_ID
是PRIMARY KEY
吗?
InnoDB中的一行INSERT
不会占用46秒,除非长时间运行ALTER
。环视四周;涉及其他的东西。或者也许是长时间运行的交易最终会在50秒内超时?你在使用autocommit=0
吗? (我希望不是。)你在使用BEGIN...COMMIT
吗?
表ACTIVE_RENT
有多大?