Bug#35894664: Assertion in Bitmap<64>::is_set(uint)

              when forcing a spatial index scan.
Bug#36361834: Incorrect result of getting data from a
              spatial index on column with SRID
Bug#36366621: MySQL crash when explaining a force a
              spatial index containing column with SRID

Bug#36361834:
While setting up keys that could be used for covering
index scans, a "geometry" keypart makes an index not
covering. However, in case of innodb, a secondary index
is always extended with primary key. While setting up
the extended keypart spatial index is marked as covering.
With force index in effect, spatial index is the only
available index for optimizer to choose from. It picks
"index-skip-scan" for the table. However, innodb does
not support sequential scans on spatial indexes. This
leads to wrong results with no rows retrieved.

Bug#35894664 and Bug#36366621:
When choosing covering index scans, optimizer picks
the shortest covering key available. However, for
the case where spatial index is the only available
option, it fails to pick any index to do the index
scan which leads to problems later.

Solution to all these issues is that spatial indexes
should not be marked as indexes that could be used
for index only reads. There are a few inconsistencies
in the code w.r.t this. So we try to correct them.
While setting up keyparts, "geometry" field
makes the index not covering but having an extended
keypart which is not a geometry field makes the index
covering which should not be the case. So we now disable
spatial index for "index-only" reads irrespective of the
extended keyparts.
When introducing the change to disable "index-only" reads
for indexes having "geometry" fields as part of
Bug#19806196, "spatial index" was not expected to be
part of "prefix keys" as well. However, it was enabled
after some of the checks were changed/moved later.
This also led to an inconsistency.
E.g if the indexed "geometry" field is used as part of
the query, even though originally the spatial index was
indeed marked as covering (because of the extended
keyparts), while setting up  the "geometry" field
(in set_field()), prefix keys for the field are removed
from the "covering_keys" keymap which made the spatial
index as not covering. This is also the reason we do
not see problems for cases where the indexed field is
part of the query.
So we fix this inconsistency by disabling "spatial indexes"
to be considered as prefix keys.
There was a check to disable picking a "spatial index" to
do covering index scan late in optimization phase. This is
removed now as it is taken care much earlier.

Change-Id: I44c04f79f35a270087a01c962f9ad35f5e3ad534

Author: Chaithra Gopalareddy

sql/sql_optimizer.cc

@@ -1963,14 +1963,18 @@ uint find_shortest_key(TABLE *table, const Key_map *usable_keys) {
       if (nr == usable_clustered_pk) continue;
       if (usable_keys->is_set(nr)) {
         /*
-          Can not do full index scan on rtree index because it is not
-          supported by Innodb, probably not supported by others either.
+          Cannot do full index scan on rtree index. It is not supported by
+          Innodb as it's rtree index does not store data, but only the
+          minimum bouding box (maybe makes sense only for geometries of
+          type POINT). Index scans on rtrees are probabaly not supported
+          by other storage engines either.
           A multi-valued key requires unique filter, and won't be the most
           fast option even if it will be the shortest one.
          */
         const KEY &key_ref = table->key_info[nr];
-        assert(!(key_ref.flags & HA_MULTI_VALUED_KEY));
-        if (key_ref.key_length < min_length && !(key_ref.flags & HA_SPATIAL)) {
+        assert(!(key_ref.flags & HA_MULTI_VALUED_KEY) &&
+               !(key_ref.flags & HA_SPATIAL));
+        if (key_ref.key_length < min_length) {
           min_length = key_ref.key_length;
           best = nr;
         }

sql/table.cc

@@ -738,22 +738,25 @@ void setup_key_part_field(TABLE_SHARE *share, handler *handler_file,
 
   const bool full_length_key_part =
       field->key_length() == key_part->length && !field->is_flag_set(BLOB_FLAG);
+  const bool is_spatial_key = Overlaps(keyinfo->flags, HA_SPATIAL);
   /*
     part_of_key contains all non-prefix keys, part_of_prefixkey
     contains prefix keys.
     Note that prefix keys in the extended PK key parts
     (part_of_key_not_extended is false) are not considered.
-    Full-text keys are not considered prefix keys.
+    Full-text and spatial keys are not considered prefix keys.
   */
   if (full_length_key_part || Overlaps(keyinfo->flags, HA_FULLTEXT)) {
     field->part_of_key.set_bit(key_n);
     if (part_of_key_not_extended)
       field->part_of_key_not_extended.set_bit(key_n);
-  } else if (part_of_key_not_extended) {
+  } else if (part_of_key_not_extended && !is_spatial_key) {
     field->part_of_prefixkey.set_bit(key_n);
   }
+  // R-tree indexes do not allow index scans and therefore cannot be
+  // marked as keys for index only access.
   if ((handler_file->index_flags(key_n, key_part_n, false) & HA_KEYREAD_ONLY) &&
-      field->type() != MYSQL_TYPE_GEOMETRY) {
+      !is_spatial_key) {
     // Set the key as 'keys_for_keyread' even if it is prefix key.
     share->keys_for_keyread.set_bit(key_n);
   }