兄弟，做后端的，谁没被 MySQL 慢查询坑过？前几天我和一个刚入行的朋友聊天，他一脸愁容地说，数据库里只有几十万条数据，一个简单的查询居然跑了两秒多。我问他字段怎么设计的，他一脸懵。这事儿太常见了，很多人觉得表建好了，往里灌数据就完事，根本没想过字段本身会拖后腿。其实，MySQL 优化的第一道门槛，往往不是索引，也不是 SQL 写法，而是字段本身。字段选得不对，后面再怎么调索引，效果都有限。就像盖楼，地基歪了，上面装修得再漂亮也没用。
先聊聊最基础的东西：字段类型。我见过太多开发把所有字符串都塞进 VARCHAR(255)，管它是手机号还是文章标题。这看似省事，但坑在后头。VARCHAR 虽然是变长的，但一旦设成 255，MySQL 在排序和临时表操作时会预留这么多空间。实际上，手机号用 CHAR(11)就够了，固定长度查询更快。性别这种字段，用 TINYINT 或者 ENUM，别用 VARCHAR。还有日期，很多人图省事存成字符串，结果要按时间排序时，MySQL 必须先把字符串转成日期，性能直接崩。DATETIME 和 TIMESTAMP 才是正经选择，TIMESTAMP 还能省空间，4 个字节搞定，而 DATETIME 要 8 个。这些细节，单看一个字段可能就省几十毫秒，但当表有几十个字段、上千万数据时，这些毫秒叠起来就是灾难。
再说说字段长度的选择。很多人有个误区：怕数据太长，就把长度设得很大。VARCHAR(255) 和 VARCHAR(500) 在存储上确实只占实际长度加 1‑2 个字节，但 MySQL 在内存排序或创建临时表时，会按定义的长度分配空间。设成 500，就会按 500 来算，结果内存占用翻倍，SQL 跑着跑着就会爆临时表。另一个常见的坑是 DECIMAL 和 FLOAT。存金额这种需要精确的数据，千万别用 FLOAT，浮点数有精度问题，算着算着就会差 0.01。DECIMAL(10,2) 虽然慢一点，但稳。像用户 ID 这种整型，用 INT 就够了，别用 BIGINT，除非你真的有几十亿用户。INT 占 4 字节，BIGINT 占 8 字节，一个字段多 4 字节，1000 万条数据就多出 40 MB，这还只是单字段，表里有 10 个这样的字段，那就是 400 MB 的冗余，磁盘和内存都受罪。
还有一点，很多人忽略：字段是否允许 NULL。默认情况下 MySQL 允许字段为 NULL，但这会影响性能。因为 NULL 值的处理比 NOT NULL 复杂，索引里需要额外标记，排序和分组时也要特殊处理。比如有个字段叫 age，允许 NULL，查询 时，MySQL 必须先把 NULL 过滤掉，多一步操作。更坑的是，NULL 在 COUNT 中不计数，如果你用 统计非空值的数量，结果可能和预期不符。所以，能设 NOT NULL 就设 NOT NULL，默认值给个 0 或空字符串，既省事又提升性能。我见过一个表，十几个字段都允许 NULL，结果一次全表扫描比正常情况慢了 30%，改成 NOT NULL 后，速度直接起飞。
聊到字段优化，离不开范式化和反范式化的取舍。很多人上学时学了第三范式，就死守它，觉得字段冗余是原罪。可现实中，过度范式化会导致大量 JOIN 查询，性能反而更差。举个例子：订单表里只存用户 ID，每次查询订单都要 JOIN 用户表拿用户名。如果在订单表里直接冗余一个 字段，虽然违反了范式，但查询时少了一次 JOIN，速度提升明显。反范式化也不是无脑加字段，需要考虑写操作的频率和数据一致性的要求。如果这个冗余字段每天只更新一次，而查询每秒跑几百次，那完全值得。但如果是实时性要求高的场景，比如余额，冗余字段会导致更新麻烦，这时候就别搞了。
再说个实战细节：字段的字符集和排序规则。很多人建表时直接使用默认的 latin1 或 utf8mb4，根本不管业务场景。比如做中文站，用 utf8mb4 没错，但如果选择 和 ，性能差别不大；如果需要精准排序（如中文拼音），就得用 。更关键的是，如果表里同时出现 utf8 和 utf8mb4 的字段，MySQL 在 JOIN 时必须做字符集转换，性能会直接下降。因此，同一个库里的表尽量统一字符集，别混着用。我见过一个项目，订单表用 utf8，用户表用 utf8mb4，结果一次普通的 JOIN 查询跑了 3 秒，统一字符集后降到 0.1 秒，这种坑踩得太冤了。
字段优化不是一次性的事，需要持续关注。业务在变，数据量在涨，当初设计的字段可能已经不合适。比如某个字段最初存的是短文本，后来变成了长篇大论， 不够用了，改字段类型时会触发索引重建，影响线上性能。所以建表时要留有余地，例如预计最多 100 个字符的字段，设成 就行，别设成 255，也不要硬设成 100，万一需求变了，改起来麻烦。还有那些很久没用的字段，比如日志表里的 ，大部分行都是 NULL 或空字符串，不如直接删掉，或者拆到附属表，减少主表宽度。MySQL 读取数据是按行读取的，字段越多，单行数据越大，IO 压力越大。保持表结构精简，是永不过时的原则。
说到底，MySQL 字段优化不是什么高深技术，而是细节堆砌的耐心活。花半小时设计好字段，比后面花几天调索引和 SQL 要划算得多。别想着“先上线再说”，等到线上出问题，你就会体会到“一时偷懒，终身还债”。下次建表前，多问自己几个问题：这个类型合适吗？长度够用吗？能设 NOT NULL 吗？要不要冗余字段？字符集统一了吗？把这些问清楚，你的数据库至少能少挨一半的骂。
