现在已经尝试了一段时间才弄明白这一点。基本上我所做的就是返回这些表中各种表和/或条件的计数。
目前，这需要大约13秒才能运行。整个数据库只有700KiB，因此几乎没有任何关注我的日期。使用dbForge查看计划，配置文件等似乎工作正常，但是，为什么这么长时间？有时候很快，有些则很慢......其他时候会出现以下错误：
SQLSTATE [HY000]：常规错误：126表的密钥文件不正确 ＆＃39; /tmp/#sql_5c99_0.MYI' ;;尝试修复它
花费大部分时间，当它工作时，从“复制到磁盘上的tmp表”开始。有人可以帮助我解释为什么这不能按预期工作吗？
查询：
SELECT
users.user_id as DT_RowId,
users.username as username,
computers.computer_name as computer_name,
count(distinct log1.activity_id) as log1s,
count(distinct log2.activity_id) as log2s,
count(distinct log3.activity_id) as log3s,
count(distinct log4.activity_id) as log4s,
count(distinct log5.activity_id) as log5s,
count(distinct log6.activity_id) as log6s,
count(distinct log7.activity_id) as log7s,
count(distinct log8.activity_id) as log8s,
count(distinct log9.activity_id) as log9s,
count(distinct log10.activity_id) as log10s,
count(distinct log11.activity_id) as log11s
FROM computers
INNER JOIN users
on users.computer_id = computers.computer_id
LEFT JOIN log1
on log1.user_id = users.user_id
LEFT JOIN log2
on log2.user_id = users.user_id
LEFT JOIN log3
on log3.user_id = users.user_id
LEFT JOIN log4
on log4.user_id = users.user_id
LEFT JOIN log5
on log5.user_id = users.user_id
LEFT JOIN realtime_logs AS log6
on log6.user_id = users.user_id AND log6.event_title = 'test1'
LEFT JOIN realtime_logs AS log7
on log7.user_id = users.user_id AND log7.event_title = 'test2'
LEFT JOIN realtime_logs AS log8
on log8.user_id = users.user_id AND log8.event_title = 'test3'
LEFT JOIN realtime_logs AS log9
on log9.user_id = users.user_id AND log9.event_title = 'test4'
LEFT JOIN realtime_logs AS log10
on log10.user_id = users.user_id AND log10.event_title = 'test5'
LEFT JOIN realtime_logs AS log11
on log11.user_id = users.user_id AND log11.event_title = 'test6'
WHERE computers.account_id = :cw_account_id AND computers.status = :cw_status
GROUP BY users.user_id
计划：
computers 1 SIMPLE ref PRIMARY,unique_filter,status unique_filter 4 const 5 Using where; Using temporary; Using filesort
users 1 SIMPLE ref unique_filter unique_filter 4 stephen_inno.computers.computer_id 1 Using index
log1 1 SIMPLE ref user_id user_id 4 stephen_inno.users.user_id 1 Using index
log2 1 SIMPLE ref user_id user_id 4 stephen_inno.users.user_id 1 Using index
log3 1 SIMPLE ref user_id user_id 4 stephen_inno.users.user_id 1 Using index
log4 1 SIMPLE ref user_id user_id 4 stephen_inno.users.user_id 1 Using index
log5 1 SIMPLE ref user_id user_id 4 stephen_inno.users.user_id 1 Using index
log6 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
log7 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
log8 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
log9 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
log10 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
log11 1 SIMPLE ref user_id user_id 771 stephen_inno.users.user_id,const 3 Using index
个人资料：
Copying to tmp table on disk 9.911206 71.86
Sorting result 2.566939 18.61
Sending data 1.055551 7.65
removing tmp table 0.170641 1.24
Copying to tmp table 0.051054 0.37
converting HEAP to MyISAM 0.036204 0.26
Creating tmp table 0.000195 0.00
starting 0.000182 0.00
freeing items 0.000167 0.00
statistics 0.000167 0.00
init 0.000080 0.00
preparing 0.000055 0.00
checking permissions 0.000048 0.00
Opening tables 0.000042 0.00
optimizing 0.000033 0.00
end 0.000023 0.00
Table lock 0.000012 0.00
System lock 0.000008 0.00
logging slow query 0.000006 0.00
cleaning up 0.000006 0.00
query end 0.000004 0.00
executing 0.000004 0.00
结果：
DT_Row Id username computer_name log1 log2 log3 log4 log5 log6 log7 log8 log9 log10 log11
17 testuser COMPUTER_1 0 2 1 0 1 0 0 0 0 0 2
22 testuser2 COMPUTER_2 0 0 0 0 0 0 0 0 0 0 0
23 testuser3 COMPUTER_2 0 0 0 0 0 68 12 12 0 0 6
你可以看到返回13秒这是非常糟糕的。
其他信息：
我应该补充说，这些相同的结果发生在两个不同的服务器上......一个用MySQL 5.1，另一个用5.6。查询对我来说很好看，索引看起来很好，计划看起来很好......我只是不知道为什么现在要执行这么长时间并且在一个非常小的数据集上。