【问题标题】:How to design MySQL Table Structure for search optimization [duplicate]如何设计MySQL表结构以进行搜索优化[重复]
【发布时间】:2020-05-23 11:59:20
【问题描述】:

大家好,

我需要一些关于如何设计 MySQL 表结构以进行搜索优化的建议。

我正在创建一个房地产网站。在那我有属性表及其所有关联的表。

我可以设计我的表以两种方式保存这些记录。

我有舒适的主桌

id property_name
----------------
1  Property A
2  Property B
3  Property C

方法 1 属性表

id property_name
----------------
1  Property A
2  Property B
3  Property C

Property_Amenities 表

id p_id  amenity_id
------------------------
1  1     1       
2  1     2
3  1     3
4  1     4       
5  2     1
6  2     1

方法 2
属性表

id property_name  amenity_id
----------------------------
1  Property A     1,2,3,4,5
2  Property B     1,4,7,9,12  
3  Property C     3,4,7,8,9,10 

方法 1 查询:我可以加入表格并获取特定属性的所有设施名称。添加优化所需的索引。对于 A 物业,平均有 20 个便利设施。假设我有 100K 个物业记录,然后为了获取特定物业的便利设施,MySQL 查询将在 Property_Amenities 表的 200 万 条记录中进行搜索。

方法 2 查询:我可以使用 FIND_IN_SETIN MySQL 运算符进行搜索。但我正在浏览这个搜索主题,似乎这种方法会占用大量资源,并且对于相同数量的数据(即 100k 属性记录)成本更高。

任何建议都会被采纳。您对这种情况的想法或我应该遵循的任何其他方法。

【问题讨论】:

  • 一些便利设施不是数字吗?人们不会要求范围吗?这里所说的和“dup”查询中的内容都没有涵盖这种情况。如果您需要范围,(1)再次搜索已涵盖的问答;然后考虑 (2) 以更清晰的属性列表开始另一个 Q。

标签: mysql sql search query-optimization


【解决方案1】:

使用第一种方法。时期。第二个是错的,错的,错的。以下是一些原因:

  • 不应使用 SQL 字符串存储多个值。
  • 应使用正确的类型存储整数。
  • 应声明外键关系。
  • SQL 的字符串处理方法很差。
  • SQL 有一种存储列表的好方法;它被称为“表”而不是“字符串”。

【讨论】:

  • 在技术层面上:IN 和文本搜索比比较整数更消耗 CPU。
猜你喜欢
  • 2014-02-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-03-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多