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 功能？
必须三步一起做，缺一不可：
- 在
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;
容易忽略的兼容性坑
禁用后不会影响日常操作，但要注意：
立即学习“PHP免费学习笔记（深入）”；
- v5.0+ 已移除 Tracking UI 入口，但后台仍可能尝试写入——所以删表比关配置更彻底
- 如果你用的是共享 phpMyAdmin 实例（多个项目共用一个入口），
phpmyadmin库是全局的，一个用户开 Tracking，所有人日志都可能被读 - 某些 CI/CD 流程会自动初始化
phpmyadmin库并导入 tracking 表结构，上线前得检查脚本是否含CREATE TABLE tracking
真正安全的禁用，不是让界面不显示「Tracking」标签页，而是让那张表不存在、那个配置为 false、那个库的权限被收走——三者少一个，都可能被绕过。
