在 MySql 中管理跨数据库读取、视图或权限答案

【问题标题】：Managing cross database reading, views or permissions in MySql在 MySql 中管理跨数据库读取、视图或权限
【发布时间】：2011-01-24 07:21:33
【问题描述】：

我将在同一个 mySql 服务器上有多个不同项目使用的表。大部分数据都是敏感的，需要在权限墙后面。然而，许多敏感数据表依赖于用户和部门信息的不敏感数据表。所以我看到三个选项摆在我面前，我不确定该选哪个。

具有表级权限的多合一数据库

除了我不控制数据库服务器上的权限之外，所有解决方案中最简单的一种，传统上服务器团队只做数据库级别的权限，让他们允许这是一场政治斗争，我可能没有影响力去赢得，并保持跟踪所有权限会很痛苦。

在多个数据库中，具有数据库级权限

我可以将表拆分为数据库区域，因此部门范围的信息（如员工数据）可以在它自己的数据库中，并且编辑员工数据的工具可以对部门数据库进行更新和插入访问。其他工具可能想要访问部分员工列表，公共员工目录对员工表具有 SELECT 访问权限，但员工表的部分需要保持私有，例如个人联系信息、复制代码或计费索引。我需要将员工表拆分为公共或私有表，但我会再次被表级权限困住。所以我需要将部门数据库拆分为部门共享数据库和部门私有数据库。

跨数据库视图 我将在数据库中创建视图，该视图从帐户无权访问的其他数据库中提取数据。所以我可以将所有员工信息放在部门数据库中，然后在 Web 数据库中创建一个视图，该视图只提取应该公开可用的列（名称、部门、扩展名）。实际上，这将允许我拥有列级别的 SELECT 权限，而不必纠结于权限。我担心的是速度。从中提取数据的原始表将被完全索引，但在查询视图时是否对列进行索引，文档似乎是矛盾的。

有没有其他人使用过这三个选项中的任何一个？你有更好的我没想到的吗？除了我指出的任何选项之外，您还可以看到哪些陷阱？

【问题讨论】：

标签： mysql performance permissions views

【解决方案1】：

视图和存储过程是您最好的选择。视图可用于提供通用访问，但如果某些查询表现不佳，请重写它们以使用绕过视图的存储过程来提高性能。

【讨论】：

存储过程会不会越过权限障碍，我可以用高帐户设置过程然后用低帐户查看数据？
是的 - 存储过程的主要特性之一是它们允许更好地管理权限。定义存储过程的帐户最好作为本地帐户 - 例如'sp_owner'@'localhost' - 以降低远程用户在破解密码时获得该帐户的强大访问权限的风险。最灵活的安排是，如果您的存储过程被定义为“create definer=current_user procedure ...”，那么可以将它们定义在哪个帐户下的决定推迟到加载时间。