很可能，属性特性最好存储在单独的表中，每个属性特性一行，而不是作为主表中的列。我认为这是一个属性与其特性之间的多对多关系，因此建议使用另外两个表：

properties          (property_id (pk), date_added, title, description)
features            (feature_id (pk), description)
property_features   (property_id (fk), feature_id (fk))

这种结构比每个特征有一列更灵活，更易于查询。例如：
通过在 features 表（在旧结构中，必须创建新列）
很容易聚合特性，并回答这样的问题：计算每个属性有多少个特性
至于图像，他们也应该有自己的ow表。如果一个图像可能属于多个用户，那么它是一个多对多关系，您可以遵循上述模式。如果每个图像都属于一个用户，则多出一个表就足够了：

properties          (property_id (pk), date_added, title, description)
features            (feature_id (pk), description)
property_features   (property_id (fk), feature_id (fk))
images              (image_id, location, description, property_id (fk))

这不是一个好的做法，因为数据可以存储在不同的表中。最有帮助的是创建一个erd来可视化如何组织表。即使你不了解erds的来龙去脉，你仍然可以用它来组织你的思想。
似乎你已经根据你在问题中提出的要点把表格分开了。我想给你的项目符号添加一个东西，就是把你的特征分解成不同的类别，并为每个类别创建一个表。
例如，游泳池和河边可以放在一张名为“景观特征”或“户外特征”的table上。

一张table：
最有可能搜索的十几个值的列。
设计几个涉及这些列的复合索引，从更常用的搜索列开始。
设计一个 TEXT 列并在其中输入“单词”作为 FULLTEXT 索引。如果这是房屋销售，考虑像“游泳池化粪池凉亭艾希勒”这样的词。这将有助于某些“布尔”类型的查询(如果您喜欢这个想法，让我们讨论一下如何使用索引和/或全文过滤；会变得很棘手。）
将其余的放入json（或 TEXT 列）。不要计划搜索它；相反，在按实际值搜索后，将行放入应用程序代码中进行进一步筛选 INDEXes