做数据库的，谁没被慢查询折磨过？明明数据量不大，一个简单的用户列表页却要等五秒才刷出来，领导盯着屏幕，产品经理在旁边催着上线，那滋味真不好受。后来我才发现，很多性能问题并不是出在 SQL 语句上，而是表结构设计时埋下的坑。你想想，地基没打好，后面再怎么装修也是白费力气。今天把这些年踩坑后总结的几个原则掰开揉碎聊一聊，这些不是教科书上的理论，而是真金白银的实战经验，照着做，查询效率翻倍不是梦。
先说最基础但最容易被忽视的一点：字段类型选对了，性能就赢了一半。我曾接手过一个项目，用户表里的手机号字段用了 VARCHAR(255)，身份证号也是 VARCHAR(255)，甚至性别字段也用了 VARCHAR(20)。当时我就懵了，这又不是存大段文章，搞这么宽干什么？VARCHAR 虽然可以变长，但 MySQL 在内部处理时，对固定长度的字段会用更快的比较算法。比如手机号只有 11 位，你非要设成 255，每次查询都要多处理无意义的空白。更夸张的是，我看到一张日志表，时间字段居然用了 VARCHAR 存字符串，按日期范围查询时必须先转成时间戳，索引根本用不上。正确的做法很简单：能用 TINYINT 就别用 INT，能用 DATETIME 就别用 VARCHAR，手机号可以用 CHAR(11) 而不是 VARCHAR(255)。字段越窄，每页能存下的行数越多，内存命中率越高，查询自然更快。
索引设计是另一个大坑，很多人觉得索引越多越好，恨不得给每个字段都加一个。结果呢？写入慢得跟蜗牛一样，因为每次插入都要维护多个 B+ 树。我见过最离谱的一张表有三十多个字段，索引建了二十三个，生产环境一跑，插入一条数据要花两秒。正确的做法是遵循“最左前缀原则”，把查询最频繁、区分度最高的字段放在索引最左边。比如订单表，用户 ID 和订单状态经常一起查询，就建一个 (userid, status) 的联合索引，而不是分别给两个字段建单列索引。还有一点容易被忽略：索引不是越多越好，而是越精准越好。那些从未出现在 WHERE 条件里的字段，别浪费空间去建索引。冗余索引有时会让优化器选错，反而更慢。建索引前，先打开慢查询日志跑几天，找出真正的瓶颈，再对症下药。
说到表关联，很多人喜欢用 JOIN 把七八张表揉在一起写一个超级大 SQL。表面上很酷，但性能往往一塌糊涂。我接手过一个报表系统，一个页面的数据需要关联五张表，最长的 SQL 写了三百多行。每次查询都要全表扫描好几张表，数据量一大就直接超时。后来我建议把大查询拆成多个小查询：先在主表上用索引快速定位出几千条 ID，然后用 IN 语句在其他表里批量取数据。你可能会觉得这样会多查几次数据库，网络开销会更大？其实不是，因为每个小查询都能用上索引，MySQL 对 IN 语句也做了优化，批量查询的效率远高于一个大 JOIN。更重要的是，这种拆分让业务逻辑更清晰，问题更容易定位。把一个复杂的 JOIN 拆成两个简单查询，性能往往能提升十倍以上。
分区表是个好东西，但很多人用错了场景。我见过有人把只有一万条数据的表也分成十个分区，结果每个分区只有千条数据，查询时仍要扫描所有分区，白白增加开销。分区的真正价值在于数据量巨大且具有明显的时间维度，比如日志表、订单表，按月份分区非常合适。查询上个月的订单时，MySQL 会自动跳过其他分区，只扫描一个分区，效率自然高。但要注意，分区键必须出现在查询条件里，否则优化器会全分区扫描，甚至比不分区更慢。而且分区表的运维成本不低，ALTER TABLE 在分区表上会很慢，数据迁移时容易踩坑。我的建议是：数据量不到千万级别，别碰分区表；到了千万级别，先考虑用索引优化，实在不行再考虑分区，并且分区粒度不要太细，季度或半年分一次就足够。
反范式设计是很多互联网公司常用的手段，但用不好就是灾难。所谓反范式，就是故意在表里存一些冗余字段，减少关联查询。比如在订单表里存用户姓名和商品名称，虽然违反了第三范式，但查询订单列表时就不需要再关联用户表和商品表。我见过一个电商系统，订单列表页原本要关联六张表，每次都要等两三秒。后来在订单表里冗余了用户昵称、商品标题、商品图片 URL 等字段，查询直接变成单表查询，毫秒级就出结果。当然，反范式也有代价：用户改了昵称，订单表里的冗余字段也得同步更新，否则数据不一致。所以反范式适合“读多写少”的场景——订单生成后很少修改，昵称变更也不影响历史订单展示。如果业务对一致性要求极高，比如金融系统，就应老老实实遵循范式设计，别贪图查询性能。
说说字段命名和字符集选择这些看似不起眼却很关键的地方。字段名别用驼峰，也别用中文拼音缩写，统一用小写加下划线，例如 username 而不是 userName 或 yhm。这样写 SQL 时不需要大小写切换，而且 MySQL 在 Linux 下对表名是大小写敏感的，统一小写能避免很多坑。字符集方面，能不用 utf8mb4 就别用，因为 mb4 每个字符占四个字节，索引效率比普通 utf8 低不少。如果表里确定没有 emoji 表情，用 utf8 就够。每个表都要加上 createtime 和 updatetime 字段，类型用 DATETIME 或 TIMESTAMP，这样排查问题时能快速定位数据变更时间。更重要的是一定要建主键，主键最好用自增整数。UUID 做主键看起来很美，但每次插入都要随机写磁盘，导致索引碎片严重，查询性能会逐渐下降。这些细节单个看都不起眼，但叠加起来，性能差距就会显现。
