MySQL MyISAM 表性能问题重温答案

【问题标题】：MySQL MyISAM table performance problem revisitedMySQL MyISAM 表性能问题重温
【发布时间】：2010-10-25 05:34:53
【问题描述】：

这个问题与this one有关。

我有一个具有以下结构的页面表：

CREATE TABLE  mydatabase.page (
  pageid int(10) unsigned NOT NULL auto_increment,
  sourceid int(10) unsigned default NULL,
  number int(10) unsigned default NULL,
  data mediumtext,
  processed int(10) unsigned default NULL,
  PRIMARY KEY  (pageid),
  KEY sourceid (sourceid)
) ENGINE=MyISAM AUTO_INCREMENT=9768 DEFAULT CHARSET=latin1;

data 列包含的文本大小约为每条记录 80KB - 200KB。 data 列中存储的数据总大小约为 1.5GB。

执行此查询需要 0.08 秒：

select pageid from page

但执行此查询大约需要 130.0 秒：

select sourceid from page

如您所见，我在 page.pageid 上有一个主索引，在 page.sourceid 上有一个索引。那么第二个查询应该花费 THAT 长吗？

编辑#1

解释返回

id select_type table type  possible_keys key      key_len ref rows Extra
1  SIMPLE      page  index               sourceid 5           9767 Using index

很抱歉，分析不起作用... MySQL（其 4.1.22）无法识别 SHOW PROFILE 查询。

显示索引返回

Table Non_unique Key_name  Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
page  0          PRIMARY   1            pageid      A         9767                             BTREE 
page  1          sourceid  1            sourceid    A         3255                        YES  BTREE

【问题讨论】：

请执行“EXPLAIN select sourceid from page”并为此查询启用 pforiling：“SET profiling = 1;”，执行查询“SHOW PROFILE;”然后禁用分析“SET profiling = 2;”和过去的结果。
糟糕——首先它应该是“profiling”而不是“pforiling”，然后应该是“SET profiling = 0;”禁用分析。
刚刚按要求编辑了帖子

标签： sql mysql performance query-optimization myisam

【解决方案1】：

您的 sourceid 字段有何不同？如果与行数相比，您只有几个不同的 sourceid 值，那么您可以尝试增加索引的大小。

【讨论】：

sourceid 包含大约 3500 个不同的值。它指的是具有大约 3500 行的源表。每个来源包含 0 到 700 页。

【解决方案2】：

您是否尝试强制使用索引？喜欢：

SELECT sourceid FROM page USE INDEX (sourceid_index)

像 sgehrig cmets 一样，使用 EXPLAIN 检查是否使用了索引？并分享结果？

EXPLAIN select sourceid from page

它还可以帮助共享索引的定义：

SHOW INDEX FROM page

【讨论】：

我已经修改了问题并添加了您要求的信息
ahhh... select sql_no_cache sourceid from page use index (sourceid) 工作，查询耗时 0.09 秒。由于某种原因，mysql 无法自行确定要使用的索引。我现在需要一个在级联连接中强制索引的查询（pagedetail > page > source）
你真的能确认只有 SQL_NO_CACHE 和 USE INDEX 的组合才能带来预期的速度优势吗？会不会是 SQL_NO_CACHE 是决定因素？
我使用 SQL_NO_CACHE 来测试查询的实际性能。如果我不使用这个关键字（这是我通常做的）查询第一次运行缓慢，后来查询结果来自缓存，它总是更快但不是问题的解决方案。 SQL_NO_CACHE 强制 mysql 不使用/save-results-in 缓存返回查询在正常情况下的实际时间。
这正是我问的原因 - 我想排除查询缓存对执行时间有一些影响的选项。所以很明显 MySQL 需要索引提示来使用覆盖索引。

【解决方案3】：

由于 MySQL 4.1.22 相当旧（2006 年 11 月 2 日），我怀疑它不支持 覆盖索引 用于辅助键的概念。 EXPLAIN 表明查询实际上使用了索引，所以我假设需要额外的时间来读取所有结果行（而不是在使用 覆盖索引时返回索引内容）提取sourceid 列。

您是否可以在更新的 MySQL 服务器版本上检查查询？

【讨论】：