【干货】数据库设计优化技巧，性能提升10倍

一、表结构设计：从源头减少性能隐患

选对数据类型是成本最低、收益最高的优化。能用 TINYINT 就别用 INT，能用 VARCHAR(50) 就别用 VARCHAR(255)，日期字段用 DATE/DATETIME 而非字符串存储。字段越短，索引越小，I/O 越少。

主键优先用自增整数，避免 UUID 或长字符串做主键。InnoDB 的主键会存在于所有二级索引中，主键过大意味着所有索引都变胖。

范式与反范式的平衡：初期按第三范式设计保证一致性;高频查询路径上适度冗余字段(如订单表冗余用户名)，用空间换时间，减少联表。

大表提前规划分区：按时间范围分区日志表、订单表，查询时自动裁剪分区，扫描数据量直接下降一个数量级。

二、索引设计：性能提升的核心杠杆

最左前缀原则必须牢记。复合索引 (a, b, c) 能覆盖 a、(a,b)、(a,b,c) 的查询，但跳过 a 直接查 b 就失效了。

高选择性列放前面。用户 ID 比性别更适合放在复合索引的前列，区分度越高，索引过滤效率越好。

善用覆盖索引。让索引包含查询所需的所有字段，避免回表查主键索引。例如查询 SELECT id, name FROM users WHERE status = 1，建 (status, id, name) 复合索引即可完全在索引内完成。

索引不是越多越好。每个索引都会拖慢写操作。定期用慢查询日志和 EXPLAIN 审查索引使用情况，删除冗余索引。

警惕索引失效场景：对索引列使用函数(如 WHERE YEAR(create_time) = 2023)、隐式类型转换、LIKE '%keyword' 前置通配符、OR 条件中含非索引列——这些都会让索引形同虚设。

三、SQL 编写：别让烂查询拖垮好设计

禁止 SELECT *，只查需要的列，减少 I/O 和网络传输。

用 JOIN 代替子查询，MySQL 对子查询的优化能力有限，JOIN 更容易被优化器高效处理。

深分页用游标替代 OFFSET：WHERE id > last_id LIMIT 20 比 LIMIT 100000, 20 快几个数量级。

批量操作代替循环单条：批量 INSERT 单次 500-1000 条，减少网络往返和事务开销。

每条慢 SQL 都用 EXPLAIN 分析，关注 type(是否全表扫描)、key(是否用到索引)、rows(扫描行数)、Extra(是否 filesort 或 using temporary)。

四、架构与运维：让系统扛住增长

缓存层：热点数据用 Redis 缓存，采用 Cache-Aside 模式，设置合理 TTL，防范缓存穿透、击穿、雪崩。

读写分离：主库负责写，从库分担读流量。注意主从延迟问题，强一致性场景仍走主库。

分库分表作为最后手段：单表超过千万行再考虑。水平分表按用户 ID 哈希或时间范围路由，配合全局唯一 ID 生成策略。

定期维护：开启慢查询日志、定期 ANALYZE TABLE 更新统计信息、重建碎片化索引、归档历史数据。

五、优化优先级建议

按"投入产出比"排序：

加索引 / 改索引 → 几分钟见效

改写慢 SQL → 几小时见效

调整表结构/数据类型 → 需要改表，但收益持久

加缓存 → 架构改动，读性能飞跃

分库分表 → 最后手段，复杂度最高