我正在运行 CMS,但这与之无关。
我有一个简单的查询:
UPDATE e107_online SET `online_location` = 'http://page.com/something.php?', `online_pagecount` = 133 WHERE `online_ip` = '175.44.*.*' AND `online_user_id` = '0' LIMIT 1;
但我的网站支持报告的相同查询表明:
User@Host: cosyclim_website[cosyclim_website] @ localhost []
Thread_id: 7493739 Schema: cosyclim_website
Query_time: 12.883518 Lock_time: 0.000028 Rows_sent: 0 Rows_examined: 0 Rows_affected: 1 Rows_read: 1
一个简单的更新查询需要 12(几乎 13)秒?有什么办法可以优化它吗?如果我通过 PhpMyAdmin 运行它,需要 0.0003 秒。
表格:
CREATE TABLE IF NOT EXISTS `e107_online` (
`online_timestamp` int(10) unsigned NOT NULL default '0',
`online_flag` tinyint(3) unsigned NOT NULL default '0',
`online_user_id` varchar(100) NOT NULL default '',
`online_ip` varchar(15) NOT NULL default '',
`online_location` varchar(255) NOT NULL default '',
`online_pagecount` tinyint(3) unsigned NOT NULL default '0',
`online_active` int(10) unsigned NOT NULL default '0',
KEY `online_ip` (`online_ip`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
最佳答案
您的查询正在更新满足特定条件的一行:
UPDATE e107_online
SET `online_location` = 'http://page.com/something.php?', `online_pagecount` = 133
WHERE `online_ip` = '175.44.*.*' AND `online_user_id` = '0'
LIMIT 1;
鉴于您有 IP 地址,我猜这个表相当大。数以百万计的行。更新可能需要很长时间的原因有很多,例如服务器负载、阻塞事务和日志文件性能。在本例中,我们假设问题是查找其中一行。您只需在相同条件下执行 select
即可对此进行测试,并查看需要多长时间。
假设 select
始终很慢,那么问题可能可以通过索引来解决。如果表没有索引——或者MySQL不能使用现有索引——那么它需要进行全表扫描。而且,也许匹配的一条记录位于表的末尾。需要一段时间才能找到它。
我建议在 e107_online(online_ip)
或 e107_online(online_user_id, online_ip)
上添加索引,以帮助它更快地找到记录。该索引需要是 B 树索引,如解释的 here .
使用索引的一个后果是匹配值最低的 IP 可能会被选中。我不知道缺乏随机性是否会对您的应用程序产生影响。
关于mysql - MySQL 服务器的更新非常慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16624017/