我无法为此左连接编制索引:
SELECT comments.id, comments.topid, comments.username, comments.body, comments.dt, comments.active, users.email
FROM comments
LEFT JOIN registered_users.users
ON comments.username = users.username
WHERE postid = 12 AND active = 1
ORDER BY id desc
我有索引:
评论 - > keyname(postid) - postid,active,id
用户 - > keyname(用户名) - 用户名
我回来的结果是:
+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+
| 1 | SIMPLE | comments | ref | postid | postid | 5 | const,const | 116 | Using temporary; Using filesort |
| 1 | SIMPLE | users | ALL | NULL | NULL | NULL | NULL | 1 | |
+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+
我该如何解决这个问题,所以我不能使用临时的;使用filesort" ?
答案 0 :(得分:1)
如果其他人遇到此问题,请务必确保您的JOIN表设置为相同的排序规则类型。
我的评论表设置为“utf8_unicode_ci” - 当我尝试加入到设置为“latin1_swedish_ci”的users.email时。
如果设置不同,MySQL就无法使用任何索引。
我现在能够使用ORDER BY,LIMIT子句而不会出现可怕的“filesort”问题。
答案 1 :(得分:0)
也许制作一个包含所有三列的索引
comments
是一个InnoDB表ALTER TABLE comments ADD INDEX new_index (active,postid,username);
comments
是MyISAM表ALTER TABLE comments ADD INDEX new_index (active,postid,id,username);
通过comments
索引搜索postid
表仍然需要间歇性地访问该表以检查id和username列。从索引中的WHERE
和ORDER BY
子句中添加更多列将减轻优化程序的工作量。
即使检索速度稍快,文件排也可能是不可避免的,因为你说
ORDER BY id desc
试一试!!!
答案 2 :(得分:0)
如果active是一个标志,那么优化器可能没有足够的选择性来打扰它。您是否尝试过仅在postid上使用索引?
答案 3 :(得分:0)
经验告诉我这样做:
create index comments_postid on comments(postid);
你需要的另一个索引是users(username)
,但你已经拥有了。
这样做也是个好主意:
analyze table comments, users;