<p>phpMyAdmin 无法直接禁用 SELECT * 或全表扫描，需通过 MySQL 权限控制（如字段级授权、视图封装）、查询超时（max_execution_time）、资源组限制、用户隔离及监控干预等后端机制实现。</p>
phpMyAdmin 里怎么禁用 SELECT * 和全表扫描
phpmyadmin 本身不提供“禁止全表扫描”的开关，它只是 mysql 的前端界面；真正起作用的是 mysql 层的权限控制和查询限制机制。直接在 phpmyadmin 界面里点几下无法阻止用户执行 select * 或慢查询——除非后端 mysql 已经做了约束。
实操建议：
- MySQL 8.0+ 可通过
CREATE ROLE+GRANT SELECT (col1,col2) ON db.tbl显式授权字段，不给SELECT表级权限，就能天然拦住SELECT * - 对旧版 MySQL（5.7 及以下），只能靠
REVOKE SELECT ON db.tbl FROM 'user'@'%'彻底收回，再用视图封装可控字段：比如建CREATE VIEW safe_user AS SELECT id,name,created_at FROM user，再授予权限给视图 - phpMyAdmin 的
$cfg['Servers'][$i]['DisableIS'] = true配置能隐藏“信息架构”库，但不影响实际查询能力，别指望它防扫描
MySQL 查询配额：用 max_execution_time 和 resource group 控制耗时
max_execution_time 是最直接的防线，但它只对 SELECT 生效，且默认为 0（不限制）。设了也没用，除非客户端显式发起带 hint 的查询，或者服务端强制注入。
实操建议：
- 全局启用：在 MySQL 配置文件加
max_execution_time = 3000（单位毫秒），但注意这仅影响新连接，已有会话不受影响 - 更可靠的做法是配合 resource group：MySQL 8.0+ 支持
CREATE RESOURCE GROUP rg_low TYPE=USER THREAD_PRIORITY=-10，再用SET RESOURCE GROUP rg_low绑定会话，可压制 CPU 时间片，间接拖慢大扫描 - PHP 连接层（如 mysqli）可在 query 前加
/*+ MAX_EXECUTION_TIME(3000) */ SELECT ...，但 phpMyAdmin 不自动加这个 hint，得靠用户自己写——所以本质还是依赖规范意识
phpMyAdmin 用户隔离：别让一个账号通吃所有库
很多团队用同一个 MySQL 账号登录 phpMyAdmin，结果一人跑个 SELECT COUNT(*) FROM huge_log_table 就卡死整个实例。这不是 phpMyAdmin 的锅，是权限模型没切分。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 每个业务线/开发人员分配独立 MySQL 账号，用
CREATE USER 'dev_a'@'%' IDENTIFIED BY 'pwd'，再按需GRANT SELECT ON app_db.users TO 'dev_a'@'%' - 禁用
SHOW DATABASES权限：执行REVOKE SHOW DATABASES ON *.* FROM 'dev_a'@'%'，这样用户登录 phpMyAdmin 后只看到被授权的库，心理上也少点乱点的冲动 - 避免用 root 或
ALL PRIVILEGES账号配置 phpMyAdmin 的$cfg['Servers'][$i]['user']，哪怕只是临时调试——配置一旦写死，谁都可能误操作
监控与兜底：发现大查询时怎么快速中断
权限和配额都是预防手段，真有慢查询跑起来，得靠实时干预。phpMyAdmin 自带“刷新进程列表”功能（首页 → “状态” → “进程”），但默认只显示当前用户会话，看不到别人干了啥。
实操建议：
- MySQL 管理员账号必须保留
PROCESS和SUPER权限（或 8.0+ 的CONNECTION_ADMIN），否则连SHOW PROCESSLIST都看不到完整结果 - 在 phpMyAdmin 中点击“杀掉”按钮前，先复制
ID列数字，手动执行KILL 12345更稳妥——因为界面上的“杀掉”有时因权限不足静默失败，无提示 - 定期查
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%SELECT%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5，能揪出高频低效查询模板，比等告警更主动
真正难的不是设几个参数，而是让 DBA 和开发对同一张表的“合理查询方式”达成共识——比如哪些字段允许模糊搜索、是否接受 LIKE '%xxx%'、有没有覆盖索引。这些没法靠 phpMyAdmin 配置解决，得写进接口文档或 SQL 审核规则里。
