mysql本身不支持基于时间的登录限制，可行方案是用cron定时执行alter user ... account lock/unlock控制账号开关，或在应用层/代理层拦截连接请求并校验当前时间是否在允许范围内。
MySQL本身不支持基于时间的登录限制
MySQL服务端没有内置机制（比如 GRANT 语法或系统变量）来控制用户“只能在 9:00–18:00 登录”。CREATE USER 和 GRANT 均不接受时间范围参数，mysql.user 表里也没有 login_start_time 或类似字段。
可行的替代方案：用操作系统的cron + MySQL账户状态控制
核心思路是定时启停用户的登录能力，通过切换其认证方式实现“逻辑上禁止登录”。实际生效依赖于 MySQL 的 authentication_string 字段和账户锁定机制。
- 每天 18:00 后，执行：
ALTER USER 'staff'@'%' ACCOUNT LOCK;
或更彻底地清空密码哈希：UPDATE mysql.user SET authentication_string = '' WHERE User = 'staff' AND Host = '%'; FLUSH PRIVILEGES;
- 每天 9:00 前，恢复可用状态：
ALTER USER 'staff'@'%' ACCOUNT UNLOCK;
或重置为有效密码哈希（推荐用SET PASSWORD而非直改表） - 必须用具有
UPDATE权限的高权限账号（如root）运行脚本，且该账号不能被同样限制 - 注意：MySQL 8.0+ 中
ACCOUNT LOCK是最干净的方式；5.7 只能靠清空authentication_string或设为无效哈希（如*0），但后者可能被绕过
更健壮的做法：在应用层或中间件拦截
如果登录请求统一经过某层代理（如 ProxySQL、自研连接池、Web 应用后端），应在该层做时间判断，而不是依赖数据库本身。
- 在连接建立前检查
hour(now())是否在允许范围内，直接拒绝非工作时间的连接请求 - 避免把时间逻辑下推到 MySQL，减少权限暴露面（比如不用给应用账号
ALTER USER权限） - 若使用 Python/Node.js 等语言建连，可在
connect()前加一层校验：if datetime.now().hour not in range(9, 18): raise PermissionError("Login denied outside working hours") - 注意时区一致性：确认应用服务器、MySQL 服务器、cron 所在机器的
TZ设置是否统一，否则会出现 1 小时偏差
容易被忽略的关键点
即使用了 ACCOUNT LOCK，也要注意：
-
ACCOUNT LOCK不影响已存在的活跃连接，只阻止新连接 —— 所以需配合KILL指令清理残留会话（可查SHOW PROCESSLIST后筛选） - MySQL 的
wait_timeout和interactive_timeout会影响“自动断连”行为，但无法精确卡在 18:00 断开，只能作为辅助 - 如果用户有多个 Host（如
'staff'@'192.168.%'和'staff'@'localhost'），必须对每条记录分别执行ALTER USER，否则会漏掉 - 备份与恢复时，
mysql.user表会被导出，时间策略配置不会自动带过去 —— 需单独维护 cron 脚本版本
