wp_postmeta
索引效率低下。已发布的表(参见Wikipedia)为
CREATE TABLE wp_postmeta (
meta_id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
post_id bigint(20) unsigned NOT NULL DEFAULT \'0\',
meta_key varchar(255) DEFAULT NULL,
meta_value longtext,
PRIMARY KEY (meta_id),
KEY post_id (post_id),
KEY meta_key (meta_key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
问题:
在AUTO_INCREMENT
不提供任何利益;事实上,它减慢了大多数查询的速度(因为必须在二级索引中查找auto\\u inc id,然后在数据中查找所需的实际id)
AUTO_INCREMENT
是额外的混乱-在磁盘和缓存中更好的是PRIMARY KEY(post_id, meta_key)
-- 群集,处理通常JOIN
. BIGINT
有点过头了,但如果不更改其他表,就无法修复VARCHAR(255)
在MySQL 5.6中可能会出现问题utf8mb4
; 请参见下面的解决方法NULL? 解决方案:CREATE TABLE wp_postmeta (
post_id BIGINT UNSIGNED NOT NULL,
meta_key VARCHAR(255) NOT NULL,
meta_value LONGTEXT NOT NULL,
PRIMARY KEY(post_id, meta_key),
INDEX(meta_key)
) ENGINE=InnoDB;
典型用法:JOIN wp_postmeta AS m ON p.id = m.post_id
WHERE m.meta_key = \'...\'
备注:复合材料PRIMARY KEY
直接转到所需的行,不要在二级索引中跑题,也不要在多行中搜索
INDEX(meta_key)
可能有用,也可能无用,这取决于您有哪些其他查询“群集”需要InnoDB继续使用utf8mb4,而不是utf8。但是,您应该在所有WP表和连接参数中保持一致错误“最大密钥长度为767”,在尝试使用字符集utf8mb4时,MySQL 5.6中可能会发生此错误。执行以下操作之一(每个操作都有缺点)以避免错误:
升级至5.7.7,3072字节限制——您的云可能不提供此功能将VARCHAR上的255改为191——您丢失了任何超过191个字符的密钥(不太可能)更改。。转换为utf8——你会丢失表情符号和一些中文使用“前缀”索引——您会失去一些性能优势重新配置(如果使用5.6.3-5.7.6)--需要更改4件事:Barracuda+innodb\\u file\\u per\\u table+innodb\\u large\\u prefix+dynamic或compressed
Potential incompatibilities
meta_id
可能没有在任何地方使用。(但移除它是一种风险)你可以meta_id
并通过更改这些索引获得最大的好处:PRIMARY KEY(post_id, meta_key, meta_id), INDEX(meta_id), INDEX(meta_key, post_id)
. (注:通过meta_id
PK结束时,post\\u id+meta\\u密钥可能是非唯一的。)更改自BIGINT
对于较小的数据类型,还需要更改其他表
utf8mb4
<移动到5.7不应该是不兼容的缩小到
VARCHAR(191)
将要求用户了解限制现在是任意的“191”,而不是以前的任意限制“255”“重新配置”修复是DBA问题,而不是不兼容问题
Comment
我希望我所倡导的一些东西出现在WordPress路线图上。同时,stackoverflow和dba。stackexchange被“为什么WP运行得这么慢”弄得乱七八糟。我相信这里给出的修复方法将大大减少此类投诉类型的问题。
请注意,尽管存在兼容性问题,一些用户仍在更改为utf8mb4。然后他们就有麻烦了。我试图解决MySQL的所有问题。
摘自Rick James mysql博客:source