3

我有一个大型 MySQL、MyISAM 表，大约有 400 万行，运行在一个 core 2 duo、8G RAM 笔记本电脑上。

该表有 30 列，包括 varchar、decimal 和 int 类型。

我在 varchar(16) 上有一个索引。让我们将此列称为：“indexed_varchar_column”。

我的查询是

SELECT 9 columns FROM the_table WHERE indexed_varchar_column = 'something';

对于我查询的每个“东西”，它总是返回大约 5000 行。

查询的解释返回：

+----+-------------+-------------+------+----------------------------------------------------+--------------------------------------------+---------+-------+------+-------------+
| id | select_type | table       | type | possible_keys                                      | key                                        | key_len | ref   | rows | Extra       |
+----+-------------+-------------+------+----------------------------------------------------+--------------------------------------------+---------+-------+------+-------------+
|  1 | SIMPLE      | the_table   | ref  | many indexes including indexed_varchar_column      | another_index NOT: indexed_varchar_column! | 19      | const | 5247 | Using where |
+----+-------------+-------------+------+----------------------------------------------------+--------------------------------------------+---------+-------+------+-------------+

首先我不确定为什么选择 another_index。实际上，它选择了一个索引，该索引是 indexed_varchar_column 和另外 2 列（构成所选列的一部分）的复合索引。也许这是有道理的，因为不必读取查询中的 2 列可能会使事情变得更快一些。真正的问题是以下问题：

对于我匹配的每个“东西”，查询需要 5 秒。第二次我查询“某事”需要 0.15 秒（我猜是因为查询正在被缓存）。当我对“something_new”运行另一个查询时，又需要 5 秒。所以，是一致的。

问题是：我发现创建一个索引（另一个复合索引，包括我的 indexed_varchar_column）并再次删除它会产生对新的“something_other”的所有进一步查询只需要 0.15 秒。请注意 1) 我创建了一个索引 2) 再次删除它。所以一切都处于相同的状态。

我猜想构建和删除索引所需的所有操作都会使 SQL 引擎缓存一些东西，然后再重用。当我在所有这些之后对查询运行 EXPLAIN 时，我得到的结果与以前完全相同。

如何继续了解创建-删除索引过程中缓存的内容，以便在不操作索引的情况下对其进行缓存？

更新：

根据 Marc B 的评论，建议当 mySQL 创建索引时，它会在内部执行 SELECT ... 我尝试了以下操作：

SELECT * FROM my_table;

它花了 30 秒并返回了 400 万行。好消息是所有进一步的查询再次非常快（直到我重新启动系统）。请注意，重新启动后查询又变慢了。我猜这是因为 mySQL 正在使用某种操作系统缓存。

任何的想法？如何显式缓存我猜的表？

更新2： 也许我应该提到这个表可能严重碎片化。它有 400 万行，但我会定期删除很多旧字段。我还添加了新的。由于我每天的 ID （删除的行）有很大的差距，我删除了主索引 (ID) 并用连续的数字再次创建它。该表可能非常分散，因此 IO 一定是一个问题......不知道该怎么做。

4

3 回答 3

0

复合索引中列的顺序是什么。

您必须在查询中使用（至少）列的左关联子集

如果您在 foo、bar 和 baz 上有一个索引，那么它们自己将不能用作针对 bar 或 baz 的索引。只有 (foo)、(foo,bar) 和 (foo,bar,baz)。

EXPLAIN是你的朋友吗？它将告诉您查询正在使用哪个索引（如果有）。

编辑这是一个简单的左连接查询的postgres解释，用于比较。

Nested Loop Left Join  (cost=0.00..16.97 rows=13 width=103)
    Join Filter: (pagesets.id = pages.pageset_id)
      ->  Index Scan using ix_pages_pageset_id on pages  (cost=0.00..8.51 rows=13 width=80)
              Index Cond: (pageset_id = 515)
      ->  Materialize  (cost=0.00..8.27 rows=1 width=23)
          ->  Index Scan using pagesets_pkey on pagesets  (cost=0.00..8.27 rows=1 width=23)
                Index Cond: (id = 515)
于 2012-09-10T15:07:53.613 回答
0

您有多少包含 indexed_varchar_column 的索引？您是否只有 indexed_varchar_column 的单个索引？

你有没有试过： SELECT 9 columns FROM USE INDEX (name_of_index) the_table WHERE indexed_varchar_column = 'something';？

于 2012-09-10T15:22:17.693 回答
0

谢谢大家的帮助。

最后我发现（感谢 Marc B 的提示）我的表在多次 INSERT 和 DELETE 之后严重碎片化。几个小时前，我用这个信息更新了这个问题。有两件事有帮助：

1)

ALTER TABLE my_table ORDER BY indexed_varchar_column;

2）运行：

myisamchk --sort-records=4 my_table.MYI  (where 4 corresponds to my index)

我相信这两个命令是等效的。即使在系统重新启动后查询也很快。我已将此 A​​LTER TABLE ORDER BY 命令放在每天运行的 cron 上。这需要 2 分钟，但这是值得的。

于 2012-09-12T09:21:36.423 回答