information_schema是mysql 5.0+默认自带的只读系统视图集合，存储库、表、列等元数据，磁盘无对应文件，攻击者可直接查询其schemata、tables、columns表高效探测数据库结构。
因为它是MySQL 5.0+默认自带的只读元数据“地图”，不用猜、不用爆，直接查就能拿到库名、表名、列名。
information_schema 是什么，为什么它不是普通数据库
它不是用户创建的数据库，而是 MySQL 启动时自动生成的系统视图集合，内容来自内存和内部结构，磁盘上没有对应文件。你执行 SHOW DATABASES 能看到它，但进 @@datadir 目录找不到它的文件夹。
-
information_schema.schemata存所有数据库名，字段是schema_name -
information_schema.tables存所有表，关键字段是table_schema（库名）和table_name（表名） -
information_schema.columns存所有字段，含column_name、data_type、table_name、table_schema
攻击者用它绕开“盲猜”的核心原因
MySQL 4.x 或更早版本没这个库，攻击者只能靠 ' OR 1=1-- 碰运气试 users、admin 这类常见表名——效率极低，且容易被日志或 WAF 拦住。
- 有了
information_schema，一句UNION SELECT table_name FROM information_schema.tables WHERE table_schema=database()就列出当前库全部表 - 不需要知道目标业务逻辑，也不依赖报错信息或延时响应，纯联合查询就能完成结构探测
- 即使应用层过滤了
UNION或SELECT，还能配合extractvalue()、updatexml()做报错注入，本质仍是读information_schema的内容
实际注入中怎么定位和适配它
不是所有环境都能直接用 information_schema.columns ——权限、MySQL 版本、WAF 规则都会影响可用性。
- 先确认 MySQL 版本：
SELECT VERSION()；若低于 5.0，information_schema根本不存在 - 检查当前用户是否有访问权限：有些部署会
REVOKE SELECT ON information_schema.* FROM 'app'@'%'，此时查询会报错Access denied - 注意
table_schema字段值是字符串，必须加引号匹配，比如WHERE table_schema='myapp_db'，不能写成= database()（除非确定上下文数据库就是目标库） - 字段长度限制：某些老 WAF 会截断长 SQL，
information_schema.columns行数多，可能触发长度拦截，这时优先查tables缩小范围
真正麻烦的从来不是“怎么查 information_schema”，而是当它被禁用、被权限隔离、或被 WAF 拆解关键词时，你得立刻切换到布尔盲注或时间盲注——这时候，连 schemata 都查不到，就得一个字节一个字节去猜 schema_name 了。
