Wauw! Dat is de meest gecompliceerde "index merge" die ik heb gezien.
Meestal (misschien altijd ), kunt u een 'samengestelde' index maken om een index-merge-intersect te vervangen, en beter presteren . Wijzig key2 van slechts (pinned) naar (pinned, DeviceId) . Dit mag verwijder het 'kruispunt' en versnel het.
Over het algemeen gebruikt de Optimizer index-samenvoeging alleen in wanhoop. (Volgens mij is dit het antwoord op de titelvraag.) Bij eventuele kleine wijzigingen in de zoekopdracht of de betrokken waarden, voert de Optimizer de zoekopdracht uit zonder indexsamenvoeging.
Een verbetering ten opzichte van de tijdelijke tabel __codes is om een permanente tabel te bouwen met een groot bereik aan waarden, en vervolgens een bereik van waarden uit die tabel te gebruiken in uw Proc. Als je MariaDB gebruikt, gebruik dan de dynamisch gebouwde "sequence"-tabel. Bijvoorbeeld de 'tabel' seq_1_to_100 is effectief een tabel van één kolom met getallen 1..100. U hoeft het niet te declareren of in te vullen.
Je kunt de andere REPEAT wegdoen lus door berekenen de tijd van Code .
LOOPs vermijden zal het grootste prestatievoordeel zijn.
Krijg dat allemaal voor elkaar, dan heb ik misschien andere tips.