直接崩了就别查information_schema——它不支持百万级表；应改用SHOW CREATE TABLE或pg_catalog精准查询、预导出DDL快照、Jinja2分块渲染HTML、规则优先+向量化模糊匹配、虚拟滚动优化加载，并人工核对截断的字段注释。
对比两套大数据表结构时，SELECT * FROM information_schema 直接崩了怎么办
别硬查 information_schema —— 它不是为百万级表设计的。mysql 8.0+ 在库中表超 5000 张时，information_schema.tables 查询可能卡死或返回超时；postgresql 的 pg_class + pg_attribute 联查若没加 relkind = 'r' 过滤，会把索引、序列全扫一遍，拖慢 10 倍以上。
实操建议：
- 用
SHOW CREATE TABLE（MySQL）或\d+ table_name（psql CLI）按需拉取，写脚本批量执行，跳过information_schema - PostgreSQL 推荐走
pg_catalog：只查pg_class+pg_attribute+pg_type，且必须加AND a.attnum > 0和AND NOT a.attisdropped - 提前导出元数据到本地 JSON/CSV：用
mysqldump --no-data或pg_dump -s生成 DDL 快照，后续比对全在内存做
用 Python 生成结构对比 HTML 时，pandas.DataFrame.to_html() 渲染 10 万行直接 OOM
这不是 HTML 本身的问题，是 to_html() 默认把整张 DataFrame 加载进字符串再渲染，中间拷贝多、无流式处理。尤其字段名含中文或特殊字符时，还容易触发编码 fallback，内存翻倍。
实操建议：
- 别用
to_html()一次性生成——改用 Jinja2 模板 + 分块yield渲染，每 500 行 flush 一次 - 列名和类型差异用
diff思路预计算：先用set(table_a.columns) ^ set(table_b.columns)找缺失字段，再用df_a.dtypes != df_b.dtypes找类型不一致，HTML 只负责展示结果，不参与计算 - 禁用
to_html(index=True)，大数据下索引列会额外占 20%+ 内存；用index=False，靠 CSS class 标注行号
对比报告里要标出「字段语义等价但名称不同」，fuzzywuzzy 在 10 万字段对上跑不动
fuzzywuzzy（现 rapidfuzz）默认用 Python 实现 Levenshtein，单次比较耗时约 0.3ms；10 万 × 10 万 组合就是 100 亿次，算到明天也完不了。而且字段名缩写（如 usr_id vs user_identifier）靠编辑距离根本识别不了。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 先做规则过滤：统一转小写 + 去下划线 + 提取词干（
re.split(r'[_\W]+', name)），再用集合交集匹配，比如{'usr','id'} ∩ {'user','identifier'}≥ 1 就标记为候选 - 只对规则匹配失败的字段对启用模糊匹配，且限制最大长度差 ≤ 3、最小字符数 ≥ 2，跳过像
avsaccount_id这种无效组合 - 用
rapidfuzz.process.cdist替代循环调用，支持 NumPy 向量化，提速 5–8 倍
生成的 HTML 报告打开卡顿，Chrome 渲染 5 万行表格要 12 秒
浏览器不是数据库，DOM 节点一过万就明显掉帧。问题不在内容，而在默认用 <table> 全量加载——哪怕加了 overflow-y: auto，滚动时仍要解析全部 <tr>。
实操建议：
- 服务端分页：把对比结果切成每页 500 行，HTML 里只放第一页 + 页码导航，用
fetch()按需加载其他页 - 客户端虚拟滚动：用
react-window或原生IntersectionObserver，只渲染视口内 20 行，其余用height: 0; visibility: hidden占位 - 关键字段高亮用 CSS class 控制，别用内联
style——10 万行里每个<td>多 30 字节，就是额外 3MB DOM 开销
最麻烦的其实是字段注释同步问题：很多系统注释存在 information_schema.COLUMNS.COLUMN_COMMENT，但 MySQL 5.7 对长注释截断到 1024 字符，而实际业务字段注释常超 2000 字。这块没法靠工具自动补全，得人工核对源码或文档，漏了就真漏了。
