Hi,

I’ve been investigating some slowness issues with our database and discovered that some of the tables don’t have primary keys – e.g. eprint__index.

On our live system running 3.3.10 (migrated from 3.1.1, and 2.[something] before then), this is the table definition:

mysql> SHOW CREATE TABLE eprint__index \G

*************************** 1. row ***************************

       Table: eprint__index

Create Table: CREATE TABLE `eprint__index` (

  `fieldword` varchar(255) DEFAULT NULL,

  `pos` int(11) DEFAULT NULL,

  `ids` text,

  KEY `pos` (`pos`),

  KEY `fieldword` (`fieldword`,`pos`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1

 

There are two keys, but no primary key.

 

On a dev install of EPrints 3.3.12, this is the table definition:

mysql> SHOW CREATE TABLE eprint__index \G

*************************** 1. row ***************************

       Table: eprint__index

Create Table: CREATE TABLE `eprint__index` (

  `fieldword` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,

  `pos` int(11) NOT NULL,

  `ids` longtext CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,

  PRIMARY KEY (`fieldword`,`pos`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

 

A primary key exists.

There are differences in the version of MySQL, but it looks like there’s a possibility that during an upgrade either the __index tables were missed out of some update, or excluded for some reason.

There is also the difference in character set – which should be caught by ~/bin/epadmin:upgrade_3_1_2_to_3_2_0

 

Inspecting the code, this block: https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Database.pm#L599-L605 will not add the primary key to existing tables.

 

Can anyone shed any light on this?

Do your __index tables have a primary key?

 

Cheers,

John