关于数据库多字段比较效率

2014-08-01 11:29:32 356 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

在Mybatis xml使用mysql数据库进行多字段模糊查询（Like）在mysql中使用Like进行一些简单轻量级的查询，并不需要考虑太多效率问题。一、Like单字段查询比较简单。没有特殊要求的话，直接使用%关键字%就进行左右匹配查询 ..... <mapper..> ... <select...> SELECT c.* FROM contacts c WHERE c.delete_time IS NULL <if test="keyWord != null and.. 阅读详情

现在要往一张表(记录总数超过1亿) 里面插入数据，插入数据前要比较是不是一样，要比较7个字段，
tba(
Id int,
acol varchar(20),
bcol varchar(20),
ccol varchar(20),
dcol varchar(20),
ecol varchar(20),
fcol varchar(20),
gcol int
)
如果用select where 1 个1个去比效率比较低，现在想在里面增加一个column保存hash码，这个hash吗由程序生成，插入直接比较hash吗，不知道这样怎么样？大家一般是怎么设计的？

...全文

DB Browser for SQLite vs 命令行：5个常见数据库管理任务效率对比本文对比了DB Browser for SQLite与命令行在5个常见数据库管理任务中的效率差异，包括创建表、批量CSV导入、复杂查询、结构浏览和数据可视化。通过实测数据，帮助开发者根据具体场景选择最适合的工具，提升SQLite数据库管理效率。阅读详情

jldzy

MS-SQL Server 34,876 成员 254,635 内容

+ 关注 + 加入社区

切换为时间正序

Tiger_Zhao 2014-08-04

打赏
举报

如果 7 个字段一起 hash 就需要在一亿个 hash 值中判重复。
依据现有数据，把字段分为3组，每组大概1000个 hash。
这样只要在 3000 个值中判断 3 次。
按你7楼 0.007 单次重复率就成为 0.007 ^ 3 = 0.000000343 组合重复率。

当然如果每个字段分布都很散，直接7组 hash，重复率更低。
记得每组 hash 值要永久保存。

jldzy 2014-08-04

打赏
举报

刚测试了下，checksum 出现重复的概率是非常高的。在9323866 中有 66644 是重复的记录。

jldzy 2014-08-04

打赏
举报

还有个问题，对于一个判断名字是是不存在的话 name nvarchar(300)，是用checksum 还是直接建立以个唯一索引来判断？哪个效率高点？ checksum 产生的是数字，按道理是比直接去比字符串是高效的。

jldzy 2014-08-04

打赏
举报

我这里查询出来是重复的， Collation Latin1_General_BIN

Tiger_Zhao 2014-08-04

打赏
举报

可能和楼主测试的文本有关吧。
CHECKSUM() 按照设置可能是不区分大小写的，比较容易重；可以考虑用 BINARY_CHECKSUM()。

专注or全面 2014-08-04

打赏
举报

你发给我的信息生成的checksum值完全不同啊

专注or全面 2014-08-04

打赏
举报

引用 10 楼 jldzy 的回复:

我是用2个字段测试的，checksum(cola,colb)

我想假如文本cola,colb本身就是不同的，计算出来的checksum(cola,colb)相同的概率的可能性没有那么大吧

专注or全面 2014-08-04

打赏
举报

引用 10 楼 jldzy 的回复:

我是用2个字段测试的，checksum(cola,colb)

首先要确保你的文本值时不同的，相同的文本值生成的checksum肯定相同了（貌似废话）但是不同的文本生成的checksum不太好测试我还是拿之前的脚本，计算guid的checksum值，就相当于guid是你的文本，那么就间接地测试，不同的文本生成的checksum值的重复的概率关于GUID，楼主你不用怀疑其重复的概率吧那么我就用guid来测试“不同的文本生成checksum值重复的概率” 下面是循环1000万次，有时候可以测到，有时候测不到不同的GUID生成了相同的checksum值那么就可以证明，不用的文本生成相同的checksu值的概率是小于1000W分之一的


DECLARE 
@guid1 UNIQUEIDENTIFIER,
@guid2 UNIQUEIDENTIFIER,
@i int 
set @i=0
while(@i<10000000)
begin
	set @guid1=NEWID()
	set @guid2=NEWID()
	if(CHECKSUM(@guid1)=checksum(@guid2))
	begin
		print @guid1
		print @guid2
	end
	set @i=@i+1
end

其实测了很多次，测出来两个 DECLARE @guid1 UNIQUEIDENTIFIER, @guid2 UNIQUEIDENTIFIER set @guid1='9A1231D9-06FD-4C36-8157-8D3CEF5E8014' set @guid2='43F32EF0-51E8-4FE0-9A69-7CE1B6CB7524' select CHECKSUM(@guid1),CHECKSUM(@guid2)

jldzy 2014-08-04

打赏
举报

我是用2个字段测试的，checksum(cola,colb)

专注or全面 2014-08-04

打赏
举报

引用 6 楼 jldzy 的回复:

还有个问题，对于一个判断名字是是不存在的话 name nvarchar(300)，是用checksum 还是直接建立以个唯一索引来判断？哪个效率高点？ checksum 产生的是数字，按道理是比直接去比字符串是高效的。

按道理在chechsum列上建立唯一索引效率肯定比name nvarchar(300)纯文本高 “刚测试了下，checksum 出现重复的概率是非常高的。在9323866 中有 66644 是重复的记录” 不知道你是怎么测试的？不同的字符串信息会生成相同的checksum值？

jldzy 2014-08-01

打赏
举报

这个和在程序端计算出hash ，插入数据库有什么区别，开始考虑如果在数据库这操作算hash,怕影响性能。

专注or全面 2014-08-01

打赏
举报

你可以增加一个计算列， ALTER TABLE tableName ADD hashsum AS CHECKSUM(列名); 然后插入数据的时候去比较这个hash值也就是将所有列合并起来计算一个hash值，插入数据的时候去比较这个自动生成的hash值其实也有人说不同的数据生成的hash值会重复，也有这种情况，我本机测试guid生成的hash值相同的情况，大概是一千万分之一更何况你这个是多个字段生成的hash值，重复的概率可以忽略了如果不放心，查询到hash值相同的情况下，再次对值进行比较，可以避免了重复的情况了你查一下hash索引

jldzy 2014-08-01

打赏
举报

也可以把所有字段拼接字符串保存到一个字段，但是有可能字段太长了，所以改用hash

發糞塗牆 2014-08-01

打赏
举报

区别在于你几乎不用额外编程，也不用怎么管理

专注or全面 2014-08-01

打赏
举报

引用 3 楼 jldzy 的回复:

这个和在程序端计算出hash ，插入数据库有什么区别，开始考虑如果在数据库这操作算hash,怕影响性能。

应该木啥区别吧，只是实现方式的问题

关于数据库多字段比较效率

相关推荐