隐藏数据库结构不是靠“加密表名”或“改名字段”这类表面操作，而是通过权限控制、应用层隔离和最小暴露原则来实现。真正的安全不在于让结构“看不见”，而在于让不该接触的人“无法访问、无法推断、无法利用”。
严格限制数据库用户权限
绝不要用 root 或高权限账号运行应用。为每个应用或模块创建独立的数据库用户，并只授予其必需的最小权限：
只读功能（如报表展示）→ 仅授予 SELECT 数据录入 → 授予 INSERT，必要时加 UPDATE，但避免 DELETE 和 DROP 禁止授予 SHOW DATABASES、SHOW TABLES、INFORMATION_SCHEMA 查询权限（除非运维必需） 用REVOKE显式收回多余权限，例如：
REVOKE DROP ON `app_db`.* FROM 'app_user'@'%';
关闭元数据可发现性
MySQL 默认允许用户查询
INFORMATION_SCHEMA和
performance_schema，这会直接暴露库、表、列、索引等完整结构。可在生产环境做如下限制： 在
my.cnf中添加：
sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"（虽不直接隐藏结构，但减少异常暴露） 禁用非必要系统库访问：启动时加参数
--skip-show-databases（限制
SHOW DATABASES） 对普通应用用户，在连接后立即执行：
SET SESSION sql_log_bin = 0;（不影响结构，但降低日志泄露风险）；更关键的是，不在应用代码中拼接
SELECT * FROM INFORMATION_SCHEMA.TABLES类语句
应用层抽象与SQL封装
不让数据库结构穿透到前端或日志中：
禁止动态拼接表名/字段名（如"SELECT * FROM " + tableParam），一律使用白名单校验或预定义接口 API 返回字段名使用业务别名（如数据库字段
usr_email→ API 返回
sql_mode中避免
STRICT_TRANS_TABLES外的调试模式），应用层捕获异常后只返回通用提示（如“操作失败”，而非“Unknown column 'pwd_hash' in 'field list'”）
网络与部署隔离
从访问路径上切断未授权探查可能：
数据库不暴露在公网，仅允许应用服务器内网IP访问（通过防火墙或安全组限制） 禁用 MySQL 的远程 root 登录，删除匿名用户：DROP USER ''@'localhost'; FLUSH PRIVILEGES;启用 TLS 加密连接，防止抓包分析 SQL 流量（尤其是建表、查询系统表等行为） 定期审计用户权限和登录来源：
SELECT user, host, authentication_string FROM mysql.user;
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_USER IS NOT NULL;
不复杂但容易忽略：结构“隐藏”的本质是权限收敛 + 行为约束 + 信息过滤。比起花精力混淆表名，把一个
app_rw用户的权限卡死在三张表的四个字段上，效果更实在。
