您列出的每种方法各有利弊：
创建一个新表？ （我不会利用常规的帖子功能和缓存的可能性）
优点： 性能
缺点： 灵活性、功能
灵活性通过为每个字段创建一个包含列的表格，您将失去灵活性。与仅使用元数据相比，添加新字段更难。对于具有大量行的表，添加或删除列是一项昂贵的操作，因此如果您需要经常修改架构，这可能不是可行的方法。
功能 使用这种方法，您将无法利用内置方法与元数据进行交互（例如 get_post_meta）。您还将更难根据您的元数据查询帖子。您仍然可以缓存数据，但您必须手动进行。据我所知，您将无法通过这种方法继续使用 ACF。
性能从积极的方面来说，将每个字段作为单独表中的一列可以让您更好地为数据编制索引。这是否对您有利取决于您需要运行的查询。
使用后元/选项表？ （在这种情况下表现如何？）并继续这个解决方案？
缺点：灵活性、功能
优点：性能
显然，如果您坚持使用默认方法处理元数据，则可以继续使用所有内置功能与该数据进行交互。您还可以在不更改表结构的情况下添加或删除元字段。
关于性能，您将无法像使用单独的表一样创建索引来提高查询的性能。如果您的查询不能利用 postmeta 表上的索引，这只是一个严重的问题。
请注意，wp_postmeta 在post_id 和meta_key 上有索引，但在meta_value 上没有。这意味着，如果您正在根据元值查找记录并且您有很多行共享相同的元键，则数据库必须查看具有特定元键的所有行以找到具有元键的行您正在寻找的价值。
因此，如果我在这个 wp_postmeta 表中保存 20 个字段 X 2 行 X 200.000 个条目，它将使 8.000.000 行通过
根据您的查询，这可能不是一个严重的问题。正如我之前提到的，postmeta 表在post_id 上有一个索引，所以如果您只查找post_id 的元条目，这不是一个严重的问题。
只要您的查询可以使用索引，800 万行对 MySQL 来说不是问题。
如果您只是基于post_id 索引进行查询，则不是问题。就内存而言，无论您使用哪种方法，您都将需要大致相同数量的内存。
向 post 表添加新字段？ （会不会兼容WP升级？）
这种方法与创建单独的表几乎相同：
- 您将有更大的能力通过索引来提高性能
你的帖子表
- 您将无法使用内置功能
用于与元数据交互
- 添加和删除字段将更加困难
我不认为这会导致升级 WordPress 出现问题。即使升级包括对wp_posts 表的修改，添加额外的列不应该导致问题。在生产升级之前，我肯定会在暂存环境中测试升级。
总的来说，我认为最好避免修改核心 WordPress 功能，包括修改默认表结构。与使用单独的表相比，这种方法不会有任何显着的性能优势，因此我认为最好采用另一种方法。