Bug#21566735: ASSERTION `LENGTH > 0 && KEYPARTS != 0' FAILED.

An assert failure is seen in some queries which have a semijoin and
use the materialization strategy.

The assertion fails if either the length of the key is zero or the
number of key parts is zero. This could indicate two different
problems.

1) If the length is zero, there may not be a problem, as it can
legitimately be zero if, for example, the key is a zero-length string.

2) If the number of key parts is zero, there is a bug, as a key must
have at least one part.

The patch fixes issue #1 by removing the length check in the
assertion.

Issue #2 happens if JOIN::update_equalities_for_sjm() doesn't
recognize the expression selected from a subquery, and fails to
replace it with a reference to a column in a temporary table that
holds the materialized result. This causes it to not recognize it as a
part of the key later, and keyparts could end up as zero. The patch
fixes it by calling real_item() on the expression in order to see
through Item_refs that may wrap the expression if the subquery reads
from a view.

sql/sql_optimizer.cc

@@ -4798,7 +4798,7 @@ bool JOIN::update_equalities_for_sjm()
         uint fieldno= 0;
         while ((old= it++))
         {
-          if (old->real_item()->eq(keyuse->val, false))
+          if (old->real_item()->eq(keyuse->val->real_item(), false))
           {
             /*
               Replace the expression selected from the subquery with the

sql/sql_select.cc

@@ -1199,7 +1199,7 @@ void calc_length_and_keyparts(Key_use *keyuse, JOIN_TAB *tab, const uint key,
     }
     keyuse++;
   } while (keyuse->table_ref == tab->table_ref && keyuse->key == key);
-  DBUG_ASSERT(length > 0 && keyparts != 0);
+  DBUG_ASSERT(keyparts > 0);
   *length_out= length;
   *keyparts_out= keyparts;
 }