phpMyAdmin 不限制每小时查询次数，真正起作用的是 MySQL 的 MAX_QUERIES_PER_HOUR 设置，但该功能在 MySQL 5.7.6+ 默认不校验、8.0+ 彻底失效；phpMyAdmin 仅转发 SQL，无拦截计数能力。
phpmyadmin 本身不提供“每小时查询次数”限制功能，它只是 mysql 的图形化操作界面；真正起作用的是 mysql 服务端的 max_queries_per_hour 设置，而 phpmyadmin 只能帮你执行对应 sql 命令——但多数情况下，这个设置在 mysql 5.7+ 实际不生效。
为什么在 phpMyAdmin 里设了 MAX_QUERIES_PER_HOUR 却没反应
你可能在 phpMyAdmin 的“用户账户”页面里勾选了“最大查询数/小时”，或手动执行了 ALTER USER ... WITH MAX_QUERIES_PER_HOUR 100，但后续用该用户反复执行 SELECT 1 却从不报错。原因很直接：
- MySQL 5.7.6+ 默认跳过
mysql.user表中max_questions字段的运行时校验，即使你设了值，服务端根本不检查 - MySQL 8.0 彻底移除了该字段的限流逻辑，
CREATE USER ... WITH MAX_QUERIES_PER_HOUR仅保留语法兼容，实际是空操作 - phpMyAdmin 没有中间件能力，它不会拦截、计数或拒绝请求，所有 SQL 都原样转发给 MySQL 执行
在 phpMyAdmin 中误配 MAX_QUERIES_PER_HOUR 的典型错误
你可能以为点几下就搞定，结果白忙一场。常见操作陷阱包括：
- 在“用户账户”→“编辑权限”页勾选“最大查询数/小时”并填数字——这本质是执行
GRANT USAGE ON *.* TO 'u'@'h' WITH MAX_QUERIES_PER_HOUR N，但该语法在 8.0+ 已废弃，且只对当前 GRANT 生效，极易被其他权限覆盖 - 用 phpMyAdmin 直接 UPDATE
mysql.user表的max_questions字段，却忘了执行FLUSH PRIVILEGES，导致修改完全不加载 - 把
MAX_QUERY_PER_HOUR（少 s）或MAX_QUESTIONS_PER_HOUR（旧别名）当正确参数写入，MySQL 静默忽略或报语法错误 - 设完后立刻用连接池（如 HikariCP）测试——单个连接反复执行 100 次
SELECT就触发限流，但因底层不生效，你以为是配置错了，其实是 MySQL 根本没跑校验
真正能落地的替代方案（必须绕开 phpMyAdmin）
如果你真需要按小时维度做查询频控，得跳出 phpMyAdmin 和 MySQL 原生限制，用外部组件实现：
-
ProxySQL：在 MySQL 前加一层代理，通过
mysql_query_rules匹配用户名 + SQL 类型（如^SELECT），配合stats_mysql_commands_counters轮询统计，每小时清零或 kill 超限会话；配置虽稍重，但生产环境最稳 -
应用层 Redis + Lua：每次查询前执行
INCR user:api_user:hourly_qps并EXPIRE ... 3600，返回值 > 100 就拒绝；需确保所有业务路径都走这一层，漏掉 ORM 启动时的SELECT DATABASE()就会误超 - 禁止用触发器或审计插件计数：开销大、非原子、易死锁，MySQL 官方明确不推荐用于实时限流
最后提醒一句：MySQL 原生的 MAX_QUERIES_PER_HOUR 在当前主流版本（5.7.21+ / 8.0.3+）中，只有极少数开启特定启动参数（如 --old-passwords=0 + 自定义 init-file）的老旧部署才可能生效；绝大多数线上环境，它就是个摆设。别在 phpMyAdmin 里浪费时间调这个参数，直接上 ProxySQL 或应用层控制更省心。
立即学习“PHP免费学习笔记（深入）”；
