在MySQL的重負載下插入/刪除行需要幾秒鐘

在過去的幾天裏，我們遇到了MySQL（舊版本5.1.69）的一些奇怪的性能問題。慢日誌顯示的東西，如：在MySQL的重負載下插入/刪除行需要幾秒鐘

# [email protected]: 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'); 

# [email protected]: 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

來源

2017-05-31 Ben

檢查服務器是否需要在磁盤臨時表中創建批次...檢查SHOW STATUS命令是否爲此變量Created_tmp_disk_tables ...臨時磁盤表是MyISAM表可能導致大量I/O使服務器執行少得多... –

query_cache_size = 256M - 太大了。每當發生寫入時，必須清除該表中QC的全部條目。這種時間與大小大致成正比。降至50M。

您的表InnoDB？如果服務器有64GB並且主要用於MySQL，那麼將buffer_pool設置爲70％。

是ACTIVE_RENT_ID的PRIMARY KEY？

進入InnoDB的一行INSERT不會花費46s，除非長期運行ALTER正在進行。環視四周;涉及其他事情。或者，也許是一個長期運行的交易，最終超時50秒？你在用autocommit=0嗎？（我希望不是。）你在使用BEGIN...COMMIT嗎？

表格的大小ACTIVE_RENT？

來源

2017-05-31 16:54:17

在MySQL的重負載下插入/刪除行需要幾秒鐘

回答

相關問題