为什么建议在phpMyAdmin中禁用追踪(Tracking)功能以保护敏感操作？-phpMyAdmin-PHP中文网

tracking功能会暴露生产库的表变更记录、完整sql语句（含明文密码等敏感参数）、数据库结构及业务逻辑；必须同时关闭配置、删除tracking表、收回phpmyadmin库权限才能彻底禁用。

phpmyadmin 的 tracking 功能不是“记录谁在操作”，而是主动把每条 sql、每个表结构变更、甚至字段修改都存成可回滚的版本快照——它默认把所有这些元数据写进 phpmyadmin 数据库的 tracking 表里，而这个库和表往往被配置为所有账号可读（甚至可写），等于把操作日志直接摊开给攻击者看。

Tracking 功能会暴露哪些敏感信息？

开启后，只要用户有权限访问 phpmyadmin 系统库（通常默认就开了），就能直接查到：

SELECT * FROM phpmyadmin.tracking WHERE db_name = 'prod_db' —— 暴露生产库中哪些表被改过、改了几次、SQL 是什么
tracking 表里存着完整语句，包括带明文参数的 INSERT INTO users VALUES (1, 'admin', 'p@ssw0rd!')
如果用的是低权限账号但能连上 phpmyadmin 库，就能反向推导出其他数据库的结构、字段名、甚至业务逻辑

为什么不能只靠权限回收来禁用？

Tracking 不是靠 MySQL 用户权限开关控制的，它由 phpMyAdmin 自身逻辑驱动。即使你 REVOKE SELECT ON phpmyadmin.* FROM 'user'@'%'，只要该用户能登录 phpMyAdmin 并点开任意一张表的「结构」页，Tracking 就可能被前端自动触发（尤其 v4.9+ 默认启用）。

$cfg['Servers'][$i]['tracking'] = true 是显式开关，但很多一键包或旧配置根本没设这一项，phpMyAdmin 会 fallback 到默认行为（即开启）
Tracking 表本身由 CREATE DATABASE IF NOT EXISTS phpmyadmin 初始化，一旦存在，且用户有 phpmyadmin 库的 SELECT 权限，数据就可读
更危险的是：某些版本允许未授权访问 phpmyadmin/tracking.php 直接拉取历史记录

如何真正禁用 Tracking 功能？

必须三步一起做，缺一不可：

amphp

使用 AMPHP 框架编写非阻塞异步 PHP 代码，依赖 revolt/event-loop、amphp/amp ^3 及完整 amphp/* 生态（http‑server、http‑client 等）。

下载

在 config.inc.php 中显式关闭：$cfg['Servers'][$i]['tracking'] = false;（注意不是注释掉，而是设为 false）
删掉或重命名 phpmyadmin 系统库中的 tracking 表：DROP TABLE IF EXISTS phpmyadmin.tracking;
收回普通用户对 phpmyadmin 库的所有权限：REVOKE ALL PRIVILEGES ON phpmyadmin.* FROM 'user'@'%'; FLUSH PRIVILEGES;

容易忽略的兼容性坑

禁用后不会影响日常操作，但要注意：

v5.0+ 已移除 Tracking UI 入口，但后台仍可能尝试写入——所以删表比关配置更彻底
如果你用的是共享 phpMyAdmin 实例（多个项目共用一个入口），phpmyadmin 库是全局的，一个用户开 Tracking，所有人日志都可能被读
某些 CI/CD 流程会自动初始化 phpmyadmin 库并导入 tracking 表结构，上线前得检查脚本是否含 CREATE TABLE tracking

真正安全的禁用，不是让界面不显示「Tracking」标签页，而是让那张表不存在、那个配置为 false、那个库的权限被收走——三者少一个，都可能被绕过。