MySQL:Pilih eksekusi kueri dan waktu pengambilan hasil meningkat dengan jumlah koneksi

Mungkin setiap koneksi melakukan pemindaian tabel lengkap dari profiles . Mari kita coba untuk menghindarinya. Ketika ada lusinan kueri yang mengenai tabel yang sama, ada kunci yang menyebabkan InnoDB "tersandung sendiri". Salah satu dari paket ini akan mempercepat kueri dan mengurangi jumlah baris yang disentuh (karenanya mengurangi penguncian). Penggunaan indeks "komposit" yang disarankan akan mempercepat kueri. Tapi OR menghalangi. Saya melihat dua trik untuk tetap melihat indeks di uniquestring , tetapi hindari beberapa atau semua OR .

(      (prfls.uniquestring like 'phk5600dcc%')
   or  (prfls.uniquestring like 'phk5600dcf%')
)

OR sulit untuk dioptimalkan.

Tambahkan ini:

INDEX(isconnected, isprofilepresent, uniquestring)

Lalu...

Paket A:

prfls.uniquestring         like 'phk5600dc%' AND  -- note common prefix
(      (prfls.uniquestring like 'phk5600dcc%')
   or  (prfls.uniquestring like 'phk5600dcf%')
)

Ini mengasumsikan Anda dapat membuat awalan umum itu.

Paket B (putar OR ke dalam UNION ):

( SELECT ...
    WHERE prfls.uniquestring like 'phk5600dcc%' AND ...
    LIMIT 450 )
UNION ALL    -- ? You may want DISTINCT, if there could be dups
( SELECT ...
    WHERE prfls.uniquestring like 'phk5600dcf%' AND ...  -- the only diff
    LIMIT 450 )
LIMIT 450   -- yes, again

Rencana A (jika praktis) memanfaatkan apa yang tampaknya menjadi nilai awal yang umum. Rencana B berfungsi, tetapi mungkin sedikit lebih lambat, meskipun masih jauh lebih cepat daripada yang asli.

Catatan lainnya...

Indeks pada flag (yang Anda miliki dua) hampir tidak pernah digunakan. EXPLAIN SELECT ... mungkin akan menunjukkan bahwa keduanya tidak digunakan. Harap berikan EXPLAIN untuk SELECT yang perlu didiskusikan.

UNIQUE KEY adalah KEY , jadi tidak perlu indeks yang berlebihan pada USERID .

limit 450 -- 450 mana yang Anda inginkan? Tanpa ORDER BY , kueri diizinkan untuk memberi Anda apa saja 450. (Tentu saja, mungkin tidak masalah.) (Dan ORDER BY mungkin akan memperlambat kueri.)

Saran saya tidak akan "menyelesaikan" masalah, tetapi harus meningkatkan jumlah koneksi sebelum perlambatan terlihat.