不能。MySQL视图中用AS起列别名仅改变结果字段名，不隐藏原表名；SHOW CREATE VIEW会暴露完整定义；真正隐藏需靠权限控制，如回收基表SELECT权限、仅授予视图权限。
视图里用 AS 别名真能隐藏原表名吗
不能。MySQL 视图定义中用 AS 给列起别名（比如 SELECT user_id AS id FROM users），只影响查询结果的字段名，不遮蔽底层表结构。执行 SHOW CREATE VIEW view_name 会直接暴露原始表名、字段、WHERE 条件甚至 JOIN 逻辑。
常见错误现象：以为给 users.id 起了别名 id，外部就查不到 users 表存在了——其实只要用户有 SHOW VIEW 权限，就能看到完整定义。
- 真正隐藏表名，得靠权限控制：回收普通用户对基表的
SELECT权限，只授予对视图的SELECT - 视图定义本身不可加密或混淆，MySQL 不提供“编译后隐藏源”的机制
- 如果应用层拼 SQL 时硬编码了视图名，而视图名又和业务含义强相关（如
v_user_profile），反而可能泄露更多线索
逻辑字段名该在视图里怎么定义才安全又实用
逻辑字段名的核心作用是解耦接口与存储，不是防窥探。重点在于命名是否稳定、是否反映语义、是否避免歧义。
使用场景：前端 API 返回 full_name，但数据库存的是 first_name 和 last_name；或者需要统一返回 status，但底层是 order_status_code + 状态映射表。
- 用
CASE WHEN或COALESCE做状态映射时，确保分支覆盖全，否则查出来是NULL容易引发前端空指针 - 字符串拼接（如
CONCAT(first_name, ' ', last_name)）记得加TRIM和空值处理，CONCAT(NULL, 'x')结果是NULL - 别用函数包裹主键字段（如
MD5(id)）当逻辑 ID——这会让索引失效，且无法反查，除非你明确不需要关联或分页
为什么 CREATE VIEW 加 ALGORITHM = TEMPTABLE 反而更不安全
这个参数控制视图执行策略：UNDEFINED（默认）由优化器选，MERGE 会把视图逻辑合并进外层查询，TEMPTABLE 强制物化中间结果。但它和安全无关，只影响性能与能力边界。
容易踩的坑：
-
TEMPTABLE视图不支持更新（UPDATE/DELETE报错View 'xxx' references invalid table(s) or column(s)），哪怕底层是单表 - 一旦用了
GROUP BY、DISTINCT、聚合函数或子查询，MySQL 自动降级为TEMPTABLE，这时候别手动指定，反而干扰优化器 - 物化过程会多一次临时表写入，大结果集下内存/磁盘压力明显，监控
Created_tmp_tables会飙升
权限隔离才是隐藏表名的实际落地方式
MySQL 没有“表名隐身术”，只有“不让看+不让碰”。关键操作都在 mysql 系统库的权限表里，不是靠视图语法能绕开的。
实操建议：
- 建专用账号，例如
app_reader@'%'，只执行：GRANT SELECT ON mydb.v_user_summary TO 'app_reader'@'%';<br>REVOKE SELECT ON mydb.users FROM 'app_reader'@'%';
- 删掉
INFORMATION_SCHEMA.TABLES的访问权限？不行——MySQL 8.0+ 默认所有用户都能查这个库，只能靠网络层或代理层过滤 - 如果 DBA 无法控制账号权限（比如共享数据库环境），那就别依赖视图“藏表名”，老老实实改应用层连接串，用不同账号连不同逻辑库
最常被忽略的一点：视图可以嵌套，但每层都得单独授予权限。只给顶层视图 SELECT，不给它依赖的下层视图或表权限，照样报错 Table 'xxx' doesn't exist——这个错误信息本身就会暴露表名。
