优化 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结果，聚焦真实瓶颈；上线前务必在测试环境验证数据迁移与查询行为变化。
