Question

我正在运行这个mysql语句，你有一个group by和一个聚合函数，avg one。这里的距离函数只是余弦距离函数的实现。

POI是30k行。

且immobilier_ad_blank是500k。

SELECT 
c.id,
avg(dist(a.lat, a.lng, p.lat, p.lng)) as dist
FROM immobilier_ad_blank c
LEFT JOIN Adresse AS a ON c.adresse_id = a.id 
INNER JOIN POI AS p on p.discr = 'YellowPage'
WHERE p.keyword_id = '2' 
     AND p.lat IS NOT NULL 
     AND p.lng IS NOT NULL 
     AND p.lat != '' 
     AND p.lng != '' 
     AND p.lat != 'Latitude' 
     AND p.lng != 'Longitude'
     GROUP BY c.id;

声明是否卡在NULL，Opening table和当我在5.5 Copying Temp table.时

如果我删除GROUP BY c.id和avg函数，语句将在.5秒内执行。

此外，如果使用INSERT INTO语句执行，则大约需要1分钟。

我还尝试手动执行临时表的创建，但它仍然不会移动。

最后，p.lat,p.lng和a.lat,alng都有聚集索引。

供您参考。服务器有2 GIG的内存。有关如何优化此查询的任何帮助。

这是建议的Explain：

[
{
    "id" : 1,
    "select_type" : "SIMPLE",
    "table" : "p",
    "partitions" : NULL,
    "type" : "ref",
    "possible_keys" : "IDX_EB1C5D5C115D4552,idxlat,idxlng",
    "key" : "IDX_EB1C5D5C115D4552",
    "key_len" : "5",
    "ref" : "const",
    "rows" : 228,
    "filtered" : 2.50,
    "Extra" : "Using where; Using temporary; Using filesort"
},
{
    "id" : 1,
    "select_type" : "SIMPLE",
    "table" : "c",
    "partitions" : NULL,
    "type" : "index",
    "possible_keys" : "PRIMARY,UNIQ_5E6BC6424B30D9C4,IDX_5E6BC6424DE7DC5C,IDX_5E6BC642999F7763,IDX_5E6BC642DB5A7180,IDX_5E6BC642498DA827,IDX_5E6BC64212469DE2,IDX_5E6BC642CC093B4A,IDX_5E6BC642900733ED,IDX_5E6BC642E1780C00,IDX_5E6BC6421BD9F3C1,idx1,idx2,idx3,idx4,idx5,idx6,idx0",
    "key" : "IDX_5E6BC6424DE7DC5C",
    "key_len" : "4",
    "ref" : NULL,
    "rows" : 560280,
    "filtered" : 100.00,
    "Extra" : "Using index; Using join buffer (Block Nested Loop)"
},
{
    "id" : 1,
    "select_type" : "SIMPLE",
    "table" : "a",
    "partitions" : NULL,
    "type" : "eq_ref",
    "possible_keys" : "PRIMARY",
    "key" : "PRIMARY",
    "key_len" : "4",
    "ref" : "mganalyst.c.adresse_id",
    "rows" : 1,
    "filtered" : 100.00,
    "Extra" : NULL
}
]

我个人强烈认为它与临时表创建有关。你如何解释insert into在常规选择占用> 2小时时需要1分钟。

Answer 1

我无法告诉你哪里出了问题，但我同意它似乎异常缓慢，看起来它不应该是。我可以给你3个地方看看如何。

确保它不是该功能。仅使用avg(dist(...))替换avg(a.lat)函数，然后重新运行查询。看看是否存在显着差异。如果有，请查看优化dist(...)函数。
查看问题是否在其中一个联接中。将选择更改为SELECT count(1) cnt ...，删除GROUP BY并执行。如果它仍然很慢，则依次删除每个连接，以查看哪个连接可能导致减速。如果在删除其中一个连接后查询速度大大提高，请查看它用于连接两个表的索引。如果不是，请将其中一个放入。
在黑暗中拍摄：运行＆＃39;优化表xxx＆＃39;在所有三个表格中，看看是否有帮助。

希望其中一条建议有所帮助。

GROUP BY需要永远

1 个答案: