直接查 INFORMATION_SCHEMA.COLUMNS 可精准发现字段缺失或类型错配，它比 DESCRIBE 更可靠，能暴露生成列、字符集等细节，重点核对 data_type、is_nullable、column_default 和字符集/排序规则。
怎么看 MySQL 表结构有没有字段缺失或类型错配
直接查 INFORMATION_SCHEMA.COLUMNS，这是最轻量、不依赖外部工具的方案。它能暴露所有字段名、类型、是否允许 NULL、默认值、字符集等细节，比 DESCRIBE table_name 更可靠——后者在某些 MySQL 版本里会隐藏生成列或忽略显式字符集声明。
常见错误现象：上线后报 Column 'xxx' cannot be null，但开发环境没复现；或者 JSON 字段存不了长文本，查出来发现其实是 VARCHAR(255) 而非 JSON 类型。
- 用
SELECT column_name, data_type, is_nullable, column_default, character_set_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'your_db' AND table_name = 'your_table' ORDER BY ordinal_position; - 重点核对：
data_type是否符合预期（比如时间字段该是datetime还是timestamp）、is_nullable是否与业务逻辑一致、column_default是否为空字符串而非NULL（尤其对NOT NULL字段） - 注意
character_set_name和collation_name：同一库下混用utf8mb4和utf8可能导致 JOIN 失败或索引失效
怎么批量比对两个环境的表结构差异
用 mysqldump --no-data --skip-comments 导出 DDL，再用 diff 或 sdiff 对比。别信 GUI 工具一键同步按钮——它们常忽略 ALGORITHM=INSTANT 兼容性、分区定义顺序、甚至索引注释。
使用场景：测试环境改了字段长度，但没同步到预发；或者 DBA 手动优化了索引，但开发不知道，代码里还按旧索引写查询条件。
- 导出命令示例：
mysqldump -h dev-host -u user -p --no-data --skip-comments mydb users > dev_users.sql，同理导出预发环境 - 对比前先统一排序：
grep -E '^(CREATE|ALTER|INDEX)' dev_users.sql | sort > dev_sorted.sql，否则字段顺序不同会导致假阳性差异 - 特别留意
ENGINE和ROW_FORMAT：InnoDB 表若被误设为COMPACT而非DYNAMIC，大字段可能触发Row size too large错误
为什么用 pt-online-schema-change 校验失败却仍能执行
pt-online-schema-change 的 --dry-run 和 --print 只检查语法和基础约束，不校验字段语义合理性。比如它不会告诉你 “把 INT 改成 TINYINT 会导致线上订单 ID 溢出”，也不会拦住你在高频更新表上加全文索引引发锁表。
性能影响很实际：一个未加 --chunk-index 的大表变更，可能让从库延迟飙升；而校验阶段根本看不出这点。
- 真正要校验的，是变更前后的数据一致性，不是 DDL 本身——得配合
pt-table-checksum在执行后跑一遍 - 容易踩的坑：
--max-load设太高，主库 CPU 到 90% 还继续切流量；或者漏掉--critical-load，导致从库 IO 扛不住时没中止 - 参数差异：
--alter-foreign-keys-method=rebuild_constraints在有外键的库中必须显式指定，否则校验通过但执行时报错
自建 Schema 校验脚本要注意哪些隐性兼容问题
Python 用 mysql-connector-python 查 INFORMATION_SCHEMA 很方便，但默认不返回 GENERATED COLUMN 的表达式，也不暴露 STORED/VIRTUAL 属性；Go 用 database/sql 查 COLUMNS.COLUMN_TYPE 时，json 类型会显示为 json，而 datetime(3) 会变成 datetime ——精度信息丢了。
可给出简短示例：
SELECT column_name, column_type, extra FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'orders' AND column_type LIKE '%json%';
这行 SQL 在 MySQL 5.7+ 返回 json，但在 8.0+ 会返回 json 或 longtext（如果用了旧版本升级路径），脚本若只匹配字符串字面量就会漏判。
- 别硬编码字段类型字符串，优先用
DATA_TYPE+CHARACTER_MAXIMUM_LENGTH+NUMERIC_PRECISION组合判断 - MySQL 8.0 的隐藏索引（
INVISIBLE）和降序索引（DESC）在SHOW CREATE TABLE里可见，但在STATISTICS表里不体现，校验脚本若只查后者就无效 - 跨版本迁移时，
TIMESTAMP默认行为变化极大（5.6 自动 ON UPDATE，5.7+ 需显式声明），光看字段类型不够，得连EXTRA一起校验
真正难的不是查出字段名，而是理解每个字段在当前 MySQL 版本、当前存储引擎、当前 SQL_MODE 下的实际行为边界。比如 STRICT_TRANS_TABLES 关闭时，INSERT INTO t(c1) VALUES('abcde') 对 VARCHAR(3) 字段会静默截断，校验脚本永远发现不了这个风险。
