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 同步失效会导致策略错位
