我很感激任何帮助,试图找到基本查询表连接上非常慢的返回时间的原因。
我遇到了麻烦所以我打开了19.7903秒的分析和查询返回显示以下个人资料详情:
Profiling
Status Time
starting 0.000044
Opening tables 0.000067
System lock 0.000002
Table lock 0.000006
init 0.000009
optimizing 0.000005
statistics 0.000011
preparing 0.000014
executing 0.000031
Sending data 0.000050
end 0.000004
end 0.000003
query end 0.000002
freeing items 0.000009
closing tables 0.000003
removing tmp table 0.000011
closing tables 0.000003
logging slow query 0.000002
cleaning up 0.000003
Showing rows 0 - 29 (2,200 total, Query took 19.7903 sec)
我不明白为什么配置文件时间不等于" 19.7903秒"。
查询是:
SELECT OWNER.ID OWNER_ID,
OWNER.LAST_NAME OWNER_LAST_NAME,
OWNER.FIRST_NAME OWNER_FIRST_NAME,
OWNER.PHONE_HOME_AREACODE OWNER_PHONE_HOME_AREACODE,
OWNER.PHONE_HOME_PREFIX OWNER_PHONE_HOME_PREFIX,
OWNER.PHONE_HOME_LINE_NUMBER OWNER_PHONE_HOME_LINE_NUMBER,
OWNER.PHONE_CELL_AREACODE OWNER_PHONE_CELL_AREACODE,
OWNER.PHONE_CELL_PREFIX OWNER_PHONE_CELL_PREFIX,
OWNER.PHONE_CELL_LINE_NUMBER OWNER_PHONE_CELL_LINE_NUMBER,
/*Some columns from OWNER removed for brevity*/
OWNER.CITY OWNER_CITY,
OWNER.PROVINCE OWNER_PROVINCE,
OWNER.POSTAL OWNER_POSTAL,
OWNER.NOTES OWNER_NOTES,
OWNER.REFERRED_BY OWNER_REFERRED_BY,
VISITOR.NAME VISITOR_NAME,
VISITOR.SIZE VISITOR_SIZE,
VISITOR.INACTIVE VISITOR_INACTIVE,
VISITOR.ID VISITOR_ID,
VISITOR.DELETED VISITOR_DELETED,
VACCINATIONS.CANINE_DISTEMPER_PARVOVIRUS_EXPIRES VACCINATIONS_CANINE_DISTEMPER_PARVOVIRUS_EXPIRES,
VACCINATIONS.CANINE_RABIES_EXPIRES VACCINATIONS_CANINE_RABIES_EXPIRES,
VACCINATIONS.CANINE_BORDETELLA_EXPIRES VACCINATIONS_CANINE_BORDETELLA_EXPIRES,
VACCINATIONS.FELINE_FVRCPC_EXPIRES VACCINATIONS_FELINE_FVRCPC_EXPIRES,
VACCINATIONS.FELINE_RABIES_EXPIRES VACCINATIONS_FELINE_RABIES_EXPIRES
FROM OWNER
LEFT JOIN VISITOR
ON VISITOR.OWNER_ID = OWNER.ID
LEFT JOIN VACCINATIONS
ON VACCINATIONS.VISITOR_ID = VISITOR.ID
ORDER BY VISITOR_NAME
EXPLAIN的结果:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE OWNER ALL NULL NULL NULL NULL 1483 Using temporary; Using filesort
1 SIMPLE VISITOR ref OWNER_ID OWNER_ID 4 wayDEV.OWNER.ID 1
1 SIMPLE VACCINATIONS ALL VISITOR_ID NULL NULL NULL 2059
的索引:
VISITOR:
Indexes: Documentation Keyname Type Cardinality Action Field
PRIMARY PRIMARY 2227 Edit Drop ID
NAME INDEX 2227 Edit Drop NAME
OWNER_ID INDEX 2227 Edit Drop OWNER_ID
OWNER:
Indexes: Documentation Keyname Type Cardinality Action Field
PRIMARY PRIMARY 1601 Edit Drop ID
LAST_NAME INDEX 1601 Edit Drop LAST_NAME
VACCINATIONS:
Indexes: Documentation Keyname Type Cardinality Action Field
PRIMARY PRIMARY 2131 Edit Drop ID
VISITOR_ID UNIQUE 2131 Edit Drop VISITOR_ID
BOARDING:
Indexes: Documentation Keyname Type Cardinality Action Field
PRIMARY PRIMARY 2256 Edit Drop ID
OWNER INDEX 2256 Edit Drop OWNER_ID
VISITOR INDEX 2256 Edit Drop VISITOR_ID
GROOMING:
Indexes: Documentation Keyname Type Cardinality Action Field
PRIMARY PRIMARY 2077 Edit Drop ID
VISITOR_ID UNIQUE 2077 Edit Drop VISITOR_ID
OWNER INDEX 2077 Edit Drop OWNER_ID
此查询已执行好几个月。它只是最近才会间歇性地恢复变慢。大约20%的时间它会很慢。其余的时间它返回正常(显示行0 - 29(总共2,200,查询花了0.0018秒))。 ? :\
这可能是一个间歇性问题,这表明有些问题 查询本身的其他问题?? <<<<<<<<<
正如我上面提到的...... 我不明白为什么配置文件时间不等于" 19.7903秒"。
'个人资料'时间和总数,查询'时间,加起来?<<<<<<<<
整个数据库中只有几千条记录。
任何帮助将不胜感激。我在Godaddy服务器上。
(我知道我的查询可能存在问题。或者它可能会被优化。但我在这里问一些非常具体的问题 - 由..."< <<<<<<&#34)
老实说......我们在这里谈论>>>>>>>&n;<<<<<<< 秒了! 当然这个2000记录数据库的查询不应该回来20秒???
答案 0 :(得分:0)
问题是您是通过LEFT JOIN中第二个表中的字段进行排序的。也就是说,没有索引实际上可以有效地用于排序,因此MySQL在每行中对整行的大量数据进行排序。 MySQL中常见的查询解决方案就是只选择id并在子查询中进行排序,然后再连接到其余的colums。当你做一些paginagion时也是如此(LIMIT也应该在子查询中)。
您需要在VISITOR上使用复合覆盖索引(owner_id,name),并在疫苗接种上使用(visitor_id)。
现在按如下方式重写查询:
SELECT ...
FROM (
SELECT o.ID as o_ID, v.ID as v_ID
FROM OWNER o
LEFT JOIN VISITOR v ON o.ID = v.OWNER_ID
ORDER BY v.NAME
) ids
JOIN OWNER o ON o.ID = ids.o_ID
LEFT JOIN VISITOR v ON v.ID = ids.v_ID
LEFT JOIN VACCINATIONS v2 ON v2.VISITOR_ID = v.ID;
答案 1 :(得分:0)
列的数据类型不是相同的 - 即
OWNER.ID - DATA TYPE = (int7)
VISITOR.OWNER_ID - DATA TYPE = (int7)
VACCINATIONS.VISITOR_ID - DATA TYPE = (varchar7)
设置数据类型 - 对于VACCINATIONS.VISITOR_ID - (int7)
,解决了缓慢 - 此表连接超过5000条记录,现在与任何其他MySQL调用一样快。
谢谢" GURU" http://forums.phpfreaks.com/topic/173475-left-join-extremely-slow-any-way-to-remedy-16000-lines/