我们有一个简单的 Web 应用程序在虚拟机上运行,该应用程序使用 InnoDB 引擎将数据保存在 MySQL 5.5 数据库中。大约三年来,一切都运行正常,但突然变得非常慢。
例如,我有一个非常简单的表,其中包含地址:
CREATE TABLE `addresses` (
`address_id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(64) CHARACTER SET latin1 NOT NULL,
`firstname` varchar(64) CHARACTER SET latin1 NOT NULL,
`street` varchar(64) CHARACTER SET latin1 NOT NULL,
`housenumber` varchar(16) CHARACTER SET latin1 NOT NULL,
`zip` varchar(5) CHARACTER SET latin1 NOT NULL,
`city` varchar(64) CHARACTER SET latin1 NOT NULL,
`email` varchar(64) CHARACTER SET latin1 NOT NULL,
`phone` varchar(16) CHARACTER SET latin1 NOT NULL,
`birthdate` date NOT NULL,
PRIMARY KEY (`address_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
该表包含大约 800 个条目,这确实不多。但是运行查询
SELECT * FROM addresses
出于测试目的,它似乎永远无法完成。我使用服务器上的 mysql CLI 检查了这一点:它输出表的一些行,然后等待很长时间,直到输出下一行。
所以也许是数据发送阶段的问题,但我不确定。
VM 有 2GB 的 RAM,但只使用了 320MB。CPU 也以非常低的 1% 到 2% 运行。mytop 没有显示任何其他阻塞服务器的查询。IT 管理员说他们没有在硬件方面进行任何更改。
我已经尝试了一些方法,比如重启数据库服务器、重启虚拟机。但都无济于事。
编辑:
EXPLAIN SELECT * FROM addresses
给出了这个结果:
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | addresses | ALL | NULL | NULL | NULL | NULL | 793 | |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)
答案1
如果 CPU 负载较低,则表明不存在缺少索引的问题,如果是这种情况,查询只需要占用更多 CPU 和磁盘访问。您还说它运行良好 3 年。
您是否检查过一般磁盘访问速度(特别是数据库所在的分区)?例如使用dd
像这儿。您所描述的听起来像是坏掉的磁盘或半死的 raid。我希望有备份?
答案2
你可以尝试几件事,
- 您有设置索引吗?
索引使得快速找到记录成为可能,而无需先进行全表扫描,从而大大缩短了执行时间。
CREATE INDEX idx_name ON addresses(name);
- 在运行查询之前,请先使用 EXPLAIN 关键字,
当在 SELECT 查询前面使用时,它将描述 MySQL 打算如何执行查询以及完成之前需要处理的行数。
- 对您的 mysql.ini 进行一些更改,如果它是 VM,请增加 RAM 并配置您的 mysql.ini 以查看性能是否提高。
有许多 MySQL 优化器可以指导您。
帮助这有帮助