Try one of the following:

• Use InnoDB tables
• Set the default character set to Latin-1 for this database
• edit maintenance/tables.sql and shorten that key from 86 characters to 78 or fewer until it fits

marcus wrote:

*** Bug 5123 has been marked as a duplicate of this bug. ***

mediawiki wrote:

This also happens with the 'jobs' table when UTF-8 is used, see
http://bugs.mysql.com/bug.php?id=4541 for more information. There appears to be
no workaround.

jiri.dlouhy wrote:

It looks that in the tables.sql there is to ambitious definition of table "job":
if I want to use utf-8:

PRIMARY KEY job_id (job_id), KEY (job_cmd, job_namespace, job_title)

The key is 2 * (255 + 255 +8) =1032 - this is too much for mysql

can be job_id or job_cmd little bit shorter??

yvesf wrote:

i manually create job:
(note (128) )
CREATE TABLE tgwiki_job (
job_id INT( 8 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
job_cmd VARCHAR( 128 ) NOT NULL DEFAULT '',
job_namespace INT NOT NULL ,
job_title VARCHAR( 128 ) BINARY NOT NULL ,
job_params BLOB NOT NULL DEFAULT '',
PRIMARY KEY job_id( job_id ) ,
KEY ( job_cmd, job_namespace, job_title )
) ENGINE INNODB;

at this time it seems to work good. But i dont know anything about the consequences.

norman wrote:

*** Bug 5489 has been marked as a duplicate of this bug. ***

gruen0aermel wrote:

In regards to comment #5, I made a similar change, but instead of shortening the
fields, I only shortened the keys generated off those fields.

Here is what I changed in maintenance/tables.sql and
maintenance/archives/patch-job.sql (I had to change both for the config script
to listen to me.) (This was with mediawiki-1.6.7) That change I made was in
the second to last line, adding both the "(128)".

• Jobs performed by parallel apache threads or a command-line daemon

CREATE TABLE /*$wgDBprefix*/job (

job_id int(9) unsigned NOT NULL auto_increment,

-- Command name, currently only refreshLinks is defined
job_cmd varchar(255) NOT NULL default '',

-- Namespace and title to act on
-- Should be 0 and '' if the command does not operate on a title
job_namespace int NOT NULL,
job_title varchar(255) binary NOT NULL,

-- Any other parameters to the command
-- Presently unused, format undefined
job_params blob NOT NULL default '',

PRIMARY KEY job_id (job_id),
KEY (job_cmd(128), job_namespace, job_title(128))

) TYPE=InnoDB;

ainglis wrote:

Previously http://bugzilla.wikimedia.org/show_bug.cgi?id=1322 has helped too

oxyge_007 wrote:

I had the same problem and did the workaround mentioned in
http://bugzilla.wikimedia.org/show_bug.cgi?id=1322#c19 . This helped executing
the update script successfully. Everything works fine, except doing rollbacks.
Then it shows the following error: "1196: Warning: Some non-transactional
changed tables couldn't be rolled back" did anyone experience the same problem?
any solutions?

janrei.g wrote:

I subscribe to wish for a solution to this. I didn't find a workaround yet that
works for me...

jakob wrote:

This bug still irks me, now with the upgrade to 10.0, for an other table;

Creating page_restrictions table...Query "CREATE TABLE wikit_page_restrictions (
pr_page int(8) NOT NULL,
pr_type varchar(255) NOT NULL,
pr_level varchar(255) NOT NULL,
pr_cascade tinyint(4) NOT NULL,
pr_user int(8) NULL,
pr_expiry char(14) binary NULL,
PRIMARY KEY pr_pagetype (pr_page,pr_type),
KEY pr_page (pr_page),
KEY pr_typelevel (pr_type,pr_level),
KEY pr_level (pr_level),
KEY pr_cascade (pr_cascade)
) TYPE=InnoDB
" failed with error code "Specified key was too long. Max key length is 500 (localhost)".

(In reply to comment #11)

pr_type varchar(255) NOT NULL,
pr_level varchar(255) NOT NULL,
(...)
KEY pr_typelevel (pr_type,pr_level),

That's your problem right there. sizeof(pr_type)+sizeof(pr_level) == 510, which is larger than 500. I have no idea why pr_type and pr_level are so insanely large (type is usually "edit" or "move", and level is usually "sysop"), but dropping a few chars from either of these shouldn't cause any trouble.

jon.1234 wrote:

I have had a similar problem with the change to the categorylinks index made on the upgrade from 1.10.1 to 1.11.0. I worked round it by changing the size of the key. Will my change have any long-term adverse effects? See http://www.mediawiki.org/wiki/Manual_talk:Upgrading_to_1.11#Problem_with_change_to_categorylinks_index Cheers!

robchur wrote:

*** Bug 11309 has been marked as a duplicate of this bug. ***

• Bug 9350 has been marked as a duplicate of this bug. ***

There's two issues here: one is that for older versions of MyISAM, the key length was too short. The second issue is that the field was needlessly long.

The latter issue was fixed per bug 9350 comment 6. The former issue can be solved by upgrading or using InnoDB. Marking this WFM.