mysql不支持时间维度权限控制，需通过代理层（如proxysql）、调度器或应用网关实现时段拦截，db侧仅能配合最小权限与监控告警。
MySQL本身没有内置的“时间段权限控制”功能，不能直接给用户配置“只允许在23:00–05:00查表”。所谓“限制ETL用户只能在非业务高峰期执行查询”，本质是靠外部手段拦截+数据库侧配合实现的，不是单纯改GRANT就能解决的事。
为什么不能靠GRANT或角色直接设时间权限
MySQL的权限系统（mysql.user、mysql.db等表）只支持按对象（库/表/列）、操作类型（SELECT/INSERT等）、来源主机、用户名做控制，不支持时间维度。即使在MySQL 8.0引入了角色（ROLE）和动态权限，依然没有TIME_BASED_SELECT这类权限项。试图用存储过程包装查询并加时间判断，既不可靠（应用可绕过），又难审计（日志里看不到原始SQL）。
可行方案：用代理层或触发式拦截
真正落地的生产做法，是把时间控制逻辑放在MySQL之前——也就是连接入口处。常见组合有：
- 用
ProxySQL配置mysql_query_rules，匹配user='etl_user'且destination_hostgroup=10的请求，再用apply_mysql_query_rules配合time_start/time_stop字段做时段放行； - 在应用网关（如Kong、Nginx+Lua）或ETL调度器（Airflow、DolphinScheduler）里加判断：当前时间不在
['00:00-06:00', '22:00-24:00']范围内，则拒绝提交查询任务； - 若必须在DB侧硬控，可建一个
time_control表，ETL脚本每次查询前先SELECT COUNT(*) FROM time_control WHERE NOW() BETWEEN start_time AND end_time，返回0才继续——但这是应用层逻辑，不是数据库强制。
误操作风险比想象中高
很多人想用EVENT定时REVOKE SELECT ON *.* FROM 'etl_user'@'%'再GRANT回来，这极其危险：EVENT执行失败会导致权限丢失；并发查询可能卡在权限校验阶段；且REVOKE会清空所有现有权限，不是增量控制。更糟的是，如果ETL任务正在跑，突然REVOKE，事务不会自动回滚，可能留下脏数据或锁表。
最务实的做法：权限最小化 + 时间段监控告警
与其费力堵住“不该查的时间”，不如确保“就算查了也查不到敏感数据”：
- ETL用户只授予具体需要的库和表的
SELECT权限，禁止ON *.*； - 用
performance_schema或slow_log开启long_query_time=0，采集所有ETL用户的查询，用脚本每5分钟扫一次，发现hour(NOW()) IN (9,10,11,14,15,16)范围内的查询就发企业微信告警； - 在ETL调度平台统一配置“允许执行窗口”，所有任务必须带
execution_window参数，数据库连接池初始化时读取该参数并缓存，后续查询都校验时间——这比在DB里折腾安全得多。
真正卡住时间点的控制，从来不在MySQL内部。它要么在调度层，要么在代理层，要么在应用代码里。指望GRANT语句自带闹钟功能，只会把问题引向更难排查的权限漂移或连接中断。
