为了清楚起见，数据库中的所有其他表都按预期工作，并在几分之一秒内加载了约 200 万行。一张只有约 600 行的表在 navcat 中加载需要 10 多分钟。
我想不出任何可能的原因。只有 4 列。其中一个 是 一个大文本字段，但我以前处理过大文本字段，它们从未如此缓慢。
运行 explain select * from parser_queue 我得到
id setect type table type possible keys key key len ref rows extra
1 SIMPLE parser_queue ALL - - - - 658 -
配置文件告诉我 453 秒用于“发送数据”
我也在“状态”选项卡中得到了这个。我不明白其中的大部分，但这些数字比我的其他表格高得多。
Bytes_received 31
Bytes_sent 32265951
Com_select 1
Created_tmp_files 16
Handler_read_rnd_next 659
Key_read_requests 9018487
Key_reads 3928
Key_write_requests 310431
Key_writes 4290
Qcache_hits 135077
Qcache_inserts 14289
Qcache_lowmem_prunes 4133
Qcache_queries_in_cache 983
Questions 1
Select_scan 1
Table_locks_immediate 31514
文本字段中存储的数据平均约为 12000 个字符。
有一个主要的、自动递增的
int id 字段、一个 tinyint 状态字段、一个 text 字段和一个带有 timestamp 的 on update current timestamp 字段。好的，我会尝试两个答案，但我可以先快速回答问题:
ID 字段上的主键是唯一的键。该表用于排队，每小时添加/删除约 50 条记录，但我昨天才创建它。能在这么短的时间内损坏吗？
它是 MyISAM
尝试隔离问题的更多工作:
repair table 什么也没做optimize table 什么也没做创建了一个临时表。临时表上的查询慢了大约 50%。
删除表并重建它。
SELECT * 只需要 4 行就需要 18 秒。这是我用来创建表的 SQL:
CREATE TABLE IF NOT EXISTS `parser_queue` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`status` tinyint(4) NOT NULL DEFAULT '1',
`data` text NOT NULL,
`last_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MyISAM;
更奇怪的是，在我的本地盒子上一切都很好。缓慢只发生在开发站点上。
为清楚起见:开发站点上有 100 多个表，这是唯一一个时髦的表。
好的，我已禁用所有使用此表的 cron 作业。
SHOW PROCESSLIST 不会显示表上的任何锁。将引擎更改为
InnoDB 并没有产生任何显着的改进(86 秒对 MyISAM 的 94 秒)还有其他想法吗？ . . .
在查询期间运行
SHOW PROCESSLIST 显示它花费了大部分时间 writing to net 最佳答案
如果您怀疑某处损坏，您可以尝试以下任一(或两者):
CREATE TABLE temp SELECT * FROM parser_queue;
这将创建一个与前一个“相同”的新表，只是它会被重新创建。或者(或者在您制作副本之后)，您可以尝试:
REPAIR TABLE parser_queue;
您可能还想尝试优化表；由于您将其用作队列，因此它可能已经碎片化。
OPTIMIZE TABLE parser_queue;
您可以通过运行
SHOW TABLE STATUS LIKE 'Data_Free' 来确定表是否碎片化，并查看这是否会产生高数字。更新
您说您将
gzcompress ed 数据存储在 TEXT 列中。尝试将 TEXT 列改为 BLOB，这意味着处理二进制数据，例如压缩文本。关于mysql - 在 MySQL 中加载一张表非常慢，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5843312/