狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

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

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

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

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

這個方案的優點就是實現簡單，缺點也很明顯，需要把所有數據都加載到內存中，容易導致OOM。不推薦!

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

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

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

-- 加密數據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%';

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

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

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

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

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

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

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