直接查 information_schema.COLUMNS 可快速获取表字段信息，但需指定 table_schema 以避免性能问题，且其元数据存在延迟与一致性风险，复杂场景应优先使用 performance_schema 或 mysqldump DDL 快照。
查表结构不用翻建表语句，直接问
开发或 DBA 想快速知道某张表有哪些字段、类型、是否允许 NULL、有没有默认值，没必要去翻
语句或者依赖 GUI 工具。直接查
最快：
注意
是数据库名（不是当前库别漏写），
对表达式默认值（如
）会返回带引号的字符串，不是裸值。
查询慢？别在大库上
它本质是 MySQL 的“虚拟库”，底层访问存储引擎元数据，不走索引，全表扫描开销不小。尤其在有几百个库、几千张表的实例上，执行
可能卡住几秒甚至超时。实际用法要收敛条件：
务必带上
过滤具体库，别用
扫全库
查索引优先用
而非
，前者字段更全、过滤更稳
避免在定时脚本里无节制轮询——比如每分钟查一遍所有表的行数（
），这个值本身不准（InnoDB 是估算），还拖慢 performance_schema
自动化运维脚本里，别把
当配置中心用
有人写巡检脚本，把
结果存进本地 JSON 做比对基线，这很危险：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
不保证事务一致性——同一时刻查
和
，可能看到“表存在但列为空”的中间态
字段长度等信息在 MySQL 8.0.23+ 有缓存行为，刚
完立刻查，可能拿不到最新结果
权限受限时（比如只给了
），连
都可能查不到自己有权限的表（取决于
和用户 host 匹配）
真要做基线比对，建议用
导出 DDL 快照，更可靠。
MySQL 8.0 后
有些表被标记为“deprecated”
比如
在 8.0 里已不推荐，应改用
+
。类似地，查锁信息别再依赖
（5.7 已移除），改查
。官方迁移路径很明确：新功能、高精度、低开销的元数据都往
和
库里放。
保留的是兼容性接口，适合简单查询，别指望它承载复杂诊断逻辑。
information_schemaCREATE TABLEinformation_schema.COLUMNSSELECT column_name, data_type, is_nullable, column_default
FROM information_schema.COLUMNS
WHERE table_schema = 'your_db' AND table_name = 'your_table'
ORDER BY ordinal_position;table_schemacolumn_defaultCURRENT_TIMESTAMPinformation_schemaSELECT *SELECT * FROM information_schema.TABLEStable_schemaLIKE '%xxx%'STATISTICSKEY_COLUMN_USAGETABLE_ROWSinformation_schemainformation_schema.COLUMNSinformation_schemaCOLUMNSTABLESALTER TABLESELECTinformation_schemaskip_show_databasemysqldump --no-datainformation_schemainformation_schema.PROCESSLISTperformance_schema.threadsperformance_schema.events_statements_currentINNODB_LOCKSperformance_schema.data_locksperformance_schemasysinformation_schema