mysql – 为什么对wp_postmeta的引用如此之慢？

在wordpress中获取属性(使用MySQL)似乎比必要的慢.

(这是一个自我回答的问题,请继续回答.)

解决方法:

wp_postMeta的标准模式提供了不良索引.这会导致性能问题.

通过将模式更改为此,大多数对元数据的引用将更快：

CREATE TABLE wp_postMeta (
    post_id …,
    Meta_key …,
    Meta_value …,
    PRIMARY KEY(post_id, Meta_key),
    INDEX(Meta_key)
) ENGINE=InnoDB;

笔记：

>当前的AUTO_INCREMENT列浪费了空间,并且因为它是PRIMARY KEY而减慢了查询速度,从而避开了(post_id,Meta_key)的“自然”“复合”PK.
>由于“聚类”,InnoDB进一步提升了PK的性能. (我希望你还没有使用MyISAM！)
>如果您使用的是MysqL 5.6(或MariaDB 10.0或10.1),请从VARCHAR(255)更改Meta_key,而不是VARCHAR(191). (如果191还不够,我们可以在一个单独的问题中讨论原因和解决方法.)
> INDEX(Meta_key)是可选的,但如果您想“查找具有特定键的帖子”,则需要它.
>警告：这些变化将加速postMeta的许多用途,但不是全部.我认为它不会减慢任何用例. (如果遇到这些问题,请提供此类查询.这可能是一个缓存问题,而不是真正的降级.)

如果您想要展示您的CREATE TABLE,我可以提供一个ALTER来将其转换为此.

如果您需要为一个帖子提供具有相同键名的多个元键,则使用此解决方案.它几乎与上述建议一样好.

    Meta_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,  -- keep after all
    ...
    PRIMARY KEY(post_id, Meta_key, Meta_id),  -- to allow dup Meta_key for a post

Source doc

可能的改变

注意事项：

>我无法测试这个.
>这不解决767错误
>这保留了Meta_id,因为一些WP用户指出它被其他表引用.
>它假设您可能有多个行(post_id,Meta_key)组合. (这看起来很糟糕的架构设计？)
>所有这一切都加快了涉及postMeta的典型SELECT.
>这也可能适用于woocommerce.
>如果您使用此功能,请转储您的数据库并准备好在发生问题时重新加载它.

sql：

ALTER TABLE wp_postMeta
    DROP PRIMARY KEY,
    DROP INDEX post_id,
    ADD PRIMARY KEY(post_id, Meta_key, Meta_id),  -- to allow dup Meta_key for a post
    ADD INDEX(Meta_id);    -- to keep AUTO_INCREMENT happy