-- to determine sort order. Sorting is by binary order, which
-- isn't always ideal, but collations seem to be an exciting
-- and dangerous new world in MySQL...
- cl_sortkey varchar(255) binary NOT NULL default '',
+ --
+ -- For MySQL 4.1+ with charset set to utf8, the sort key *index*
+ -- needs cut to be smaller than 1024 bytes (at 3 bytes per char).
+ -- To sort properly on the shorter key, this field needs to be
+ -- the same shortness.
+ cl_sortkey varchar(86) binary NOT NULL default '',
-- This isn't really used at present. Provided for an optional
-- sorting method by approximate addition time.
UNIQUE KEY cl_from(cl_from,cl_to),
- -- This key is trouble. It's incomplete, AND it's too big
- -- when collation is set to UTF-8. Bleeeacch!
- KEY cl_sortkey(cl_to,cl_sortkey(128)),
+ -- We always sort within a given category...
+ KEY cl_sortkey(cl_to,cl_sortkey),
-- Not really used?
KEY cl_timestamp(cl_to,cl_timestamp)
-- See isCountable() in includes/Article.php
ss_good_articles bigint(20) unsigned default '0',
+ -- Total pages, theoretically equal to SELECT COUNT(*) FROM page; except faster
+ ss_total_pages bigint(20) default -1,
+
+ -- Number of users, theoretically equal to SELECT COUNT(*) FROM user;
+ ss_users bigint(20) default -1,
+
+ -- Deprecated, no longer updated as of 1.5
+ ss_admins int(10) default -1,
+
UNIQUE KEY ss_row_id (ss_row_id)
) TYPE=InnoDB;
--
-- Stores an ID for every time any article is visited;
-- depending on $wgHitcounterUpdateFreq, it is
--- periodically cleared and the cur_counter column
--- in the cur table updated for the all articles
+-- periodically cleared and the page_counter column
+-- in the page table updated for the all articles
-- that have been visited.)
--
CREATE TABLE /*$wgDBprefix*/hitcounter (