优化 MySQL 表结构的关键是匹配访问模式、减少冗余、精准选型、合理索引、拆分宽表及善用约束。具体包括：1. 用 TINYINT 代替 INT、DATE 代替字符串、VARCHAR 代替 TEXT、CHAR 用于定长编码；2. 主键优选自增整型，高频字段建联合索引并遵循最左前缀原则；3. 拆分大字段至扩展表，按业务或时间归档历史数据；4. 非空约束、ENUM/ 字典表、默认值提升性能与一致性，外键依场景权衡；5. 所有变更需基于慢日志与 EXPLAIN 分析，并经测试验证。
优化 MySQL 表结构是提升查询速度、降低存储开销和增强系统稳定性的关键一步。核心在于让数据组织方式更贴近实际访问模式，减少冗余、避免类型滥用、合理使用索引与约束。
选择合适的数据类型
小而精准的类型能减少磁盘 I/O、内存占用 和 CPU 计算开销。
- 用 TINYINT 代替 INT 存储 状态码 （如 0/1/2），节省 3 字节/ 行
- 用 DATE 或 DATETIME 而非字符串存时间，便于计算与索引下推
- 避免 TEXT / BLOB 存短文本（如标题、标签），优先用 VARCHAR(N) 并设合理上限
- 对确定长度的 编码（如身份证、手机号、UUID），考虑 CHAR（定长）提升检索效率，但注意填充开销
规范主键与索引设计
主键不仅是唯一标识，更是聚簇索引的载体，直接影响全表数据物理排序。
- 优先使用自增 INT 或 BIGINT 作主键，避免用 UUID 或字符串——减少页分裂、提升插入性能
- 高频查询条件字段（如 user_id、order_status、create_time）要建立联合索引，遵循 最左前缀原则
- 删除长期不用或重复度高的索引（如单列 gender），索引越多，写入越慢
- 对大文本字段做前缀索引需谨慎（如
INDEX(title(50))），确保前缀有足够区分度
拆分宽表与垂直分区
单表字段过多会拖慢查询、增加锁竞争、影响缓存效率。
- 把不常访问的大字段（如详情描述、HTML 内容、JSON 配置）移到单独扩展表，主表只留核心字段
- 按业务逻辑分离：例如用户基础信息（user）与用户设置（user_setting）、用户统计（user_stat）分开存储
- 读多写少且数据量大的历史表，可按时间归档为 user_log_2024、user_log_2023 等，配合分区表或应用层 路由
善用约束与默认值
约束不是负担，而是数据库自我保护机制，也能辅助优化器生成更优执行计划。
- 非空字段明确加 NOT NULL，避免 NULL 值参与索引失效或聚合计算异常
- 枚举类字段（如订单状态）用 ENUM 或小整型 + 字典表，比 VARCHAR 更省内存、查得快
- 常用默认值（如
created_at DEFAULT CURRENT_TIMESTAMP）由数据库生成，减少应用层拼 SQL 的出错风险 - 外键在高并发写场景下可能成为瓶颈，若应用层已保证一致性，可权衡去掉以换取写入性能
不复杂但容易忽略。改表结构前先分析慢查询日志和 EXPLAIN 结果，聚焦真实瓶颈；上线前务必在测试环境验证数据迁移与查询行为变化。
