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

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

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

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

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

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

但是這個方案基本上是屬于自欺欺人，因為一旦數(shù)據(jù)被拖庫，還是會丟。不推薦

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

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

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

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

這樣也就能實現(xiàn)一個模糊查詢的效果了，但是這個方案有個缺點，就是無法用到索引，不是因為用like，而是因為我們在字段上用了函數(shù)，索引就會失效。

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

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

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

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

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

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