MySQL无原生时间限制访问权限，需通过EVENT定时LOCK/UNLOCK账户模拟，或由应用层、中间件在连接时校验时间实现；依赖系统时间准确且无法实时断开已存在连接。
MySQL 中没有原生的「时间限制访问权限」机制
MySQL 的 GRANT 语句不支持直接指定「只在每天 9:00–18:00 允许登录」或「仅限工作日访问」这类基于时间的权限控制。它的权限模型是静态的：用户是否存在、密码是否正确、host 是否匹配、全局/库/表级权限是否授予——这些都在连接建立时检查，不涉及运行时的时间判断。
用 MySQL 事件 + 账户状态模拟时间限制
可行但需绕行：通过定期启用/禁用账户实现粗粒度时间控制。MySQL 支持 ACCOUNT LOCK 和 UNLOCK（5.7.6+），配合 EVENT 可定时切换状态。
- 必须启用
event_scheduler = ON（检查：SHOW VARIABLES LIKE 'event_scheduler';） - 账户需用
CREATE USER ... IDENTIFIED BY ...显式创建，不能是匿名用户 - 事件无法触发跨会话的实时断连，已建立的连接不会被强制终止
- 示例：每天 18:00 锁定用户
'app_user'@'192.168.1.%'
CREATE EVENT lock_app_user_at_eod ON SCHEDULE EVERY 1 DAY STARTS '2024-01-01 18:00:00' DO ALTER USER 'app_user'@'192.168.1.%' ACCOUNT LOCK;
真正生效的时间控制必须由应用层或中间件承担
数据库本身不校验连接发起时间，所以最可靠的方式是在应用连接池或代理层做拦截：
- 应用代码中调用
SELECT NOW()或CURRENT_TIME()判断当前时间，再决定是否执行查询 - 使用 ProxySQL 或 MaxScale，在
mysql_query_rules中结合match_digest和自定义变量（如@time_window）做路由过滤 - Linux 层面用
iptables或firewalld配合 cron 控制源 IP 端口访问时段（不推荐，过于粗暴） - 注意：
SELECT CURTIME()返回的是 MySQL 服务器本地时间，务必确认其时区与业务预期一致（SELECT @@time_zone;）
容易忽略的关键点
即使用了事件锁账户，仍存在几个隐蔽风险：
-
root或高权限用户可随时ALTER USER ... ACCOUNT UNLOCK，无法防内部越权 - MySQL 8.0+ 的角色（
ROLE）也不能绑定时间条件，角色启用/禁用仍是静态操作 - 客户端可能复用长连接，
ACCOUNT LOCK后新连接被拒，但旧连接仍可执行命令直到超时或主动断开 - 所有基于时间的方案都依赖服务器系统时间准确，NTP 同步失效会导致策略错位
