mysql - 在 MySQL 中加载一张表慢得离谱

Question

为清楚起见，数据库中的所有其他表均按预期工作，并在几分之一秒内加载约 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 带有更新当前时间戳的字段。

---

好的，我会尝试两个答案，但我可以先快速回答问题:

ID 字段上的主键是唯一键。该表用于排队，每小时添加/删除约 50 条记录，但我昨天才创建它。它会在这么短的时间内损坏吗？

MyISAM

---

尝试隔离问题的更多工作:

修复表 什么也没做 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

Answer 1

如果您怀疑某处存在腐败，您可以尝试以下其中一项(或两项):

CREATE TABLE temp SELECT * FROM parser_queue;

这将创建一个与前一个表“相同”的新表，只是将重新创建它。或者(或者可能在您制作副本之后)，您可以尝试:

REPAIR TABLE parser_queue;

您可能还想尝试优化表格；它可能会变得支离 splinter ，因为您将它用作队列。

OPTIMIZE TABLE parser_queue;

您可以通过运行 SHOW TABLE STATUS LIKE 'Data_Free' 来确定表是否碎片化，并查看这是否会产生很大的数字。

更新

您说您正在将 gzcompress 数据存储在 TEXT 列中。尝试将 TEXT 列更改为 BLOB，这意味着处理二进制数据，例如压缩文本。