复合索引应按等值查询字段（高频优先）、范围查询字段（仅一个）、ORDER BY字段（方向一致）顺序建立；SELECT *会强制回表降低性能；OR条件易使索引失效，宜改写为UNION；分区表中分区键应置于复合索引最左列。复合索引该按什么顺序建？顺序直接决定查询能否命中索引------MySQL/PostgreSQL 的 B-Tree 索引是左前缀匹配的，WHERE a = 1 AND b = 2 AND c > 3 能用上 (a, b, c)，但换作 (b, a, c) 就只能用上第一个字段 b（如果没其他条件），a 和 c 就失效了。实操建议：把等值查询字段（=、IN）放最左边，且高频字段优先范围查询字段（>、BETWEEN、LIKE 'abc%'）紧接其后，且只能有一个------再往后字段无法被索引利用ORDER BY 字段可追加在末尾，但仅当排序方向一致（全 ASC 或全 DESC）且无混合时才有效避免把 SELECT 中的计算字段（如 UPPER(name)）或函数结果作为索引首列，否则无法走索引SELECT * 会拖垮多维查询性能吗？会，尤其在宽表+复合索引场景下。索引本身可能覆盖查询（Covering Index），但 SELECT * 强制回表------即使所有 WHERE 条件都命中索引，仍要根据主键去聚簇索引捞出所有字段，IO 成倍增加。实操建议：只查真正需要的字段，比如 SELECT user_id, status, created_at，而非 SELECT *若常查固定几列，考虑把它们全包含进复合索引末尾（叫"索引覆盖"），例如索引 (tenant_id, status, created_at, user_id) 可让 SELECT user_id, created_at FROM t WHERE tenant_id = ? AND status = ? 完全免回表注意大字段（TEXT、JSON、长 VARCHAR）哪怕没选，只要在表结构里，回表时仍要读取整行，影响依然存在WHERE 中用了 OR，复合索引还有效吗？大概率失效。比如 WHERE a = 1 OR b = 2，即使有 (a, b) 索引，优化器通常放弃走索引，改用全表扫描------因为 OR 拆解后是两个独立范围，B-Tree 不支持高效合并。 ARTi.PiCS ARTi.PiCS是一款由AI驱动的虚拟头像生产器，可以生成200多个不同风格的酷炫虚拟头像
相关推荐
兵慌码乱6 小时前
基于 MediaPipe 与 PySide2 的手势交互音乐控制系统实现：轻量化视觉交互全流程解析luckdewei9 小时前
FastAPI 资产管理系统实战：复杂 ORM 关联、Alembic 迁移与 N+1 查询优化aqi0015 小时前
15天学会AI应用开发（八）使用向量数据库实现RAG功能Csvn16 小时前
`functools.lru_cache` —— 一行代码搞定缓存加速金銀銅鐵1 天前
[Python] 从《千字文》中随机挑选汉字cup112 天前
[技术复盘] Windows Python 打包实战：Nuitka 环境踩坑总结与 CI 自动化构建全指南aqi002 天前
15天学会AI应用开发（七）有了大模型为什么还要引入RAG金銀銅鐵2 天前
用 Python 实现 Take-Away 游戏