无法进一步优化MySQL查询：我缺少什么？

我有一个查询似乎不可能进一步优化（关于执行时间）。这是一个简单的查询，索引已经就位，我已经尝试配置InnoDB设置……但似乎没有什么真正的帮助

表格

该查询是trk、auf和paf三个表之间的联接

• trk：临时表，包含表示轨迹的id
• auf：表示与曲目关联的音频文件的表
• paf：保存已发布音频文件id的表。充当“过滤器”

在trk表中有50到100个ID的情况下，执行查询通常需要1500到2500毫秒。auf表包含大约110万行，paf表包含大约900.000行

MySQL服务器运行在4GB机架空间云服务器实例上

查询

SELECT auf.*
FROM auf_713340 trk
INNER JOIN file auf
  ON auf.track_id = trk.id
INNER JOIN publishedfile paf
  ON auf.id = paf.file_id

带解释的查询

id select_type table type   possible_keys         key           key_len ref                                 rows Extra
1  SIMPLE      trk   ALL    NULL                  NULL NULL     NULL                                        60  
1  SIMPLE      auf   ref    PRIMARY,FK_file_track FK_file_track 108     func                                1   Using where
1  SIMPLE      paf   eq_ref PRIMARY               PRIMARY       110     trackerdatabase_development.auf.id  1   Using where; Using index

InnoDB配置

[mysqld]

# The size of memory used to cache table data and indexes. The larger 
# this value is, the less I/O is needed to access data in tables. 
# Default value is 8MB. Recommendations point towards 70% - 80% of 
# available system memory.
innodb_buffer_pool_size=2850M

# Recommendations point towards using O_DIRECT to avoid double buffering.
# innodb_flush_method=O_DIRECT

# Recommendations point towards using 256M.
# @see http://www.mysqlperformanceblog.com/2006/07/03/choosing-proper-innodb_log_file_size/
innodb_log_file_size=256M

# The size in bytes of the buffer that InnoDB uses to write to the log files
# on disk. Recommendations point towards using 4MB.
innodb_log_buffer_size=4M

# The size of the buffer used for MyISAM index blocks.
key_buffer_size=128M

---

现在，问题是；我该怎么做才能使查询执行得更好？毕竟，所讨论的表并没有那么大，索引已经就位。

在auf表中，将id字段设置为int（11），并使其自动递增。所有大于11的整型字段长度，将其编辑为11

谢谢 里帕萨哈

试试这个：

SELECT auf.* 
FROM file auf 
WHERE EXISTS 
      ( SELECT *
        FROM auf_713340 trk 
        WHERE auf.track_id = trk.id 
      )
  AND EXISTS
      ( SELECT *
        FROM publishedfile paf
        WHERE auf.id = paf.file_id
      ) ;

---

我还将测试和比较使用InnoDB引擎定义的临时表或作为

BTREE

索引的（主）索引的效率。默认情况下，内存表有

HASH

索引，如果我没有记错的话，就不是Btree。

发布表的定义（

SHOW CREATE TABLE

）。为什么它会将func列为

auf

的参考？您在发布的SQL中进行了直接比较。@ypercube:Added SHOW CREATE statementsm@scragar:不确定……可能是因为“trk”表是临时内存表吗？我选择了这个路径，而不是在50-100个ID上执行WHERE IN条件。这就是为什么解释显示键为108。因此，您的“auf”表的大小可能要大3倍。尝试将所有id列改为二进制（36）。谢谢您的输入，但这说起来容易做起来难。根据UUID（字符）的id，有多个应用程序-这意味着此更改将需要更改整个应用程序。感谢您提供的信息。主键将始终是唯一的。所以INT是主键的最佳类型。如果id CHAR（36）依赖于您的应用程序，那么您可以将此id设置为id_dependen CHAR（36）和id INT（11）。这两个领域可能会解决您的问题。是的，可能是……但我必须承认，我更感兴趣的是调查性能改进，而不是重新设计。

SELECT auf.* 
FROM file auf 
WHERE EXISTS 
      ( SELECT *
        FROM auf_713340 trk 
        WHERE auf.track_id = trk.id 
      )
  AND EXISTS
      ( SELECT *
        FROM publishedfile paf
        WHERE auf.id = paf.file_id
      ) ;