1. 大表数据查询优化
1.1 建立合适的索引
- 单列索引：针对查询条件的字段建立索引。
- 联合索引 ：针对多条件查询建立复合索引（注意索引的最左匹配原则）。
- 覆盖索引：查询字段全部在索引中，避免回表。
sql
CREATE INDEX idx_status_created ON orders(status, created_at);**1.2 避免 SELECT ***
- 只查询需要的字段，减少数据传输量。
sql
SELECT id, name FROM users WHERE status = 'active';1.3 分区 / 分表
- 分区表：按时间或范围分区，减少单次扫描数据量。
- 分表：按业务规则拆分成多个表，降低单表数据量。
1.4 读写分离
- 主库负责写，多个从库负责读，缓解查询压力。
1.5 缓存
- 使用 Redis / Memcached 缓存热点数据，减少数据库访问。
2. 超大分页处理
问题：
LIMIT offset, size 在 offset 很大时会扫描大量数据，性能很差。
优化方案 1：基于索引的"延迟关联"
sql
SELECT u.* FROM users u JOIN ( SELECT id FROM users WHERE status = 'active' ORDER BY id LIMIT 100000, 20 ) t ON u.id = t.id;原理：先用索引快速定位 ID，再回表取数据。
优化方案 2：基于主键的"游标分页"
sql
SELECT * FROM users WHERE id > 100000 ORDER BY id LIMIT 20;原理：记录上一次的最大 ID，下次直接从该 ID 往后查，避免扫描前面的数据。
优化方案 3：禁止深度分页
- 对超过一定页数的查询，提示用户缩小范围或使用条件过滤。
3. SQL 查询慢的优化思路
3.1 使用 EXPLAIN 分析执行计划
sql
EXPLAIN SELECT * FROM orders WHERE status = 'pending';重点关注：
- type （访问类型，越接近
const越好） - key（使用的索引）
- rows（扫描行数）
3.2 避免函数操作索引列
sql
-- 慢
WHERE DATE(created_at) = '2025-10-25'
-- 快
WHERE created_at >= '2025-10-25' AND created_at < '2025-10-26'3.3 避免 OR 导致索引失效
sql
-- 慢
WHERE status = 'active' OR type = 'vip'
-- 快（拆成两次查询或用 UNION）
SELECT ... WHERE status = 'active' UNION ALL SELECT ... WHERE type = 'vip';3.4 适当使用覆盖索引
sql
CREATE INDEX idx_status_id ON orders(status, id);
SELECT id FROM orders WHERE status = 'pending';4. 主键选择：自增 ID vs UUID
| 对比项 | 自增 ID | UUID |
|---|---|---|
| 存储空间 | 小（4~8字节） | 大（16字节） |
| 索引性能 | 高（顺序插入） | 低（随机插入，索引碎片多） |
| 可读性 | 简单递增 | 不可读 |
| 分布式唯一性 | 需额外方案（如雪花算法） | 天然唯一 |
| 安全性 | 可推测数据量 | 不易推测 |
建议：
- 单库单表 → 用自增 ID（性能好）
- 分布式、多节点写入 → 用雪花算法（Snowflake）或优化版 UUID（如 UUIDv7，时间有序）
- 不建议直接用随机 UUID 作为主键（索引性能差）
5. 总结优化策略
| 场景 | 优化方法 |
|---|---|
| 大表查询 | 索引优化、分区分表、缓存、读写分离 |
| 超大分页 | 延迟关联、游标分页、限制深度分页 |
| SQL 慢查询 | EXPLAIN 分析、避免函数操作索引列、避免 OR、覆盖索引 |
| 主键选择 | 单库用自增 ID，分布式用雪花算法或有序 UUID |