where子句中对字段使用函数（如year(create_time)=2023）会导致数据库无法使用索引而全表扫描；应改用范围查询，如create_time>=’2023-01-01′ and create_time
WHERE 子句里用函数导致全表扫描
数据库没法走索引，是因为你在 WHERE 里对字段用了函数，比如 WHERE YEAR(create_time) = 2023。mysql 和 postgresql 都会放弃索引，直接扫全表。
改成范围查询更安全：
WHERE create_time >= '2023-01-01' AND create_time- 如果必须按月查，用
DATE_FORMAT(create_time, '%Y-%m')要谨慎——它同样不走索引；优先考虑生成日期维度表或加计算列+索引 - PostgreSQL 可以建函数索引：
CREATE INDEX idx_create_year ON orders ((EXTRACT(YEAR FROM create_time)))，但 MySQL 8.0+ 才支持类似功能（虚拟列+索引）
JOIN 多张表时顺序影响执行计划
SQL 不是线性执行的，优化器会重排 JOIN 顺序，但它的判断依赖统计信息是否准确、小表是否真“小”。你写的 FROM a JOIN b JOIN c 不代表实际执行顺序。
实操建议：
- 用
EXPLAIN看rows和type字段：如果某张表显示ALL且rows很大，说明没走好索引或被当成了驱动表 - 强制小表驱动大表：在 MySQL 中可加
STRAIGHT_JOIN（仅限 INNER JOIN），但得先确认小表确实够小（比如users表只有几百行，而orders有千万级） - 避免
select *在多表 JOIN 中出现——字段越多，临时表越重，尤其涉及GROUP BY或ORDER BY时容易触发磁盘临时表
窗口函数替代自关联 / 子查询
想查“每个用户最新一笔订单”，老写法是 SELECT * FROM orders o1 WHERE order_time = (SELECT MAX(order_time) FROM orders o2 WHERE o2.user_id = o1.user_id)，性能差还容易出错。
窗口函数更稳：
-
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)是最常用的选择，注意PARTITION BY字段必须有索引支撑 - PostgreSQL 和 MySQL 8.0+ 支持，但 sqlite 3.25+ 才开始支持，旧版本别硬上
- 别在
WHERE里直接过滤窗口函数结果（比如WHERE rn = 1），得套一层子查询或 CTE，否则报错：Window function is not allowed in WHERE clause
IN 列表超 1000 项触发性能断崖
oracle 明确限制 IN 最多 1000 个值，MySQL 和 PostgreSQL 虽无硬限制，但传入几千个 ID 会导致解析慢、执行计划失准、甚至内存溢出。
更靠谱的做法：
- 拆成多个
IN查询，每批 500 项以内，用应用层合并结果 - 把 ID 列表写进临时表（
CREATE TEMPORARY table tmp_ids (id BIGINT PRIMARY KEY)），然后JOIN，适合单次大批量场景 - 用
VALUES ROW构造集（PostgreSQL）或union ALL拼接（MySQL），比长IN更易缓存执行计划
复杂点往往不在语法多难，而在统计信息不准、索引缺失、或者你以为的“小数据”其实在数据库眼里已经算大了。