应通过MySQL原生机制限流：用MAX_QUERIES_PER_HOUR限制每小时查询总数，MAX_USER_CONNECTIONS控制并发连接数，max_execution_time终止超时SELECT，配合phpMyAdmin前端配置收紧与网络层防护。
直接限制恶意查询拖垮 MySQL，不能靠 phpMyAdmin 界面本身——它只是个前端，真正起作用的是 MySQL 的资源配额机制和查询层拦截。phpMyAdmin 没有“防刷”“限流”按钮，硬要靠它拦，等于用纸糊堤坝挡洪水。
用 MAX_QUERIES_PER_HOUR 给用户套上硬限流
这是 MySQL 原生、最接近“防并发恶意查询”的机制：它按用户账号统计任意连续 60 分钟内所有语句总数（SELECT、SHOW、EXPLAIN，甚至 ORM 启动时的 SELECT DATABASE() 都算），超限立即报错 ERROR 1226 (42000)。
- 新建用户时设置：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 300; - 已有用户修改：
ALTER USER 'report_user'@'localhost' WITH MAX_QUERIES_PER_HOUR 100; - 设为
0才表示不限；省略或写错拼写（如MAX_QUERY_PER_HOUR）会静默失效 - 注意：它不是滑动窗口，而是按 MySQL 服务端整点小时滚动重置，业务侧理解的“过去 60 分钟”不一致
用 MAX_USER_CONNECTIONS 控制单用户并发连接数
防止一个账号开几十个长连接占满 max_connections，尤其适用于被代理或爬虫滥用的场景。
- MySQL 5.7+ 必须用
ALTER USER ... WITH MAX_USER_CONNECTIONS 5;或带WITH的GRANT，CREATE USER里写无效 - 设为
0是不限（不是禁止连接），修改后立即生效，不用FLUSH PRIVILEGES - 验证是否生效：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'xxx'; - 别和
wait_timeout混淆：后者只杀空闲连接，不控并发数量
在 phpMyAdmin 配置里堵住前端失控入口
很多“恶意查询”其实源于用户手抖或脚本误传——比如 URL 里塞 ?limit=9999999，后端没校验就拼进 SQL，LIMIT 反而成了全表扫描加速器。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
立即学习“PHP免费学习笔记（深入）”；
- 编辑
config.inc.php，强制收紧界面行为：$cfg['MaxRows'] = 200;（禁用无分页加载）$cfg['LimitChars'] = 500;（截断 TEXT 字段，防 HTML 膨胀） - 禁用危险功能：设
$cfg['ShowSQL'] = false;和$cfg['EnableAutocomplete'] = false;，减少隐式元数据查询 - 切勿把 phpMyAdmin 暴露在公网；若必须用，至少用反向代理加 IP 白名单 + 基础认证
真正兜底：MySQL 层加 statement_timeout（PostgreSQL）或等效机制
MySQL 本身没有 statement_timeout，但可通过 max_execution_time（5.7.8+）实现类似效果——对 SELECT 查询强制超时中断，避免慢查询卡死连接池。
- 会话级启用：
SET SESSION MAX_EXECUTION_TIME = 30000;（单位毫秒） - 全局默认（需重启或动态变量支持）：
SET PERSIST max_execution_time = 30000; - 注意：它只对 SELECT 生效，对 INSERT/UPDATE/DELETE 无效；且无法阻止执行计划生成阶段的卡死
- 配合
slow_query_log+long_query_time = 1，快速定位未加索引的烂查询
最难防的从来不是单次大查询，而是高频小查询堆出来的资源耗尽——MAX_QUERIES_PER_HOUR 和 MAX_USER_CONNECTIONS 必须配对使用，再叠加上层应用参数校验，才可能挡住真实攻击。别信“调高 memory_limit 就能扛住”的说法，那只是把崩溃延迟到更难排查的时刻。
