查information_schema.COLUMNS只能定位列名而非具体值；真要搜值需动态拼SQL扫描各表对应列，优先手动筛选高概率表+LIKE模糊匹配，再考虑自动化方案。
直接查 information_schema.COLUMNS 只能定位列，不能定位值
很多人一上来就跑 SELECT TABLE_NAME FROM information_schema.COLUMNS WHERE COLUMN_NAME = 'name' AND TABLE_SCHEMA = 'mydb'，这只能告诉你“name”这个字段在哪些表里存在，但完全不等于“John”这个值就在这些表的name列里。它查的是元数据结构，不是实际数据内容。
真要搜值，得动态拼 SQL + 扫描每张表的每列
MySQL 没有内置“全库搜值”命令，必须靠程序逻辑或存储过程驱动。核心思路是：
- 从
information_schema.COLUMNS中筛选出目标数据库中所有CHAR、VARCHAR、TEXT类型的列（数值类型如INT也可加，但需注意隐式转换） - 对每个
(table_name, column_name)组合，生成类似SELECT COUNT(*) FROM `t_user` WHERE `username` LIKE '%abc%'的语句 - 执行并判断是否返回 > 0 —— 这才是“值存在”的证据
- 注意：用
=匹配要求严格相等；用LIKE或CONVERT(... USING utf8mb4) LIKE ...才支持模糊/编码兼容匹配
SHOW TABLES 和 SHOW COLUMNS 在脚本里容易出错
这两个命令本身不报错，但实际用在自动化流程里常踩坑：
-
SHOW TABLES返回结果集字段名是Tables_in_dbname，不是table_name，硬写table_name会取不到值 -
SHOW COLUMNS FROM t不返回字段类型长度（比如VARCHAR(255)只显示varchar），导致无法安全过滤掉过长字段或二进制字段 - 表名或字段名含特殊字符（如横线、空格）时，不加反引号
`会语法错误，而information_schema.COLUMNS的TABLE_NAME和COLUMN_NAME是原始值，必须手动包裹
最简可行的手动方案：先缩小范围再单表验证
别一上来就写存储过程。先快速试几条关键语句：
SELECT TABLE_NAME, COLUMN_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db'
AND DATA_TYPE IN ('varchar', 'char', 'text', 'tinytext', 'mediumtext', 'longtext');
拿到结果后，挑几个高概率表手动查：
SELECT 't_user' AS table_name, 'username' AS column_name, id, username FROM t_user WHERE username LIKE '%john%';
这样比盲目扫全库快得多，也更容易定位到真实命中位置。真正需要自动化的场景（比如审计、迁移前探查），才值得上带游标和预编译的存储过程——但那已是另一层复杂度了。
