优化 TiDB 复杂查询性能时，需要关注哪些点（比如索引设计、执行计划、统计信息）？有哪些常见的避坑操作？
一、核心关注要点
1. 索引设计：查询效率的基础
- 优先建联合索引，遵循 “前缀匹配” 原则，将过滤性强、查询频繁的字段放在前面。
- 避免过度索引，索引过多会拖慢写入速度，且优化器可能选错索引。
- 针对复杂查询的 WHERE 条件、JOIN 关联键、ORDER BY/GROUP BY 字段，针对性建索引，减少全表扫描。
2. 执行计划：验证查询路径是否最优
- 用
EXPLAIN ANALYZE查看执行计划，重点关注是否走索引、JOIN 方式（优先 Hash Join/Index Join，避免 Nested Loop Join 用于大表关联）。 - 检查是否存在 “全表扫描”“索引失效”“数据倾斜”（某节点处理大量数据），这些是性能瓶颈的主要来源。
- 关注算子顺序，优化器可能因统计信息不准导致 JOIN 表顺序错误，需手动调整（如
STRAIGHT_JOIN）。
3. 统计信息：优化器的 “决策依据”
- 确保统计信息最新，复杂查询依赖统计信息判断数据分布，可通过
ANALYZE TABLE手动更新（尤其大批量写入 / 更新后）。 - 避免统计信息失真，比如表中存在大量 NULL 值、数据分布极不均衡时，需调整统计信息采样率（
tidb_analyze_sample_rate）。
4. 其他关键关注项
- 数据分片：TiDB 按 Range 分片，复杂查询需避免跨过多分片（热点分片），可通过调整分片规则优化。
- 内存与并发：复杂查询（如大表关联、聚合）易占满内存，需合理设置
tidb_mem_quota_query（查询内存上限）、tidb_max_parallel_exec_instance（并行执行实例数）。
二、常见避坑操作
- 避免单表数据量过大：单表超过 10 亿行后，即使有索引，查询和维护成本也会剧增，需提前分表（如 TiDB 分区表）。
- 不滥用
SELECT *：只查询需要的字段，减少数据传输和内存占用，尤其大表查询。 - 规避复杂子查询 / 多层嵌套：子查询易导致优化器无法生成最优计划，可改写为 JOIN 或 CTE（
WITH子句）。 - 不忽视 JOIN 条件：JOIN 时必须指定关联键，避免笛卡尔积；大表关联需确保关联键有索引，且数据类型一致（避免隐式转换导致索引失效）。
- 避免
LIMIT偏移量过大：LIMIT 1000000, 10会扫描大量数据后丢弃，可通过主键 / 索引分页优化（如WHERE id > 1000000 LIMIT 10）。 - 不盲目关闭
TiDB优化特性：比如禁用 Hash Join、并行执行等，需先通过执行计划验证，再针对性调整。
三、补充优化技巧
- 对于超复杂查询，可拆分為多个简单查询，通过应用层聚合结果，降低单查询压力。
- 利用 TiDB 物化视图，预计算复杂聚合查询结果，加速读取（适用于报表、统计类查询）。
- 监控慢查询日志（
slow-query.log），定期分析高频慢查询，针对性优化索引或查询语句。
表结构，索引设计的科学性
1 索引设计
- 覆盖索引：尽量让查询只通过索引就能获取所需数据
- 复合索引：注意字段顺序，高频查询条件放前面
- 避免过度索引：索引会影响写入性能
- 前缀索引：对长字符串使用前缀索引节省空间
2 执行计划分析
- EXPLAIN ANALYZE：查看实际执行计划
- 关注算子：特别是 TableScan、IndexScan、HashJoin 等
- 预估行数：检查是否与实际行数偏差过大
- TiDB Dashboard：使用慢查询分析工具
3 统计信息
- 定期更新：
ANALYZE TABLE保持统计信息准确 - 采样率调整：对大数据表适当提高采样率
- 查看统计信息：
SHOW STATS_HEALTHY检查统计信息健康度
4 SQL 优化
- 避免全表扫描：确保 WHERE 条件能使用索引
- 合理使用 JOIN：注意 JOIN 顺序，小表驱动大表
- LIMIT 优化：分页查询时使用延迟关联
- 避免子查询：尽量改写为 JOIN
常见避坑操作
1 索引陷阱
不要在低基数列上建索引- 避免在函数表达式上使用索引
- 不要创建重复索引
2 查询陷阱
- 避免
SELECT *，只查询需要的字段 - 不要在 WHERE 条件中使用
!=、NOT IN等 - 避免在 WHERE 条件中对字段进行函数运算
3 配置陷阱
- 不要盲目调大
tidb_mem_quota_query - 避免过度并行，合理设置
tidb_build_stats_concurrency - 不要关闭统计信息自动收集
4 架构陷阱
- 避免单表数据量过大（建议不超过 100GB）
- 不要忽视热点问题，合理设计分区表
- 避免频繁的大事务
可以基于业务出发，进行业务逻辑优化，sql性能优化。
复杂查询，一看跑的快，二看跑的时间
还要看看结果集大小
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。