核心用法
该技能作为MySQL数据库设计专家，通过四步工作流完成标准化建表：首先解析用户上传的业务规则文档（.md）和存量SQL脚本（.sql），提取实体关系与字段约束；其次依据阿里巴巴Java开发手册数据库规范进行结构设计，包括小写下划线命名、VARCHAR(32)主键、DECIMAL金额、DATETIME时间、TINYINT状态等类型选择；然后强制添加标准审计字段（create_time/update_time/create_by/update_by/deleted），设计主键与索引遵循最左前缀原则；最终输出完整CREATE TABLE语句，指定InnoDB引擎与utf8mb4字符集。
显著优点
规范权威性：直接对标阿里巴巴MySQL规范与阿里云RDS最佳实践，覆盖命名、类型、索引、安全四大维度，避免团队重复造规范。
自动化程度高：支持文档自动解析→结构推导→DDL生成的端到端流程，大幅减少手工编写与规范对照的时间成本。
版本兼容：同时支持MySQL 5.7与8.0，明确标注8.0新特性（函数索引、JSON字段）的兼容性限制。
安全设计内置：强制逻辑删除（软删除）、审计字段、NOT NULL默认值，规避常见数据完整性风险。
潜在缺点与局限
规范刚性过强：阿里规范对字段数（≤20）、索引数（≤5）等限制较严格，超大规模业务场景可能需要人工突破。
无可视化能力：纯文本DDL输出，缺乏ER图、血缘关系图等可视化交付物。
分库分表有限：仅提及"考虑未来分库分表可能性"，未提供Sharding-JDBC等中间件的具体拆分策略生成。
MySQL专属：无法直接迁移至PostgreSQL、TiDB等兼容但细节差异较大的数据库。
适合人群
- 需快速启动新项目的中后台开发团队
- 缺乏DBA资源但需保障数据库规范性的中小企业
- 正在从MySQL 5.7向8.0迁移的存量改造团队
- 需统一多项目数据库规范的技术负责人
常规风险
1. 过度索引：虽规范建议单表索引≤5个，但复杂查询场景下可能不足，需结合实际执行计划调整
2. TEXT/BLOB误用：长文本拆表建议未明确阈值，大字段频繁访问可能引发随机IO性能问题
3. 枚举值维护：CHAR(2)状态码依赖应用层枚举类映射，库表分离时易出现不一致
4. 默认值陷阱：CURRENT_TIMESTAMP在5.6及以下不支持，跨版本迁移需校验
5. 敏感数据加密：文档仅提及"敏感字段加密存储"，未提供具体加密算法与密钥管理方案，需额外安全设计