这是通过默默无闻的安全。虽然它可能不会在所有情况下都伤害到您，但它本身并不能提供可行的安全性。不要依赖此作为您的保护。

一个简短的比喻

假设你把钱放在MONEY家里贴有标签的罐子里。由于您知道有时离开家时会忘记锁门，因此您重新标记罐子COOKIES以防止小偷找到它。你现在会觉得更有安全感吗？当然，一个非常懒惰、愚蠢的小偷可能会错过它，但你不必成为一个大盗来偷你的钱。记得锁门不是更好吗？

回到计算机世界

假设您有一个带有 SQL 注入漏洞的旧 phpBB 安装。默认情况下，表的前缀为phpbb_. 您将其更改为obscure_. 这会对你有帮助吗？

简单的扫描可能无法找到硬编码phpbb_users的表名（就像所有密码一样），因此会失败。但即使是脚本小子也可以运行一个脚本来运行 aSHOW TABLES并找到你的obscure_users. 事实上，有些工具会 通过 SQL 注入漏洞自动转储所有表的内容。

结论

那么这里的教训是什么？虽然更改表前缀（重新标记 jar）可能会保护您免受最基本的愚蠢自动攻击（愚蠢、懒惰的小偷），但您仍然容易受到脚本小子（小偷在您的 jar 中搜索）执行的简单攻击。当您遇到像 SQL 注入这样的真正漏洞时，解决方案是修复该漏洞（锁上门），而不是添加一层薄薄的晦涩面纱。

也就是说，如果没有有害的副作用，一个可以减缓某些攻击的简单预防措施可能仍然值得作为“纵深防御”。只是因为您实施它而感到不安全。

（作为附录，我应该说在同一个数据库中运行多个安装可能会带来安全隐患，具体取决于具体情况。）

不，是蛇油。

当有人在应用程序中发现 SQL 注入漏洞时，不知道表名只是一个很小的障碍。许多股票注入有效载荷（如良好的旧通用密码' OR '1' = '1）甚至不需要知道任何表名。如果攻击者发现了一种从任意表中转储数据的方法，他们只需转储系统表INFORMATION_SCHEMA.TABLES（或等效的，取决于使用的数据库系统）并获得所有其他表的名称。

不过，它不一定是有毒的蛇油。能够让多个安装共享同一个数据库可能是一个合法的功能（比如在一个只允许你在他们的 MySQL 集群上使用单个数据库的低预算网络主机上）并且只要你只有一个随机前缀和表名仍然是人类可读的，它不会对维护产生太大影响。但这并没有增加太多的安全性。

在广泛采用的基于 DBMS 的系统（如 WordPress）中，通常将实例配置为使用表名my_fav_prefix_posts代替wp_posts.

为什么？据称它会减慢脚本小子的速度。

几年前，对 WordPress 实例进行了大量攻击。简单的网络犯罪分子（脚本小子）使用简单的攻击软件（脚本）来接触大量寻找漏洞的服务器。当脚本没有找到该wp_posts表时，它们会转移到攻击列表中的下一个服务器。当然，几周后脚本变得更加复杂，WordPress 实例无法再将它们的表格隐藏在显而易见的地方。

我想这就是替代数据库前缀提供额外安全层的神话的起源。他们没有。

我会说这不会增加安全性。但是，如果您不能（或不想）依赖模式在不同的应用程序之间分隔表，则使用不同的前缀允许不同的应用程序共享同一个数据库，而没有冲突的风险。

但是没有增加真正的安全性。