在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