更新/插入时不时需要几秒钟

我有我的服务器上真正简单的INSERT/UPDATES问题。不时需要比几秒钟更长时间才能完成这样的查询的：更新/插入时不时需要几秒钟

2.1062s - INSERT INTO `transaction` SET `idUser` = 72, `currency` = 50, `amount` = '10', `action` = 'buyCoins'; 
11.785s - UPDATE `user` SET `cash` = 10, `crystal` = 10, `expPoints` = 10, `energy` = 10 WHERE idUser = 72; 
0.6296s - UPDATE `user` SET `lastEnergyUpdate` = CURRENT_TIMESTAMP WHERE idUser = 72;

看起来问题不依赖于特定的表。我没有那些桌子上的TRIGGERS。

表定义：

CREATE TABLE `user` (
`idUser` int(10) unsigned NOT NULL AUTO_INCREMENT, 
`expPoints` int(10) NOT NULL DEFAULT '0', 
`cash` int(10) NOT NULL DEFAULT '1000', 
`crystal` int(10) NOT NULL DEFAULT '10', 
`energy` int(4) NOT NULL DEFAULT '0', 
`name` varchar(50) DEFAULT NULL, 
`surname` varchar(50) DEFAULT NULL, 
`age` int(4) unsigned DEFAULT NULL, 
`sex` enum('men','women','unknown') DEFAULT NULL, 
`lastEnergyUpdate` timestamp NULL DEFAULT NULL, 
`lastLogin` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
`insertDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
PRIMARY KEY (`idUser`), 
UNIQUE KEY `serviceUnique` (`serviceName`,`serviceId`) 
) ENGINE=InnoDB AUTO_INCREMENT=5333 DEFAULT CHARSET=utf8 

CREATE TABLE `transaction` (
    `idTransaction` int(10) NOT NULL AUTO_INCREMENT, 
    `idUser` int(10) unsigned NOT NULL, 
    `currency` enum('crystal','partnerCurrency','cash') DEFAULT NULL, 
    `amount` int(5) NOT NULL, 
    `action` enum('unlockPlace','buyExtra','collectReleased') NOT NULL, 
    `insertDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    PRIMARY KEY (`idTransaction`), 
    KEY `fk_transaction_user1` (`idUser`), 
    CONSTRAINT `fk_transaction_user1` FOREIGN KEY (`idUser`) REFERENCES `user` (`idUser`) ON DELETE CASCADE ON UPDATE CASCADE 
) ENGINE=InnoDB AUTO_INCREMENT=156329 DEFAULT CHARSET=utf8

在同一台服务器我有多个数据库（〜100），但没有大的。所有数据库的转储大约为300MB。

Mysqltunner输出：

>> MySQLTuner 1.0.1 - Major Hayden <[email protected]> 
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ 
>> Run with '--help' for additional options and output filtering 

-------- General Statistics -------------------------------------------------- 
[--] Skipped version check for MySQLTuner script 
[OK] Currently running supported MySQL version 5.1.66-0ubuntu0.11.10.2-log 
[OK] Operating on 64-bit architecture 

-------- Storage Engine Statistics ------------------------------------------- 
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 138M (Tables: 267) 
[--] Data in InnoDB tables: 170M (Tables: 327) 
[--] Data in MEMORY tables: 0B (Tables: 1) 
[!!] Total fragmented tables: 329 

-------- Performance Metrics ------------------------------------------------- 
[--] Up for: 20h 45m 57s (558K q [7.468 qps], 58K conn, TX: 685M, RX: 98M) 
[--] Reads/Writes: 66%/34% 
[--] Total buffers: 1.1G global + 6.0M per thread (150 max threads) 
[OK] Maximum possible memory usage: 2.0G (12% of installed RAM) 
[OK] Slow queries: 0% (54/558K) 
[OK] Highest usage of available connections: 6% (10/150) 
[OK] Key buffer size/total MyISAM indexes: 16.0M/8.8M 
[OK] Key buffer hit rate: 99.9% (245K cached/258 reads) 
[OK] Query cache efficiency: 51.5% (176K cached/342K selects) 
[OK] Query cache prunes per day: 0 
[OK] Sorts requiring temporary tables: 6% (1K temp sorts/19K sorts) 
[!!] Temporary tables created on disk: 34% (2K on disk/8K total) 
[OK] Thread cache hit rate: 99% (10 created/58K connections) 
[!!] Table cache hit rate: 16% (786 open/4K opened) 
[OK] Open file limit used: 32% (714/2K) 
[OK] Table locks acquired immediately: 99% (329K immediate/329K locks) 
[OK] InnoDB data size/buffer pool: 170.3M/512.0M 

-------- Recommendations ----------------------------------------------------- 
General recommendations: 
    Run OPTIMIZE TABLE to defragment tables for better performance 
    MySQL started within last 24 hours - recommendations may be inaccurate 
    Temporary table size is already large - reduce result set size 
    Reduce your SELECT DISTINCT queries without LIMIT clauses 
    Increase table_cache gradually to avoid file descriptor limits 
Variables to adjust: 
    table_cache (> 1024)

当然这只是为了那个〜1％的情况查询（99％正常工作），然后HDD真的布西（13％ - 8个核服务器上的20％WA ）

我应该不断增加table_cache吗？任何其他想法发生了什么？我该如何改进它？

我的MySQL服务器是5.1.66。我试图升级到5.5.x，但这并没有帮助我，所以我将它降级。

来源

2012-11-13 Skowron

看看慢查询日志，如果有一个查询是锁定表，并因此阻止你的upsert。 – fancyPants

您的表缓存命中率很低（很好的实际预期是95％以上），缓存大小应该会增加。创建的临时磁盘表的数量很高，但这可能只是因为您正在运行的查询;有些将始终需要临时磁盘表。使用主键顺序插入/更新数据时，InnoDB可能会很烦人。表中有多少行？外键可能是问题的一部分，因为它需要在插入/更新时进行检查。这两个更新查询是不是有一些原因？ –

@tambom - 我检查了慢查询日志，但我发现只有那些更新+来自不同数据库的一些查询（但现在我只关心这个数据库） – Skowron

当然这只是为了那个〜1％的情况查询（99％正常工作），然后HDD真的布西（13％ - 20％是在8个核服务器）

你的磁盘出现问题 - 我敢打赌，这是在你的innodb日志冲洗到磁盘时发生的 - 我会尝试使用更小的（更频繁地用于冲洗）和更大的日志大小（用于不太频繁的冲洗） - 我希望你获得更多从更频繁的冲洗。
另一件需要注意的就是在这段时间里吃什么东西 - 运行iotop，如果你能抓住罪魁祸首。
否则，请确保您的tmp，数据和日志分区在物理上是分开的，如果可以的话。

来源

2012-11-14 07:50:13 Michael

1。好点子。我会用不同innodb日志大小的结帐解决方案 2. iotop不会显示任何内容 - mysqld不时会在列表中显示，但它会在后面消失。 3.这可能会有多大的改进？我将它们全部放在一个分区上，但是我认为我可以更改 – Skowron

2 - 只有在遇到问题时运行iotop才会有效。 3.可以是巨大的，特别是如果你使用raid10。 – Michael

更新/插入时不时需要几秒钟

回答

相关问题