PLATFORM-1914: update querycache schema for new wikis

[macbre]

PLATFORM-1914

Due to a MySQL 5.6 bug InnoDB tables that do not have primary key defined has problems with replication of heavy transactions (with tens of thousands of rows involved).

We noticed this behavior during updateSpecialPages.php script run which performs heavy (DELETE + INSERT queries) operations on querycache table. This was quite visible when ruvlab wiki was processed - the maintenance script was performing a transaction with delete and insert of 75k rows causing huge lag on c1 cluster.

querycache table indeed lacks a primary key, so let's add it for new wikis.

Before:

CREATE TABLE `querycache` (
  `qc_type` varbinary(32) NOT NULL,
  `qc_value` int(10) unsigned NOT NULL DEFAULT '0',
  `qc_namespace` int(11) NOT NULL DEFAULT '0',
  `qc_title` varchar(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '',
  KEY `qc_type` (`qc_type`,`qc_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

+--------------+------------------+------+-----+---------+-------+
| Field        | Type             | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------+-------+
| qc_type      | varbinary(32)    | NO   | MUL | NULL    |       |
| qc_value     | int(10) unsigned | NO   |     | 0       |       |
| qc_namespace | int(11)          | NO   |     | 0       |       |
| qc_title     | varchar(255)     | NO   |     |         |       |
+--------------+------------------+------+-----+---------+-------+

After:

CREATE TABLE `querycache` (
  `qc_type` varbinary(32) NOT NULL,
  `qc_value` int(10) unsigned NOT NULL DEFAULT '0',
  `qc_namespace` int(11) NOT NULL DEFAULT '0',
  `qc_title` varchar(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '',
  UNIQUE KEY `qc_type_value_ns_title` (`qc_type`,`qc_value`,`qc_namespace`,`qc_title`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

+--------------+------------------+------+-----+---------+-------+
| Field        | Type             | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------+-------+
| qc_type      | varbinary(32)    | NO   | PRI | NULL    |       |
| qc_value     | int(10) unsigned | NO   | PRI | 0       |       |
| qc_namespace | int(11)          | NO   | PRI | 0       |       |
| qc_title     | varchar(255)     | NO   | PRI |         |       |
+--------------+------------------+------+-----+---------+-------+

@drozdo / @wladekb / @adamkarminski

[macbre]

This simply can't be related to a SQL schema file change.

VideoPageToolAssetTest::testCRUDAsset with data set #0 ('VideoPageToolAssetFeatured', 1, array('test_title', 'Test Display Title', 'This is a test description', 'Alternate Thumb Title'))
Not able to load saved asset
Failed asserting that null matches expected 15463.

[wladekb]

lgtm, only wondering how big the index will be but it's unlikely to get us into big trouble

[macbre]

@wladekb - take a look at the last comment in PLATFORM-1914

Due to the way InnoDB handles primary key and data storage we actually improve the data and index size (for lyricwiki the current data + index size for querycache is just 37% when compared with the size before the fix).

Table data in InnoDB are stored in the index structure of primary key (explicit or implicit). So, primary key is data and there is no need to report its size as (secondary) index size.

[wladekb]

Unbelievable :) Thanks for the research.