SQL效率提升应先确保查询语句规范：避免SELECT *，明确指定所需字段；WHERE条件需适配索引，禁用函数和前导模糊匹配；分页优先用游标而非OFFSET。
SQL基础查询写得对，效率才可能高。别一上来就堆索引或改执行计划，先确保语句本身干净、意图清晰、不走弯路。
查什么，就写什么：避免 SELECT *
用 SELECT * 看着省事，实际是性能隐患。数据库要读取所有字段，网络多传数据，内存多缓存，如果表有大文本或JSON字段，影响更明显。
- 只写需要的列，比如 SELECT user_id, name, email FROM users
- 连表时注意别漏了表前缀，避免字段名冲突，如 SELECT u.id, o.order_no FROM users u JOIN orders o ON u.id = o.user_id
- 临时查数据调试可以用 *，但上线前务必改掉
WHERE 条件要能走索引
索引不是建了就生效，关键看 WHERE 里怎么写。函数、类型转换、模糊前导通配符（LIKE '%abc'）都会让索引失效。
- 优先用等值条件：WHERE status = 'active'
- 范围查询放后面：WHERE dept_id = 5 AND create_time > '2024-01-01'（假设联合索引是 (dept_id, create_time)）
- 避免在字段上做运算：WHERE YEAR(create_time) = 2024 → 改成 WHERE create_time >= '2024-01-01' AND create_time
少用子查询，优先考虑 JOIN 或 EXISTS
相关子查询（尤其是 WHERE 中的 IN (SELECT ...)）容易引发重复执行，数据量一大就卡。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 把 WHERE id IN (SELECT user_id FROM logs WHERE type = 'login') 换成 JOIN logs l ON u.id = l.user_id AND l.type = 'login'
- 判断是否存在，用 EXISTS 通常比 IN 更快，因为找到一条就停：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
- 非相关子查询可以保留，但建议拆成 CTE 或临时表提升可读性
分页别用 OFFSET 越翻越慢
LIMIT 10 OFFSET 10000 这种写法，数据库仍要扫前 10010 行，只是丢掉前 10000。数据量大时延迟飙升。
- 用游标分页（cursor-based pagination）：记录上一页最后一条的排序字段值，例如 WHERE id > 12345 ORDER BY id LIMIT 10
- 真要用 OFFSET，确保 ORDER BY 字段有索引，且尽量控制总页数（比如限制最多查到第 200 页）
- 后台管理类场景若必须跳页，可加缓存或预计算总数+分页摘要
基本上就这些。SQL 效率不靠黑科技，而在于写得克制、看得懂、符合索引逻辑。先写对，再调优，别本末倒置。
