Rex Johnston added a comment - 2024-06-06 20:47 - edited One obvious improvement to my suggested patch is to choose which key to remove, rather than the easiest (which is the last one). Questions 1) how are key_parts ordered? 2) how do we know which key might be best to deactivate? Shortest? Longest? Coverage? What are optimal conditions for an index merge? Having 2 keys mostly similar has showing itself to be terrible, so perhaps we need to compare keys to each other and deactivate one that is most like another one. Speaking with sanja_byelkin , the idea of free-ing up memory isn't applicable, so we are stuck with these objects left in memory until the statement has finished executing. This isn't terribly great in the context of prepared statements/SP <check this>. Perhaps we might be able to estimate how many SEL_ARGS we are going to allocate and trim used keys first. depends on the structure of the condition being evaluated.