performance - DBMS_CRYPTO 性能问题

Question

我正在使用 DBMS_CRYPTO 来保护信息以防发生数据库泄露。 key 不存储在 dbms 中，而是由应用程序在每次访问时提供。

select decrypt(name), seq order by seq 查询花费的时间(几乎恰好)是其中任何一个的 15 倍

select decrypt(name), seq

或

select name, seq order by seq

这让我相信解密函数破坏了主键 seq 上的索引。为什么会坏？

我已经尝试将关键字 DETERMINISTIC 添加到函数的输出类型，但它只将时间缩短到比更快的查询长约 10 倍。我不明白为什么它需要比 select decrypt(name), seq 更长的时间。 编辑:DETERMINISTIC 关键字也加速了简单的解密查询，正如预期的那样。

是我的预期有误，还是另有原因？考虑到我已获得的安全限制，我可以接受 300 毫秒的延迟，但 3000 毫秒很明显，我想让它更快。

我正在使用一个名为 SmartSQL 的数据库工具，它会显示“耗时”(我假设在发送查询和接收结果的最后一位之间有时间)。

seq 上有一个索引，主键。我认为在加密值上放置索引无济于事。

执行计划:

选择解密(名称)，seq

------------------------------------------------------------------------------------
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                |  8810 |  1453K|    98   (3)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|    98   (3)| 00:00:02 |
------------------------------------------------------------------------------------

select name, seq order by seq desc

---------------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |  8810 |  1453K|       |   428   (1)| 00:00:06 |
|   1 |  SORT ORDER BY     |                |  8810 |  1453K|  3448K|   428   (1)| 00:00:06 |
|   2 |   TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|       |    98   (3)| 00:00:02 |
---------------------------------------------------------------------------------------------

select decrypt(name),seq order by seq desc

---------------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |  8810 |  1453K|       |   428   (1)| 00:00:06 |
|   1 |  SORT ORDER BY     |                |  8810 |  1453K|  3448K|   428   (1)| 00:00:06 |
|   2 |   TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|       |    98   (3)| 00:00:02 |
---------------------------------------------------------------------------------------------

我的完整查询如下所示:

select 
    seq, gender, wdate, address, 
    my_crypto_pkg.decrypt(tel, 'my_secret_key'), 
    my_crypto_pkg.decrypt(name, 'my_secret_key') 
from cstn_memb_info
--  where my_crypto_pkg.decrypt(name, 'my_secret_key') like ?
order by
    seq desc

Answer 1

只要注释掉涉及解密数据的谓词，三个查询返回第一行的时间就会有很大的不同。但考虑到您要达到的最终结果，这似乎没有意义。

如果你消除了decrypt调用，那么你只是在扫描表，你不必调用一个单独的函数来解密数据(这比仅仅阅读它)。如果去掉 ORDER BY，Oracle 只需在返回数据前解密前 N 行，甚至不必完成表扫描。如果您解密数据并对结果排序，那么您必须先解密所有数据，然后才能进行排序并开始返回结果。对于同时执行 decrypt 和 ORDER BY 的查询，获取最后一行的时间也是最长的，但差异会小得多。在解密值上添加谓词后，所有查询的速度至少应与三个查询中最慢的查询一样慢，这更符合您最终想要运行的查询。

实际上，由于您打算对解密值进行谓词，并且由于加密 key 是在运行时传入的，因此在您订购之前，您将必须对表进行全面扫描，解密每一行结果。随着数据量的增加，这将非常缓慢。当您谈论“分页 View ”时，它通常也与您所描述的内容不兼容。由于每次运行此查询时都必须解密每一行，因此您不想编写一个返回前 10 行的查询，然后发出另一个查询来获取第 11-20 行，依此类推。每次获取一页数据时，您都需要重新解密表中的每一行。

如果您使用的是 11g，则使用结果缓存功能可能允许您发出单独的查询，以相当高效的方式获取单独的数据页面。但这在 10g 中不可用。