大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
上周讲了参数调优，上上周讲了索引优化。但有个问题一直没聊：如果表结构本身设计就有问题，参数和索引能救回来吗？
答案很残酷：救不回来。
一个字段类型选错，可能导致索引失效、内存浪费、查询变慢——而你调参数、加索引，都是在“治标”。今天把表结构设计中最常见的性能陷阱拆开讲一遍。
一、字段类型选错的性能代价
VARCHAR vs CHAR：别凭感觉选
| 类型 | 特点 | 适用场景 | 性能影响 |
CHAR(n) |
固定长度，不足补空格 | 长度固定的值（身份证号、MD5） | 存储浪费但读取快 |
VARCHAR(n) |
可变长度，存多少占多少 | 长度不固定的值（姓名、地址） | 存储节省但读取有额外开销 |
一个反面案例：某系统phone字段用了VARCHAR(20)，表里500万行数据，索引建在phone上。执行WHERE phone = '13800138000'，查询倒是走了索引，但key_len显示用满了20个字符——索引页里能存的条目数变少，缓冲池浪费了30%以上。
优化方案：将phone改为VARCHAR(11)，如果业务只查前几位，还可以用前缀索引CREATE INDEX idx_phone ON users(phone(3))。调整后索引大小缩减约40%，查询响应时间从200ms降到80ms。
DATETIME vs TIMESTAMP：差了8小时可能丢数据
| 类型 | 存储空间 | 时区处理 | 取值范围 |
DATETIME |
8字节 | 不自动转换 | 1000-9999年 |
TIMESTAMP |
4字节 | 自动转换 | 1970-2038年 |
坑点：跨国业务用TIMESTAMP时，MySQL会自动根据时区转换，但某些国产库的行为可能不同。如果迁移后时区没配置对，报表里的时间可能差8小时。
建议：跨国业务或需要精确时间戳的场景，优先用DATETIME；只存国内时间且对存储空间敏感，用TIMESTAMP。
二、字符集陷阱：utf8mb4带来的索引长度超限
这是MySQL 5.7升级到8.0时最常见的坑。
InnoDB的索引长度限制是3072字节。utf8mb4每个字符占4字节，VARCHAR(255)就需要1020字节。如果一张表有多个VARCHAR(255)字段都在索引里，很容易超过3072字节限制——CREATE INDEX直接报错。
解决方案：
- 使用
utf8mb3代替utf8mb4（如果不需要存储emoji） - 使用前缀索引：
CREATE INDEX idx_name ON table(column(100)) - MySQL 8.0.30+支持
innodb_fill_factor控制索引页填充率
一个教训：某互联网公司的用户表，昵称字段用了VARCHAR(255)，加索引时发现Specified key was too long。最后只能删掉索引重建，线上业务停了15分钟。表设计阶段的错误，上线后要付出10倍的代价。
三、大量NULL值对索引的影响
InnoDB中，NULL值在索引中会占用额外空间。如果某列90%都是NULL，索引的Cardinality会低估该列的选择性，优化器可能放弃使用这个索引。
解决方案：
- 如果业务逻辑允许，用默认值代替
NULL（如status默认'active'） - 使用
NOT NULL约束（但需要确认业务真的允许）
一个案例：一张日志表的user_id列允许NULL，90%的行是NULL（因为匿名访问）。虽然建了索引，但优化器认为选择性太低，大部分查询走了全表扫描。将user_id改为NOT NULL DEFAULT 0后，查询走了索引，响应时间从3秒降到0.1秒。
四、表结构调整的“晚期成本”
表结构设计阶段的错误，改动越晚成本越高：
| 发现阶段 | 改动成本 | 风险 |
| 设计阶段 | 低（改SQL即可） | 几乎为零 |
| 开发阶段 | 中（改代码+改表） | 低 |
| 测试阶段 | 高（重新测试+数据迁移） | 中 |
| 生产环境 | 极高（锁表+停机+回滚预案） | 高 |
ALTER TABLE在MySQL中可能会锁表（取决于操作类型和版本）。一张500万行的表，ADD COLUMN可能需要几分钟到几十分钟。如果是MODIFY COLUMN改变类型，可能重建整个表，耗时以小时计。
建议：上线前用pt-online-schema-change或gh-ost等工具做在线DDL，避免锁表。
五、表结构设计的自查清单
上线前确认以下几点：
- □ 字段类型是否选择了最小可用类型（
VARCHAR(11)而不是VARCHAR(255)） - □ 字符集是否合理（不需要emoji就用
utf8mb3） - □ 索引长度是否超过3072字节限制
- □ 大量
NULL值的列是否可以用默认值代替 - □ 时间字段是否考虑了时区问题
- □ 上线后的
ALTER TABLE操作是否规划了在线DDL方案
总结
表结构设计的错误，后期几乎无法低成本修复。字段类型选错、字符集设置不当、大量NULL值——这些问题在参数调优和索引优化层面都解决不了。
设计阶段多花1小时思考字段类型，上线后少加10小时的班。 把表结构设计的检查清单放进开发流程里，从源头卡住性能问题。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
