問題描述

項(xiàng)目里需要一個(gè)搜索相似圖片的功能，百度了一些dhash的算法，生成了16個(gè)長度的hash值，在mysql里這樣查詢：

SELECT pk, hash, BIT_COUNT( CONV(hash, 16, 10) ^ CONV(’4c8e3366c275650f’, 16, 10) ) as hamming_distance FROM image_hashes HAVING hamming_distance < 4 ORDER BY hamming_distance ASC;

經(jīng)測試，15W條數(shù)據(jù)，搜索需要很長時(shí)間。第二次速度會(huì)快些，有啥辦法可以優(yōu)化？

問題解答

謝邀。

抱歉地說，這個(gè)我也沒有做過，只是之前聽說過漢明距離。15w數(shù)據(jù)，不是很多，但是用了mysql的函數(shù),沒辦法創(chuàng)建索引。。。

可以參考mysql 圖片漢明距離計(jì)算, 近40w的異或計(jì)算, 如何破

Hamming distance on binary strings in SQL

你可以試試mysql的內(nèi)存表 MySQL內(nèi)存表的特性與使用介紹

不好意思，沒有“漢明距離”的相關(guān)經(jīng)驗(yàn)。

如果只是15W數(shù)據(jù)的話，可以把數(shù)據(jù)加載到內(nèi)存里緩存起來，然后在程序里運(yùn)算，畢竟SQL并不擅長做這種事情。

僅從你的SQL來說，的確沒有太大的優(yōu)化空間，能想到的就只有以下幾點(diǎn)：

hash列用char代替varchar

舍棄ORDER BY hamming_distance ASC，改為由程序排序

建議把DDL語句和EXPLAIN結(jié)果也發(fā)上來一并分析，不過最大的性能卡口應(yīng)該是BIT_COUNT(CONV(hash, 16, 10) ^ CONV(’4c8e3366c275650f’, 16, 10)) as hamming_distance，其實(shí)相當(dāng)于全表掃描了。