Last modified: 2011-03-02 00:47:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18645, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16645 - Inconsistent indices on pagelinks, imagelinks, templatelinks tables
Inconsistent indices on pagelinks, imagelinks, templatelinks tables
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.14.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 16012
  Show dependency treegraph
 
Reported: 2008-12-14 18:21 UTC by Roan Kattouw
Modified: 2011-03-02 00:47 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2008-12-14 18:21:22 UTC
The pl_from (pl_from, pl_namespace, pl_title), il_from (il_from, il_to) and tl_from (tl_from, tl_namespace, tl_title) indices are UNIQUE, while the pl_namespace (pl_namespace, pl_title, pl_from), il_to (il_to, il_from) and tl_namespace (tl_namespace, tl_title, tl_from) indices aren't. They contain the same fields, though, so if one is UNIQUE the other one should be UNIQUE too.
Comment 1 Brion Vibber 2008-12-15 19:32:25 UTC
Only one constraint is necessary. Would there be any benefit to applying the constraint to the other permutations?
Comment 2 Roan Kattouw 2008-12-15 20:44:45 UTC
Well of course there's no added value in terms of constraints, but it could help MySQL optimize stuff, I guess (that really is just a guess, I have no idea).
Comment 3 Brad Jorsch 2008-12-15 20:58:51 UTC
It could make the difference between MySQL using "const" or "eq_ref" instead of "ref" when planning the query. MySQL doesn't seem to be smart enough to realize the non-UNIQUE key is still going to be unique.

I ran the following test:

create table foo (i integer not null, j integer not null, unique key key1 (i,j), key key2 (i,j)) engine=InnoDB;

-- Insert 100 records into foo, for (0,0) - (9,9)

explain select * from foo force index (key1) where i=4 and j=2;
|  1 | SIMPLE      | foo   | const | key1          | key1 | 8       | const,const |    1 | Using index | 

explain select * from foo force index (key2) where i=4 and j=2;
|  1 | SIMPLE      | foo   | ref  | key2          | key2 | 8       | const,const |    1 | Using index | 
Comment 4 Roan Kattouw 2009-01-16 23:15:27 UTC
Fixed in r45821.
Comment 5 Tim Starling 2009-03-11 00:55:30 UTC
Adding UNIQUE fields does not speed MySQL up, it slows it down. This is documented in the MySQL manual: removing unique constraints is suggested as a means of speeding up INSERTs.
Comment 6 Brad Jorsch 2009-03-11 11:10:14 UTC
The "speeding up" discussed above regards SELECT performance, not INSERT performance. Does adding uniqueness constraints really not speed up SELECTs in MySQL?
Comment 7 Roan Kattouw 2009-03-11 13:52:04 UTC
(In reply to comment #6)
> The "speeding up" discussed above regards SELECT performance, not INSERT
> performance. Does adding uniqueness constraints really not speed up SELECTs in
> MySQL?
> 

I guess someone (me?) would have to see whether we actually have any SELECTs in the code that would benefit from this additional UNIQUE index.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links