一个mysql数据库查询性能的问题(二)
table: table_name
07
type: ALL
08
possible_keys: NULL
09
key: NULL
10
key_len: NULL
11
ref: NULL
12
rows: 2357455
13
Extra: Using where
14
1 row in set (0.00 sec)
索引的好坏
MySQL使用一个指标value group size来衡量索引的好坏。什么是value group呢？ 就是具有相同索引key值的行数。这个指标显然是越小越好。最理想的情况就是每一个key值只对应1行， 这样的话我们的每次搜索一个key值都只返回一行，显然速度非常快。
可以用mysql提供的工具查看一个表的索引的好坏。可以先用analyze table语句更新统计，然后用show index来查看统计：
1
mysql> analyze table table_name;
2
+-----------------+---------+----------+----------+
3
| Table | Op | Msg_type | Msg_text |
4
+-----------------+---------+----------+----------+
5
| stat.table_name | analyze | status | OK |
6
+-----------------+---------+----------+----------+
7
1 row in set (3.13 sec)
9
mysql> show index in table_name;
table_name这张表有两个索引PRIMARY和class，PRIMARY这个索引是一个包含4列的多列索引。
Cardinality这个值表示索引值的不同的行数。
例如：
col_key_1值有18行。
col_key_1＋col_key_2 值有392909行。
col_key_1 + col_key_2 + col_key_3 值有235745行。
col_key_1 + col_key_2 + col_key_3 + col_key_4值有235745行。
通过索引值的行数，我们就可以看出来索引好还是不好了。索引值不同的行数越多索引就越好。当索引值不同的行数=表的总行数就达到最理想的情况 value group size = 1了。
B-tree索引和Hash索引的比较
默认情况下MySQL都是使用B-tree索引。来谈一下Hash索引的缺陷:
1 只能处理’=‘ 这种where 子句，而对于< >是无能为力的。 这和B-tree索引是有序的，Hash无序的有关。
2 无法处理order by。 原因同上。
3 无法得知两行之间的距离。 原因同上。
4 只能搜完整的字段，不能只搜字段的一部分。 而对于B-tree索引， 支持搜索字符串最左边的一部分。例如"police%" 。