缺乏用于元表的复合索引

时间：2012-10-31 作者：Dmitry Isaev

为什么？wp_commentmeta 表没有复合索引(comment_id, meta_key) 默认情况下？我相信这是该表唯一有用的索引，我错了吗？

相反，它有一组奇怪的索引：

mysql> show create table wp3_commentmeta;
...
PRIMARY KEY  (`meta_id`),
KEY `comment_id` (`comment_id`),
KEY `meta_key` (`meta_key`)
...
同样的事情wp_postmeta.

2 个回复
最合适的回答,由SO网友:Andrew Nacin 整理而成

标准WordPress架构“同步”通过dbDelta() 只会添加索引，而不会删除它们。字段也是如此。我们也从未接触过存储模式，因此它是MySQL的默认模式（最新版本中的MySQL现在是InnoDB）。

在脸上，acomment_id_meta_key 索引非常有意义。但是，当您查看WordPress实际如何使用其元数据表时，用例就不那么明显了。

当您请求对象（post、comment或user）的元键时，we fetch all meta keys for that object, 然后缓存它们。这非常重要，因为它只需要comment_id 索引，非acomment_id_meta_key 指数

当然，该查询仍将使用comment_id_meta_key 索引很好，但该索引要大得多，因为它不是一列整数，而是一列varchar(255). 因此，对于元数据的主要用例，它的效率较低。

下一个示例的API有限：用于获取所有对象的所有元键的查询（可能是为了确定哪些对象具有元键）。这也是meta_key 索引，非acomment_id_meta_key 指数

元数据的另一个大API是使用元查询对其进行查询。这些都不是（也不是假装）有效的。他们质疑meta_key （有时是meta_值），希望返回主对象查询的对象ID（通常是内部注释或左连接commentmeta）。再一次comment_id_meta_key 在这里没有帮助。

缩放WordPress是缓存、查询优化和数据库优化的混合体。如果您发现正在运行使用这些索引的查询，那么添加它们真的没有什么错。这与切换到InnoDB没有太大区别（是的，您应该这样做）。我只是不熟悉一个核心准备好的查询，它会丢失现有索引，但从中受益comment_id_meta_key.

SO网友:RolandoMySQLDBA

在这种情况下，您不受限制。只需创建所需的复合索引并删除任何重复索引。例如：

ALTER TABLE wp3_commentmeta ADD INDEX comment_id_meta_key_ndx (comment_id, meta_key);
ALTER TABLE wp3_commentmeta DROP INDEX comment_id;
只需确保您的查询实际使用了新创建的索引。

结束
标签： post-meta   mysql   comment-meta   小码农  

相关推荐

Mysqldump add drop table?

我注意到在Codex中显示了用于备份数据库的--add drop table选项。在我搞砸之前，这是否意味着在最终导入备份时，如果目标数据库中存在这些表，它们将被覆盖？我不想在备份桌子时把它们弄掉！user@linux:~/files/blog> mysqldump --add-drop-table -h mysqlhostserver -u mysqlusername -p databasename (tablename tablename tablename) | bzip2