业务系统表结构因长期迭代出现语义重复、类型冗余、命名模糊等字段冲突问题，需通过提取含comment的完整建表语句，用qwen模型识别冗余字段对并输出json建议，再经人工复核代码与git历史后落地合并。
业务系统迭代多年，表结构频繁变更，开发人员各自添加字段，导致一张表里出现语义重复、类型冗余、命名相似但含义模糊的字段，比如 【user_name】 和 【username】 同时存在，或 【create_time】 与 【created_at】 都是 datetime 类型却指向同一业务含义——这类冗余字段不光浪费存储空间，更会误导新接入的开发和BI同学，埋下数据一致性隐患。
提取表结构元数据并生成可读描述
先用 MySQL 客户端连接目标库，执行：SHOW CREATE TABLE your_table_name;，把建表语句完整复制出来。不要只看字段名列表，必须包含字段类型、默认值、注释（COMMENT）、是否允许 NULL、主键/唯一约束等上下文信息——缺少这些，模型无法判断 tinyint(1) 是布尔标志还是状态码，也无法区分 varchar(20) 和 varchar(255) 是否属于同一语义层级。
把建表语句粘贴进一个纯文本文件（如 table_schema.txt），保存为 UTF-8 编码。这一步不能跳过，直接截图或 PDF 输入会导致模型识别错乱。
构造提示词让Qwen识别字段语义冲突
方法一：使用 Qwen2.5-7B-Instruct 或更高版本（推荐 32B），在本地部署后启动对话界面：
输入以下提示词（注意保留换行和缩进）：
你是一名资深数据库架构师。请严格基于以下 MySQL 表结构定义，逐字段分析是否存在语义冗余、类型冗余或命名冲突。要求：① 只输出 JSON 格式；② 字段对必须同时满足「类型兼容」「业务含义高度重叠」「无明确分工说明」才判定为冗余；③ 对每组冗余字段，给出合并建议（保留哪个、为何保留）；④ 不要臆测业务逻辑，仅依据字段名、类型、注释、约束推断。结构如下：
{"redundant_pairs": [{"field_a": "xxx", "field_b": "yyy", "reason": "xxx", "suggestion": "xxx"}], "non_redundant_notes": ["xxx"]}
把 table_schema.txt 全文粘贴在提示词下方，中间空一行。模型会自动解析字段注释里的中文描述，比如 COMMENT '用户注册手机号' 和 COMMENT '用户绑定手机号' 就可能被识别为同一实体。
【关键前提】 表结构中必须包含 COMMENT 注释，否则模型仅靠字段名（如 mobile 和 phone）容易误判——这两个词在中文语境下常混用，但若注释分别写明“用户主联系方式”和“紧急联系人电话”，就不是冗余。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
用 Python 脚本批量喂入多张表
第一步：编写脚本从 information_schema.columns 提取指定库所有表的字段信息：
连接数据库后执行 SQL：SELECT table_name, column_name, data_type, is_nullable, column_default, column_comment, column_key FROM information_schema.columns WHERE table_schema = 'your_db_name' ORDER BY table_name, ordinal_position;
第二步：将查询结果转为结构化字典，按表名分组，每张表生成一段带格式的自然语言描述，例如：“表 orders 包含字段：order_id（bigint，主键）、user_id（bigint，非空）、status（varchar(20)，注释：订单当前状态）、order_status（varchar(20)，注释：订单生命周期阶段）……”
第三步：对每张表调用 Qwen2.5-32B-Instruct 的 API 接口，传入上述描述文本，并设置 temperature=0.1 保证输出稳定。模型返回 JSON 后，用 Python 解析 redundant_pairs 字段，直接写入 CSV 报告。
这一步操作起来很简单，直接把文件拖进去就行。但注意：不要一次性提交超过 5 张表的描述——Qwen2.5-32B 虽支持 128K 上下文，但字段描述堆叠后易触发 token 截断，导致漏判。
人工复核与落地合并
① 拿到模型输出的冗余对列表后，先查 Git 历史，确认两个字段是否由不同 PR 在不同时间添加；
② 查应用代码，确认是否有服务仍在读写被标记为冗余的字段；
③ 若字段确属冗余，执行 ALTER TABLE … DROP COLUMN 操作前，必须先在测试环境用 pt-table-sync 工具校验数据一致性；
④ 合并后更新所有相关文档、ORM 映射、API 响应 Schema，并在字段注释中加一句“已合并至 xxx 字段”。
模型不会告诉你某字段正在被某个凌晨跑的报表任务读取——这个动作必须人工验证。跳过这步直接删字段，线上服务立刻报错。
