SQL

在 Go 后端开发中，我们通常使用 MySQL 或 PostgreSQL 等关系型数据库，索引设计的好坏直接决定了服务接口的响应速度。 1.索引设计 1.1 选择合适的列作为索引： 选择性高（High Selectivity）： 索引列的不重复值越多越好。例如，用户 ID（唯一）比性别（只有两三种值）更适合作为索引。 场景： 在设计用户服务时，user_id、email 等是理想的索引列。 常用作查询条件（Where）： 经常出现在 WHERE 子句中的列，或者用于连接（JOIN）的列。 排序/分组（Order By/Group By）： 经常用于排序或分组的列。 1.2 考虑联合索引（Composite Index）： 最左前缀原则 (Leftmost Prefix Principle)： 这是联合索引设计的核心。如果创建了 (A, B, C) 的联合索引，它可以用于查询 WHERE A = ?、WHERE A = ? AND B = ?、WHERE A = ? AND B = ? AND C = ?，但不能单独用于 WHERE B = ? 或 WHERE C = ?。 场景： 在设计订单查询接口时，如果经常查询 WHERE user_id = ? AND order_status = ?，应建立 (user_id, order_status) 的联合索引。 1.3 覆盖索引 (Covering Index)： 如果查询的所有字段都包含在索引中，那么数据库不需要回表（查找主键对应的数据行），直接从索引中返回数据即可。这能大幅提升性能。 场景： 当你需要查询某个用户的订单状态和创建时间，只创建 (user_id, status, create_time) 的联合索引。查询语句为 SELECT status, create_time FROM orders WHERE user_id = ?，数据库直接通过索引就能拿到结果。 1.4 索引数量的平衡： 索引不是越多越好。每个索引都会占用磁盘空间，并且在进行 INSERT, UPDATE, DELETE 操作时，数据库需要维护索引，造成写操作性能下降。 场景： 在设计高写入量的日志表或消息表时，应尽量少建索引，只保留用于最核心查询的索引。 2.高效命中策略 使用 Explain ： 在 Go 后端进行复杂查询优化时，一定要在测试环境使用 EXPLAIN 命令分析 SQL 语句，确保 type 列不是 ALL（全表扫描），key 列使用了正确的索引。 ...