EXPLAIN会暴露业务逻辑并可能修改数据，因其不语义隔离，执行时会真实调用存储函数或触发器（如CLEANUP()），且输出计划可反推表结构、索引、JOIN顺序及WHERE条件等关键信息。
EXPLAIN 本身不加密、不隐藏逻辑，且在 MySQL 中执行它可能意外修改数据——不能靠它防泄露，只能靠权限控制来限制谁能看到。
EXPLAIN 为什么会暴露甚至修改业务逻辑
MySQL 的 EXPLAIN 不做语义隔离：只要查询里调用了存储函数或触发器，EXPLAIN 就会实际执行它们（比如触发 CLEANUP() 删除数据）。这不是 bug，是设计行为——它需要真实估算成本，就得走通表达式求值路径。同时，EXPLAIN 输出的执行计划本身就能反推表结构、索引使用、JOIN 顺序、WHERE 条件强度等，间接暴露业务规则（例如 “为什么只查 status=1 的订单？”）。
- 常见错误现象：
EXPLAIN SELECT * FROM (SELECT cleanup()) t导致数据被删，但用户没执行任何 DML - 使用场景：DBA 调优时用，开发查慢 SQL 时也常用，但普通账号不该有此能力
- 性能影响：无额外开销，但副作用不可控；PostgreSQL 的
EXPLAIN默认不执行函数，更安全
MySQL 没有 explain 权限，但能用 SHOWPLAN 替代限制
MySQL 官方不提供 EXPLAIN 独立权限（不像 PostgreSQL 有 pg_read_all_data 或 SQL Server 的 SHOWPLAN 权限）。你无法单独禁止某人用 EXPLAIN，但可以剥夺其“看到执行计划所需的前提”：
- 撤掉
PROCESS权限：没有它，EXPLAIN对涉及子查询、临时表、派生表的语句会报错ERROR 1227 (42501): Access denied; you need (at least one of) the PROCESS privilege(s) for this operation - 禁用
INFORMATION_SCHEMA访问：移除对INFORMATION_SCHEMA.STATISTICS、INFORMATION_SCHEMA.KEY_COLUMN_USAGE的 SELECT 权限，让EXPLAIN缺少元数据支撑，部分计划字段（如key_len、ref）显示为 NULL 或不准确 - 不给
SELECT权限：最直接——没权限查表，EXPLAIN就根本跑不起来（报ERROR 1142 (42000): SELECT command denied）
真正该限制的是谁有权限看 ROUTINES 和 TABLES
比起纠结 EXPLAIN，更关键的是堵住逻辑泄露主渠道：information_schema.ROUTINES 和 information_schema.VIEWS。存储过程和视图定义明文可读，EXPLAIN 只是顺带暴露更多。
- 创建专用执行账号（如
'proc_runner'@'10.0.2.%'），只授EXECUTE，不给SELECToninformation_schema - 用
REVOKE SELECT ON information_schema.* FROM 'app_user'@'%';显式收回元数据访问权（MySQL 8.0+ 支持） - 避免用
DEFINER = 'root'@'%'创建过程——这会让执行者继承 definer 权限，可能绕过权限检查 - 定期检查：运行
SELECT ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db';，确认无高权限定义者
复杂点在于：哪怕你封死了所有权限，只要账号能连上实例并拥有 SELECT on information_schema.ROUTINES，它就能还原出全部存储过程逻辑。EXPLAIN 的风险只是“附带执行”，而元数据表才是真正的逻辑金库——别把它当成次要项。
