有道理的是，如果对1000个条目使用新表更快，那么对数十个或数百个条目也必须更快。

性能不是关于纯粹的行数，而是数据的实际数量及其结构计数。通常，您只使用theme mod API. 您的主题数据位于可预测的位置，可以通过插件轻松导出或更改。theme mod API将所有数据存储在一个选项中，因此杂乱的选项表不会成为您的问题。

但是，如果在主题数据中放置非常深的数组或对象，（反）序列化可能会减慢这些选项的读写速度。在这种情况下，我宁愿处理数据结构，也不愿创建新表。我会使用一个好的缓存插件来减少数据库查询。

If 您可以选择单独的表—为子主题和多站点安装找到一个好的解决方案。想象一个有100个博客的小网络。您是否为每个博客创建新表？还是所有博客共享一个表？

只有当WordPress的表模式无法映射我的数据结构时，我才会使用单独的表。在一个主题中，情况可能并非如此。