SQL大数据查询加速核心是让数据库少算、算得准、读得快；关键在理解存储、执行路径与优化器逻辑，而非堆硬件。
SQL大数据查询加速，核心不在“写得快”，而在“让数据库少算、算得准、读得快”。关键不是堆硬件，而是理解数据怎么存、查询怎么走、优化器怎么想。
索引不是越多越好，而是要匹配查询模式
索引本质是有序的查找结构（如B+树），它加速WHERE、ORDER BY、JOIN ON等操作，但对SELECT *或LIKE '%abc'几乎无效。建索引前先看执行计划（EXPLAIN），确认是否真走索引；避免在低区分度字段（如性别、状态）上单独建索引；复合索引要注意列顺序——最左前缀原则必须遵守，比如(a,b,c)索引能加速WHERE a=1 AND b=2，但不能加速WHERE b=2。
减少数据扫描量，从源头控制返回行数
大数据慢，常常因为“查100万行只用10行”。几个实用做法：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 用具体字段代替*，避免传输和解析无用列
- 尽早加WHERE条件，别依赖应用层过滤
- 分页慎用OFFSET：OFFSET 1000000会强制扫描前100万行，改用WHERE id > last_id LIMIT 100游标分页
- 大表关联前，先用子查询或CTE把驱动表缩小，避免笛卡尔积式膨胀
执行计划是你的“SQL透视镜”，必须会读
运行EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+），重点关注几项：
- Rows Removed by Filter高？说明WHERE条件没走索引，或统计信息过期（记得ANALYZE table）
- Actual Total Time远大于Planning Time？说明执行本身慢，不是解析问题
- 出现Seq Scan或Full Table Scan？检查对应字段是否有合适索引
- 出现Hash Join但Buckets溢出到磁盘？说明内存不足或join键分布不均，可调work_mem
分区和物化视图：对付固定模式的大宽表
当单表超亿级且查询有强时间/地域/业务维度规律时：
- 范围分区（按日期）让查询自动剪枝，比如WHERE log_time >= '2024-01-01'只扫今年分区
- 列表分区（按地区/类型）适合枚举明确的字段，避免跨分区扫描
- 物化视图（或汇总表）把高频聚合结果预先算好，查询直接读快照，比实时GROUP BY快数倍——但需权衡数据新鲜度与性能
基本上就这些。不复杂，但容易忽略细节。真正提速，靠的是每次慢查都愿意看一眼执行计划，而不是换写法再试三次。
