MySQL Bugs: #3440: 32 indices isn't enough

Bug #3440	32 indices isn't enough
Submitted:	11 Apr 2004 20:36	Modified:	26 Apr 2004 12:03
Reporter:	Matthias Urlichs	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S4 (Feature request)
Version:	4.1	OS:	Linux (Linux 2.4)
Assigned to:	Sergei Golubchik	CPU Architecture:	Any

Description:
32 indices is not enough for big systems.

I am working on a large 3rd-party ERP system to play nicely with mysql; that system has several tables with >32 columns which refer to other tables. Since InnoDB demands indices on "foreign key" columns, I cannot assure referential integrity, which is not something my customer is going to be happy about.

How to repeat:
Create a table with >32 indices.

Suggested fix:
Use a "long long" to represent the indices / their bitmap.

The major part of allowing more than 32 keys per table (converting uint-based bitmap to arbitrary length bitmap and extending frm file) was done already.

By changing MAX_KEY (unireg.h) and typedef key_map (mysql_priv.h) you can have more that 32 indexes per table. (you'll have to recompile MySQL, but it's not a problem for you as far as I remember :)

I'll check whether (and when) it may go into the mainstream version.

A patch (including Bitmap<32> ;-) -- actually two changes, so if you decide to keep MAX_KEY at 32 for now, which IMHO would be a mistake, you can drop the second one) is available at

bk://smurf.noris.de/tmp/mysql41

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Ok, I increased MAX_KEY (and MI_MAX_KEY to cover MyISAM case) to 64.
Pushing now.
Will be in 4.1.2