Problem:
When invalid string data is present in a where clause of an update statement,
range scan is not used. Instead index scan is picked. This can be seen
as a performance regression because scanning the entire index for non
existent value can take very long time.

Analysis:
W.r.t the query presented in the bugpage, while trying to store the
predicate value in range optimizer to create a key, it truncates
the entire string as it is invalid. Earlier, for such a case,
range optimizer used to create the key with an empty string.
This changed in 5.6 with the fix for Bug#11752201. With the current
implementation (both in 5.6 and 5.7), range optimizer bails
out seeing the invalid data allowing index scan to do the job.

Solution:
We detect an invalid string and if the condition has an equality operator
we return an impossible WHERE condition from range optimizer since an
invalid string can never be equal to a valid string.