我有一个大约有3000万行数据的表。
表比较简单:
+--------------------------------------+
| TABLE: recipe_locations |
+--------------------------------------+
| INT recipe_id (primary_key) |
| TEXT url |
| VARCHAR(128) domain (index) |
| VARCHAR(128) tag |
| INT number_ingrediants (index) |
+--------------------------------------+
在标签里面,我试图把这道菜的一种主要成分。我想让这个成分可以搜索。
我现在遇到的问题是,在tag
列上进行搜索需要相当长的时间。事实上,一些LIKE %...%
查询可能需要10秒才能完成,对于我想要推送到这个表的工作负载来说,这是不可接受的。
我想知道它是否会更快有另一个表,其中有所有的主要成分,并首先搜索tags
表,获取id,然后做recipe_locations
表上的WHERE IN
?
我能想象的唯一的事情是,如果搜索查询说,"a
"(——在标签表中可能有成千上万的匹配),那么获得标签的所有id将意味着做WHERE IN
的子查询,或者做LEFT JOIN
。我想知道这是否会妨碍我的LIKE
查询的性能,如前所述。
在包含30000000条记录的VARCHAR字段上使用LIKE搜索可能是性能方面最糟糕的事情。另外,如果每一行都有一个TEXT字段,可能会变得很大,这会使它变得更慢。因此,应该尽可能少地访问那个表recipe_locations。如果我是您,我会创建两个额外的表:
表:ingrediants
ingrediant_id INTEGER AUTOINCREMENT PRIMARY KEY
ingrediant_name VARCHAR(128)
表recipe_ingredients (1:n关系,你可能想要)
recipe_id INTEGER
ingrediant_id INTEGER
(定义合适的索引)
select
r.*
from
recipe_ingrediants ri
left join
recipe r on r.recipe_id=ri.recipe_id
left join
ingrediants i on i.ingrediant_id=ri.ingrediant_id
where
i.ingrediant_name='SALT'
order by
something
这样查询只遍历最大的表一次。使用适当的索引定义,这将比您现在使用的快得多。