SQL查询加速核心是懂数据、控访问、精写法：加对索引（按WHERE/JON/ORDER BY字段建复合索引）、减少数据搬运（避免SELECT*、尽早过滤、游标分页）、拆解逻辑（用临时表或物化视图）、选对引擎（MySQL适明细，ClickHouse/Doris适分析）。
SQL大数据查询加速，核心不是换工具，而是懂数据、控访问、精写法。真正卡顿的往往不是服务器性能，而是没走索引、全表扫描、重复计算或网络传输冗余。
加对索引：不是越多越好，而是查哪列建哪索引
索引是加速查询最直接有效的手段，但盲目建索引反而拖慢写入、浪费空间。关键看 WHERE、JOIN、ORDER BY、GROUP BY 中高频出现的字段。
- 复合索引要注意字段顺序：比如常查
WHERE status = 'done' AND create_time > '2024-01-01'，应建INDEX(status, create_time)，反过来效果差很多 - 避免对低区分度字段单独建索引（如 gender、is_deleted），除非配合其他高区分字段组成复合索引
- 用
EXPLAIN看执行计划，确认type是ref或range，而不是ALL（全表扫描）
减少数据搬运：能过滤就别让数据库传整行
大表查询慢，很多时候是因为把几百万行、每行几十KB的数据全拉到应用层再处理。应该让数据库只返回真正需要的字段和行数。
- 别写
SELECT *，明确列出字段，尤其避开大字段（如 text、json、blob） - 尽早用
WHERE过滤，而不是先 JOIN 再 WHERE；JOIN 前尽量用子查询或 CTE 先缩小左表/右表数据集 - 分页慎用
LIMIT offset, size：offset 越大越慢（MySQL 需跳过前 N 行）。改用“游标分页”：记录上一页最大 ID，下一页查WHERE id > last_id ORDER BY id LIMIT 50
拆解复杂逻辑：用临时表或物化中间结果
一个包含多层子查询、多次 GROUP BY 和窗口函数的大 SQL，执行时容易反复扫描、内存溢出。可把稳定中间结果存下来，再逐步加工。
- 例如统计“每个城市近30天下单用户数+复购率”，不要在一个 SQL 里嵌套 4 层子查询；先用
CREATE TEMPORARY TABLE tmp_orders AS SELECT ... WHERE order_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)，再基于 tmp_orders 计算 - 在支持物化视图的引擎（如 PostgreSQL、StarRocks、Doris）中，把高频聚合结果固化，查询直接读物化结果
- 对实时性要求不高的报表场景，可用定时任务预计算并写入汇总表（如 daily_city_stats），查询变秒级
选对引擎和数据布局：结构决定上限
MySQL 单表过千万行后，即使有索引也难扛高并发聚合查询；而列式引擎（如 Doris、ClickHouse）天生适合 OLAP 场景。
- 明细查询多、事务强（如订单详情页）→ 用 MySQL + 合理分库分表（按 user_id 或 order_no 取模）
- 分析类查询多（如“各渠道 ROI 趋势”）、数据量十亿+ → 换 ClickHouse 或 Doris，按时间分区 + 排序键（如 (dt, channel)）能实现亚秒响应
- 宽表预关联：把用户属性、商品类目等维度表提前 JOIN 到事实表，避免查询时多次 JOIN 大表（牺牲写入和存储，换查询速度）
基本上就这些。不复杂，但容易忽略。动手前先 EXPLAIN，查完再看执行计划里有没有 warning、key_len 是否合理、rows 是否远超预期——这才是加速的起点。
