以下のクエリでパフォーマンスに大きな問題があります。リークとは何かがわかりましたが、回避方法がわかりません。
問題は、内部選択が200Kのようなテーブル内のすべてのレコードを調べてから、フィルターを選択して適用しようとし、最初のラウンドでデータ全体が選択されるようにすることです。
SELECT *
FROM (
SELECT
( SELECT GROUP_CONCAT(tp.login) login
FROM tp
WHERE tp.user_id = ue.user_id ) login,
u.email as email,
ue.fname as name
FROM user_extra ue
LEFT JOIN users u ON u.id = ue.user_id
) t
WHERE
email like '%[email protected]%'
OR fname like '%test%'
OR login like '%461988%
テストは間違いを犯していません:
SELECT GROUP_CONCAT(tp.login) login,
u.email as email,
ue.fname as name
FROM user_extra ue
JOIN users u ON u.id = ue.user_id -- I doubt in LEFT
JOIN tp ON tp.user_id = ue.user_id
GROUP BY ue.fname,
u.email
-- , ue.user_id -- maybe needed, but I doubt
HAVING email like '%[email protected]%'
OR fname like '%test%'
OR login like '%461988%
これは中間バリアントであり、後でUNIONと組み合わせた2つ(またはデータによっては3つ)の個別のクエリに分割する必要があります。
1人のユーザーがログインしていない(tpテーブルに彼のレコードがない)場合がありますが、fnameの電子メールで顧客の検索用語が一致したかどうかを表示したいのですが、これを行う方法は?– Ali Mahmoudi
このような場合、このテーブルは外部結合(LEFT JOIN)を使用して結合する必要があります。–アキナ
左結合を使用すると、パフォーマンスが問題になる前のようになり、クエリが200秒間実行されます– Ali Mahmoudi
上で述べたように、これは中間バリアントです。それが正しければ、tp
次の場所にない可能性を考慮して分割しましょう。
SELECT GROUP_CONCAT(tp.login) login,
u.email as email,
ue.fname as name
FROM user_extra ue
JOIN users u ON u.id = ue.user_id -- I doubt in LEFT
LEFT JOIN tp ON tp.user_id = ue.user_id
WHERE u.email like '%[email protected]%'
GROUP BY ue.fname,
u.email
UNION ALL
SELECT GROUP_CONCAT(tp.login) login,
u.email as email,
ue.fname as name
FROM user_extra ue
JOIN users u ON u.id = ue.user_id -- I doubt in LEFT
LEFT JOIN tp ON tp.user_id = ue.user_id
WHERE ue.fname like '%test%'
GROUP BY ue.fname,
u.email
UNION ALL
SELECT GROUP_CONCAT(tp.login) login,
u.email as email,
ue.fname as name
FROM user_extra ue
JOIN users u ON u.id = ue.user_id -- I doubt in LEFT
JOIN tp ON tp.user_id = ue.user_id
GROUP BY ue.fname,
u.email
HAVING login like '%461988%
出力が正しいかどうかをテストします。
重複が発生する場合は、UNIONALLをUNIONDISTINCTに置き換えてください。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加