SQL查询变慢主因是写法、表结构与执行路径不合理；索引需匹配WHERE等实际使用条件，复合索引字段顺序要与查询条件一致，避免对索引字段用函数。
SQL大数据查询变慢，核心问题往往不在数据量本身，而在查询写法、表结构和执行路径是否合理。优化不是堆硬件，而是让数据库“少走弯路、快找数据”。
索引不是越多越好，而是要匹配查询条件
索引本质是快速定位数据的“目录”。但只有被WHERE、JOIN、ORDER BY、GROUP BY实际用上的列，才值得建索引。
- 复合索引要注意字段顺序：比如WHERE status = ? AND create_time > ?，适合建(status, create_time)索引；反过来就可能失效
- 避免对索引字段做函数操作：WHERE YEAR(create_time) = 2024会让索引失效，改用create_time >= '2024-01-01' AND create_time
- 区分“高基数”和“低基数”字段：性别、状态这类取值少的字段，单独建索引效果差，更适合配合其他字段组成复合索引
减少扫描数据量，从源头控制返回结果
数据库最耗时的操作之一是读取大量无关行。优化重点是“别查不该查的”。
- 明确指定字段，不用SELECT *：尤其当表有大文本、JSON或BLOB字段时，全字段读取会大幅增加IO和网络传输
- 尽早过滤：把WHERE条件尽量下推到子查询或JOIN前；用LIMIT分页时注意深分页问题（如OFFSET 1000000），可改用“游标分页”（基于上一页最大ID继续查）
- 避免隐式类型转换：比如WHERE user_id = '123'（user_id是INT），会导致索引失效，应保持类型一致
JOIN和子查询要谨慎，优先考虑逻辑拆解
多表关联容易引发笛卡尔积或临时表膨胀，尤其是大表之间没走索引JOIN时，性能断崖式下跌。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 确认JOIN字段都有索引，且类型、字符集完全一致（比如utf8mb4 vs utf8可能不走索引）
- 大表JOIN小表，确保小表在前（部分引擎如MySQL 5.7+优化器会自动调整，但显式控制更稳妥）
- 用EXISTS替代IN子查询处理存在性判断；用LEFT JOIN + IS NULL替代NOT IN（后者对NULL敏感，易出错且难优化）
- 超复杂查询可拆成中间临时表（如CREATE TEMPORARY TABLE）或物化CTE（PostgreSQL/Oracle支持），避免重复计算
善用执行计划，别靠猜
EXPLAIN（或EXPLAIN ANALYZE）是诊断查询性能的“听诊器”，它告诉你数据库实际怎么执行的。
- 重点关注type（是否用到索引：ALL最差，range/ ref/ eq_ref较好）、rows（预估扫描行数）、Extra（是否Using filesort、Using temporary——意味着排序/分组用了临时表）
- 对比加索引前后的执行计划变化，验证优化是否真正生效
- 生产环境慎用SELECT FOR UPDATE或长事务，它们会阻塞并影响并发查询性能
基本上就这些。SQL优化不是一招鲜，而是一套组合动作：建对索引、写对语句、看清执行路径、再结合业务场景做取舍。不复杂但容易忽略。
