MySQL不支持按创建者动态隔离表权限，因其权限系统静态且GRANT不接受函数变量；可行方案为应用层拦截、视图封装或中间件路由，并需严格控制SHOW DATABASES权限。
MySQL 本身不支持“用户只能访问自己创建的表”这种动态权限模型——它没有内置的 CURRENT_USER() 表级上下文过滤，也不能在 GRANT 里写条件表达式。所谓“自己创建的表”，必须靠外部逻辑控制，不能只靠原生权限配置。
GRANT 无法实现“按创建者隔离表”的根本原因
MySQL 的权限系统是静态的：每条 GRANT 记录绑定到明确的 database.table_name，不支持运行时解析用户身份后匹配表名（比如 user1_orders、user2_logs）。即使你用 CURRENT_USER() 写在视图或存储过程中，权限检查仍发生在语句解析阶段，而不会回溯“这张表是谁建的”。
-
GRANT SELECT ON mydb.user1_orders TO 'user1'@'%'可行，但需提前知道表名 -
GRANT SELECT ON mydb.`{CURRENT_USER()}_orders` TO 'user1'@'%'语法错误，MySQL 不允许变量或函数出现在对象名位置 - 表创建者信息只存于
information_schema.TABLES.CREATE_TIME和TABLE_COMMENT（非标准字段），不可用于权限判定
真正可行的三种落地路径
绕过 MySQL 原生权限限制，把“谁建的表、能看哪些表”这件事移出数据库层：
-
应用层拦截：所有建表、查表请求都走统一 DAO，建表时自动加前缀（如
u12345_orders），查询时强制拼接当前用户 ID 前缀，拒绝未带前缀的裸表名访问 -
视图 + 固定命名约定：为每个用户建同名视图（如
my_orders），定义为SELECT * FROM u12345_orders；只授SELECT ON mydb.my_orders权限，用户永远只操作视图，不接触物理表名 -
中间件路由（如 ProxySQL / MaxScale）：在 SQL 解析阶段重写语句，把
SELECT * FROM orders改成SELECT * FROM u12345_orders，再转发；需维护用户→表前缀映射关系
为什么别碰 FLUSH PRIVILEGES 和直接改 mysql.tables_priv
很多教程教人先 REVOKE 再 GRANT 后补一句 FLUSH PRIVILEGES，这在绝大多数场景下多余且危险：
-
GRANT和REVOKE成功执行后，权限已实时写入mysql.tables_priv表，无需手动刷新 - 只有当你绕过
GRANT、直接INSERT INTO mysql.tables_priv修改系统表时，才需要FLUSH PRIVILEGES - 误用
FLUSH PRIVILEGES可能触发权限缓存重载异常，尤其在高并发连接下导致短暂授权失效
最易被忽略的一点：哪怕你用视图或中间件做了完美隔离，只要用户有 SHOW DATABASES 权限，他依然能看到所有库名——真正的数据隔离必须配合 GRANT SHOW DATABASES ON *.* TO ... 的显式授予，否则 SHOW DATABASES 返回空列表才是安全基线。
