php - 智能(？)数据库缓存

Question

我见过几个数据库缓存引擎，它们都非常愚蠢(即:将此查询缓存 X 分钟)并要求您在 之后手动删除整个缓存存储库>INSERT/UPDATE/DELETE 查询已执行。

大约 2 或 3 年前，我为我正在从事的项目开发了一个替代数据库缓存系统，其想法基本上是使用正则表达式来查找特定 SQL 查询中涉及的表:

$query_patterns = array
(
    'INSERT' => '/INTO\s+(\w+)\s+/i',
    'SELECT' => '/FROM\s+((?:[\w]|,\s*)+)(?:\s+(?:[LEFT|RIGHT|OUTER|INNER|NATURAL|CROSS]\s*)*JOIN\s+((?:[\w]|,\s*)+)\s*)*/i',
    'UPDATE' => '/UPDATE\s+(\w+)\s+SET/i',
    'DELETE' => '/FROM\s+((?:[\w]|,\s*)+)/i',
    'REPLACE' => '/INTO\s+(\w+)\s+/i',
    'TRUNCATE' => '/TRUNCATE\s+(\w+)/i',
    'LOAD' => '/INTO\s+TABLE\s+(\w+)/i',
);

我知道这些正则表达式可能有一些缺陷(那时我的正则表达式技能还很菜鸟)并且显然不匹配嵌套查询，但由于我从不使用它们，所以这对我来说不是问题。

无论如何，在找到涉及的表后，我会按字母顺序对它们进行排序，并使用以下命名约定在缓存存储库中创建一个新文件夹:

+table_a+table_b+table_c+table_...+

在 SELECT 查询的情况下，我会从数据库中获取结果，serialize() 它们并将它们存储在适当的缓存文件夹中，例如以下查询的结果:

SELECT `table_a`.`title`, `table_b`.`description` FROM `table_a`, `table_b` WHERE `table_a`.`id` <= 10 ORDER BY `table_a`.`id` ASC;

将存储在:

/cache/+table_a+table_b+/079138e64d88039ab9cb2eab3b6bdb7b.md5

MD5 是查询本身。在随后的 SELECT 查询中，获取结果将是微不足道的。

如果是任何其他类型的写入查询(INSERT、REPLACE、UPDATE、DELETE 等on) 我将 glob() 所有名称中包含 +matched_table(s)+ 的文件夹都删除所有文件内容。这样就不必删除整个缓存，只需删除受影响表和相关表使用的缓存即可。

该系统运行良好，性能差异显而易见 - 尽管该项目的读取查询多于写入查询。从那时起，我开始使用事务，FK CASCADE UPDATES/DELETES 并且从来没有时间完善系统以使其适用于这些功能。

我用过 MySQL Query Cache过去，但我必须说性能甚至无法比较。

我在想:难道只有我一个人看到了这个系统的美吗？有没有我可能不知道的瓶颈？为什么像 CodeIgniter 这样的流行框架和 Kohana (我不知道 Zend Framework )有这么基本的数据库缓存系统？

更重要的是，您认为这是一项值得追求的功能吗？如果是，有什么我可以做/用来让它更快(我主要关心的是查询结果的磁盘 I/O 和(反)序列化)？

感谢所有意见，谢谢。

Answer 1

我可以看到这个解决方案的优点，但是，我相信它只适用于一组非常特定的应用程序。不适用的场景包括:

• 利用级联删除/更新或任何类型触发器的数据库。例如，您对表 A 的 DELETE 操作可能会导致对表 B 的 DELETE 操作。正则表达式永远不会捕捉到这一点。

• 从不通过缓存失效方案的点访问数据库，例如crontab 脚本等。如果您决定实现跨机器复制(引入只读从属)，它也可能会扰乱缓存(因为它不会经历缓存失效等)

即使这些场景对您的情况不现实，它仍然回答了为什么框架不实现这种缓存的问题。

关于这是否值得追求，这完全取决于您的应用。也许您愿意提供更多信息？