直接查 information_schema.COLUMNS 可快速获取表字段信息，但需指定 table_schema 以避免性能问题，且其元数据存在延迟与一致性风险，复杂场景应优先使用 performance_schema 或 mysqldump DDL 快照。
查表结构不用翻建表语句，直接问 information_schema
开发或 DBA 想快速知道某张表有哪些字段、类型、是否允许 NULL、有没有默认值，没必要去翻 CREATE TABLE 语句或者依赖 GUI 工具。直接查 information_schema.COLUMNS 最快：
SELECT column_name, data_type, is_nullable, column_default<br>FROM information_schema.COLUMNS<br>WHERE table_schema = 'your_db' AND table_name = 'your_table'<br>ORDER BY ordinal_position;注意
table_schema 是数据库名（不是当前库别漏写），column_default 对表达式默认值（如 CURRENT_TIMESTAMP）会返回带引号的字符串，不是裸值。
information_schema 查询慢？别在大库上 SELECT *
它本质是 MySQL 的“虚拟库”，底层访问存储引擎元数据，不走索引，全表扫描开销不小。尤其在有几百个库、几千张表的实例上，执行 SELECT * FROM information_schema.TABLES 可能卡住几秒甚至超时。实际用法要收敛条件：
- 务必带上
table_schema过滤具体库，别用LIKE '%xxx%'扫全库 - 查索引优先用
STATISTICS而非KEY_COLUMN_USAGE，前者字段更全、过滤更稳 - 避免在定时脚本里无节制轮询——比如每分钟查一遍所有表的行数（
TABLE_ROWS），这个值本身不准（InnoDB 是估算），还拖慢 performance_schema
自动化运维脚本里，别把 information_schema 当配置中心用
有人写巡检脚本，把 information_schema.COLUMNS 结果存进本地 JSON 做比对基线，这很危险：
-
information_schema不保证事务一致性——同一时刻查COLUMNS和TABLES，可能看到“表存在但列为空”的中间态 - 字段长度等信息在 MySQL 8.0.23+ 有缓存行为，刚
ALTER TABLE完立刻查，可能拿不到最新结果 - 权限受限时（比如只给了
SELECT），连information_schema都可能查不到自己有权限的表（取决于skip_show_database和用户 host 匹配）
mysqldump --no-data 导出 DDL 快照，更可靠。MySQL 8.0 后 information_schema 有些表被标记为“deprecated”
比如 information_schema.PROCESSLIST 在 8.0 里已不推荐，应改用 performance_schema.threads + performance_schema.events_statements_current。类似地，查锁信息别再依赖 INNODB_LOCKS（5.7 已移除），改查 performance_schema.data_locks。官方迁移路径很明确：新功能、高精度、低开销的元数据都往 performance_schema 和 sys 库里放。information_schema 保留的是兼容性接口，适合简单查询，别指望它承载复杂诊断逻辑。
