MySQL：哈希索引与表联接

Question

I'm have pretty big MySQL table(more than 10 millions of rows, innoDB engine), the table has a field that indicate a row's category( varchar(40) ), the categories are less than 10.

Now I have two choices:

1. keep the field and make a hash index on it.
2. make the field into another category table, and link them with a category_id

Which one has a better performance and why with these two operations:

1. Query for all categories(I know a seperated table could be faster, but does it really faster a lot? even compare to hash index ?)
2. Query for all rows that in a specified category(I assume hash index should be faster, but not sure, cause someone told me MySQL opitimizer will make table join with small table much faster)

EDIT : I almost never add new categories here.

Answer 1

You can define an index on your category column, and it will make some queries for a specific category much faster (assuming the category you search for doesn't occur in a majority of rows). An index on a varchar works well in this way.

The reason you might create a lookup table for the category name is that if you want to change a category name, you can do that by changing one row in the category lookup table, instead of potentially many thousands of rows in the main table.

By the way, your use of the phrase "hash index" is misplaced. InnoDB does not support hash indexes, only B-tree indexes and fulltext indexes.

Answer 2

Considering that for any DB it is faster to check a number (integer) than a string. I believe that the fastest result will be received if you create a X-REF table as you mentioned which converts the strings into a number which is the ID of the big table records, and have this field set as an index.

As stated, you will gain performance by assisting your DB to compare 10M numbers instead of 10M strings.

Also, as Bill Karwin suggests, this will allow you to change/add categories in the most flexible way.

Last, if you don't expect the total number of categories to grow above, say, 2000, you may even make the index field of the big table to be just a two-bytes integer.