1. Secondary indexes (but not the PRIMARY KEY) requires additional disk space. A
secondary index implicitly includes copies the field(s) of the PRIMARY KEY; this is how it
can get to the actual data row. Finding a row via a secondary key involves two BTree
lookups -- one in the secondary index, one in the primary key index (which has the data
2. With file_per_table, that is in the .ibd; without file_per_table that is in ibdata1.
Probably the identical amount of space either way.
file_per_table is almost always the better way to go. However, it is awkward to convert a
big existing system, since it is not easy to free up the space already taken by ibdata1.
> -----Original Message-----
> From: Pothanaboyina Trimurthy [mailto:skd.trimurthy@stripped]
> Sent: Tuesday, October 30, 2012 6:35 AM
> To: mysql@stripped
> Subject: index & innodb
> hi lists
> 1. does the indexes require additional storage other than the
> table space storage.
> 2. is there any performance difference will be there, if we go
> for innodb_file_per_table.
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql
|• index & innodb||Pothanaboyina Trimurthy||30 Oct|
| • RE: index & innodb||Rick James||31 Oct|