发明一个测试练习,以便为您提供帮助:
我们有两个下表:
表1:
id: auto_increment (primary key)
number_complete: varchar(255)
表2:
id: auto_increment (primary key)
name: varchar(255)
number_cut: varchar(255)
我们在每个表中都有此数据:
表1:
表2:
在表1中确实有超过一百万条记录,而在第二个表中有三万四千条记录。
我正在寻找的结果是这样的:
他正在执行并继续执行的是这句话:
select t2.name, count(t1.id)
from table1 as t1, table2 as t2
where t1.number_complete like concat(t2.number_cut,'%')
group by t2.name;
但是这时我已经等待了将近1个小时的时间才能执行该句子,因为您可能会意识到我不是SQL方面的专家。
答案 0 :(得分:0)
在number_complete
上添加索引。
ALTER TABLE table1
ADD INDEX (number_complete);
由于索引默认为B树,因此使匹配前缀合理有效,LIKE
可以利用这一点。
答案 1 :(得分:0)
我会将要比较的字段设置为索引:
try? AVAudioSession.sharedInstance().setCategory(AVAudioSessionCategoryPlayback,
with: .duckOthers)
try? AVAudioSession.sharedInstance().setActive(true)
UIApplication.shared.beginReceivingRemoteControlEvents()
那也应该使搜索运行得更快。
答案 2 :(得分:0)
字符串操作很昂贵。如果它们的规模达到数百万美元,那么它们将变得极其昂贵,您将需要等待数小时。解决方案是避免在过滤器中进行字符串操作。
您将需要问自己一个问题:table1和table2之间的关系如何?它们是多对一还是多对多?如果它们是多对多的,则可以创建一个table3(table1_id,table2_id)表。如果它们是多对一的,则可以为table1表创建table2_id。这些将是数字字段,易于过滤和搜索。
您将需要编写一个脚本来填充新列。是的,您将等待一个小时甚至更长的时间,但只能等待一次。之后搜索会很快。