數(shù)據(jù)庫加密可以保障數(shù)據(jù)的安全，但是也會(huì)帶來很多的問題，其中有一個(gè)比較關(guān)鍵的就是數(shù)據(jù)的模糊查詢的問題。

當(dāng)我們通過加密后把密文存到數(shù)據(jù)庫中的時(shí)候，再通過明文進(jìn)行模糊查詢是不生效的。

比如Hollis加密后的內(nèi)容是363164846D8200899E314897E64A7420，那么當(dāng)我想用Ho來做模糊查詢時(shí)候，那么他的密文是71AAFD38484F3160708C6A6D2D5F736B，這兩個(gè)密文可以說是沒有任何關(guān)系的，所以，是無法直接做模糊查詢的。那么如何解決這個(gè)問題呢？

一種比較常見的方法，就是把要查詢的表中的所有符合條件的數(shù)據(jù)，都加載到應(yīng)用內(nèi)存中，在內(nèi)存中逐個(gè)解密，然后再做模糊匹配。

這個(gè)方案的優(yōu)點(diǎn)就是實(shí)現(xiàn)簡單，缺點(diǎn)也很明顯，需要把所有數(shù)據(jù)都加載到內(nèi)存中，容易導(dǎo)致OOM。不推薦!

還有人提出過說單獨(dú)建一張表，其中保存明文和目標(biāo)表之間的映射，需要模糊查詢的時(shí)候先去明文映射表中查到主鍵，然后再去目標(biāo)表查詢數(shù)據(jù)。

但是這個(gè)方案基本上是屬于自欺欺人，因?yàn)橐坏?shù)據(jù)被拖庫，還是會(huì)丟。不推薦

加密的時(shí)候如果用了函數(shù)的話，解密的時(shí)候我們也可以借助函數(shù)來做解密，同時(shí)做模糊查詢，比如加密時(shí)使用了AES_ENCRYPT算法：

-- 加密數(shù)據(jù)INSERT INTO user_data (username, credit_card) VALUES ('Hollis', AES_ENCRYPT('1234-5678-9012-3456', 'hollis_secret_key'));

那么在做模糊查詢的時(shí)候就可以這樣做：

SELECT * FROM user_data WHERE AES_DECRYPT(credit_card, 'hollis_secret_key') like 'Hol%';

這樣也就能實(shí)現(xiàn)一個(gè)模糊查詢的效果了，但是這個(gè)方案有個(gè)缺點(diǎn)，就是無法用到索引，不是因?yàn)橛胠ike，而是因?yàn)槲覀冊谧侄紊嫌昧撕瘮?shù)，索引就會(huì)失效。

這個(gè)方案適合于表中數(shù)據(jù)量不大，或者查詢條件中還有其他查詢字段可以走索引的情況。

還有一個(gè)比較簡單的做法，也是很多大廠在用的方案。

那就是對明文進(jìn)行分詞，然后分別加密后存儲(chǔ)到數(shù)據(jù)庫中，比如Hollis這個(gè)需要加密的字符串，我們就可以把他拆成Ho 、Holl、llis等這幾個(gè)字符串，然后分別對他們進(jìn)行加密，并保存到數(shù)據(jù)庫中。

這樣當(dāng)我們使用Ho 、Holl、llis 進(jìn)行查詢的時(shí)候，就可以對明文加密后去數(shù)據(jù)庫中匹配了。

這個(gè)方案的缺點(diǎn)也比較明顯，第一個(gè)就是需要冗余很多字段，第二個(gè)就是不夠靈活，如果我按照Holli來查詢的話就不支持了。

這個(gè)方案本質(zhì)就是一種比較典型的用空間換時(shí)間的做法，理論上只要你愿意，可以把所有的可能的查詢都做冗余。