mysql原生不支持基于时间的权限控制，所有时间限制均需外部机制实现：①用account lock配合cron定时开关账号；②通过proxysql在连接层过滤；③在应用层校验时间再建连。
MySQL 本身不支持基于时间的权限访问控制。你不能在 GRANT、ALTER USER 或任何原生权限语句里写“只允许周一至五 9:00–18:00 登录”——这类语法根本不存在，也不会被解析。
所有所谓“时间限制”，都是外部机制模拟出来的效果，本质是定时开关账号或拦截连接请求。下面分几种实际可用的方式说清楚怎么做、为什么这么选、容易掉进哪些坑。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
用 ACCOUNT LOCK + cron 定时切换账号状态
这是最轻量、兼容性最好、无需额外组件的方案，适用于 MySQL 5.7.6+（含 8.x）。
- 每天固定时间执行
ALTER USER 'app_user'@'%' ACCOUNT LOCK或UNLOCK - 必须配
event_scheduler = ON才能跑事件，但更推荐用系统cron：它不依赖 MySQL 权限上下文，失败也容易排查 - 脚本里别硬写 root 密码，用
~/.my.cnf存凭证，并设chmod 600 - 示例 crontab（工作日早 9 点解锁、晚 6 点锁定）：
0 9 * * 1-5 mysql -NBe "ALTER USER 'app_user'@'%' ACCOUNT UNLOCK"
0 18 * * 1-5 mysql -NBe "ALTER USER 'app_user'@'%' ACCOUNT LOCK"
- 注意：
ACCOUNT LOCK只影响新连接，已存在的长连接不会断开；且 root 用户随时能手动UNLOCK，无法防内部越权
用 ProxySQL 在连接层做时间过滤
适合已有代理层或计划统一管理数据库流量的场景，比改账号状态更灵活、无刷新延迟。- ProxySQL 的
mysql_users表有active字段，配合 scheduler 脚本可动态开关 - 规则逻辑写在 Lua 或 SQL 中，例如：
SELECT IF(HOUR(NOW()) BETWEEN 9 AND 17 AND WEEKDAY(NOW()) BETWEEN 0 AND 4, 1, 0) - 关键点：ProxySQL 默认用自身系统时间，必须和 MySQL 服务端、应用服务器统一为 UTC，否则比对失效
- 连接被拒绝时返回标准
Access denied，客户端感知和原生拒绝一致 - 缺点：新增运维复杂度；scheduler 脚本需单独维护；无法控制已建立连接的后续操作
在应用层校验当前时间再决定是否建连
最可控、最贴近业务逻辑的方式，但要求所有访问都走同一套代码路径。- 不依赖 MySQL 版本或插件，也不动数据库配置
- 每次从连接池取连接前，先判断
datetime.now(timezone.utc)是否落在许可窗口内 - 示例（Python）：
if now.weekday() in (0,1,2,3,4) and 9 <pre class="brush:php;toolbar:false;"> conn = pool.get_connection()
- 风险点：若应用有多个入口（比如 CLI 工具、旧脚本、第三方 BI），容易漏控；时区必须用 UTC，不能信
time.localtime() - 优势：可结合业务上下文（如节假日白名单、审批状态）做复合判断，纯数据库方案做不到这点
别踩这些坑
-VALID UNTIL 不是 MySQL 语法，PostgreSQL 的写法直接报错
- 触发器、存储过程、BEFORE INSERT 对登录行为完全无效——连接建立早于任何 SQL 执行
- connection_control 插件只管输错密码频次，和时间段无关
- PASSWORD EXPIRE AT 只阻止新登录，不影响已存在会话，且不能替代权限回收
- 所有方案都依赖系统时间准确，NTP 同步失效会导致策略集体偏移，尤其跨时区部署时
真正严控时段访问，得组合用：ProxySQL 做第一道连接拦截 + 应用层二次校验 + 定时脚本兜底锁账号。单靠一种方式，总会有绕过路径或延迟窗口。
