我是使用Wordpress的新手，并且有问题要找出可供选择的解决方案。
我必须在Wordpress的posts表中存储超过200,000个条目（books，cds，...）。每个条目都有大约20个不同的字段来填充。
因此，我认为我必须在posts表中添加新字段，以便存储数据。
我使用ACF自定义字段插件来执行此操作，但我可以看到自定义字段不与post表存储在同一个表中。它存储在wp_options表中的类别和postmeta表中的帖子以及填充它的每个字段将在这些表中创建2行。
因此，如果我在这个wp_postmeta表中保存20个字段X 2行X 200.000个条目，它将会生成8.000.000行（对于演出来说可能没有那么好）。
使用Wordpress实现此任务的最佳方法是什么？
创建一个新表？ （我不会受益于常规帖子功能和缓存可能性）
在帖子表中添加新字段？ （它是否与WP的升级兼容？）
使用postmeta / option表？ （在这种情况下表现怎么样？）并继续这个解决方案？
非常感谢提前帮助
答案 0 :(得分：1)
您列出的每种方法都有利弊：
创建一个新表？ （我不会受益于常规帖子功能和缓存可能性）
专业：效果 Con：灵活性，功能
灵活性通过为每个字段创建包含列的表格，您将失去灵活性。与仅使用元数据相比，添加新字段更难。对于具有大量行的表，添加或删除列是一项昂贵的操作，因此如果您需要经常修改架构，这可能不是最佳选择。
功能使用此方法，您无法利用内置方法与元数据进行交互（ex get_post_meta）。您还将很难根据元数据查询帖子。您仍然可以缓存数据，但必须手动执行。据我所知，你不会继续使用这种方法使用ACF。
效果从积极的方面来说，将每个字段作为一个列放在一个单独的表中可以让您更好地索引数据。这是否对您有利，取决于您需要运行的查询。
使用postmeta / option表？ （在这种情况下表现怎么样？）并继续这个解决方案？
Con：灵活性，功能
专业版：
显然，如果您坚持使用默认方法处理元数据，您可以继续使用所有内置功能与该数据进行交互。您还可以在不改变表格结构的情况下添加或删除元字段。
关于性能，您无法像创建单独的表一样创建索引来提高查询性能。如果您的查询无法利用postmeta表上的索引，这只是一个严重的问题。
请注意，wp_postmeta在post_id和meta_key上有索引，但meta_value没有。{1}}。这意味着如果您正在查找基于元值的记录并且您有许多共享相同元键的行，则数据库必须查看具有特定元键的所有行以查找具有元元素的行你正在寻找的价值。
因此，如果我在此wp_postmeta表中保存20个字段X 2行X 200.000个条目，它将生成8.000.000行
根据您的查询，这可能不是一个严重的问题。正如我之前提到的，postmeta表在post_id上有一个索引，所以如果你只是按post_id查找元条目，这不是一个严重的问题。
只要您的查询可以使用索引，就不会有800万行成为MySQL的问题。
如果您只是根据post_id索引进行查询，则不是问题。就内存而言，无论使用哪种方法，您都需要大致相同的内存量。
在帖子表中添加新字段？ （它会与WP的升级兼容吗？）
这种方法与创建单独的表几乎相同：
我不会认为这会导致升级WordPress的问题。即使升级包含对wp_posts表的修改，但是其他列也不应该导致问题。在升级生产之前，我肯定会在暂存环境中测试升级。
总的来说，我认为最好避免修改核心WordPress功能，包括修改默认表结构。与单独的表相比，这种方法不会有任何显着的性能优势，所以我认为最好采用另一种方式。