btr0cur.c, ha_innobase.cc:

  Fine-tune optimization parameters; in small tables the estimates are accurate; in big tables let us not be too optimistic about index selectivity

innobase/btr/btr0cur.c

@@ -2552,6 +2552,7 @@ btr_estimate_number_of_different_key_vals(
 	ulint		total_external_size = 0;
 	ulint		i;
 	ulint		j;
+	ulint		add_on;
 	mtr_t		mtr;
 
 	n_cols = dict_index_get_n_unique(index);
@@ -2624,8 +2625,25 @@ btr_estimate_number_of_different_key_vals(
 				 + not_empty_flag)
 		                	/ (BTR_KEY_VAL_ESTIMATE_N_PAGES
 		                	   + total_external_size);
-	}
 	
+		/* If the tree is small, smaller than <
+		10 * BTR_KEY_VAL_ESTIMATE_N_PAGES + total_external_size, then
+		the above estimate is ok. For bigger trees it is common that we
+		do not see any borders between key values in the few pages
+		we pick. But still there may be BTR_KEY_VAL_ESTIMATE_N_PAGES
+		different key values, or even more. Let us try to approximate
+		that: */
+
+		add_on = index->stat_n_leaf_pages /
+		   (10 * (BTR_KEY_VAL_ESTIMATE_N_PAGES + total_external_size));
+
+		if (add_on > BTR_KEY_VAL_ESTIMATE_N_PAGES) {
+			add_on = BTR_KEY_VAL_ESTIMATE_N_PAGES;
+		}
+		
+		index->stat_n_diff_key_vals[j] += add_on;
+	}
+		
 	mem_free(n_diff);
 }
 

sql/ha_innobase.cc

@@ -3130,22 +3130,6 @@ ha_innobase::info(
 					rec_per_key = 1;
 				}
 			
-				/* Since the MySQL optimizer is often too
-				pessimistic in the assumption that a table
-				does not fit in the buffer pool, we
-				increase the attractiveness of indexes
-				by assuming the selectivity of any prefix
-				of an index is 1 / 100 or better.
-				(Actually, we should look at the table
-				size, and if the table is smaller than
-				the buffer pool, we should uniformly
-				increase the attractiveness of indexes,
-				regardless of the estimated selectivity.) */
-
-			        if (rec_per_key > records / 100) {
-				        rec_per_key = records / 100;
-				}
-
 				table->key_info[i].rec_per_key[j]
 								= rec_per_key;
 			}