SQL更新语句性能调优技巧_避免对索引列执行函数操作

对索引列使用函数会导致索引失效，因破坏B+树有序性；应将函数移至等号右侧或改用范围查询，如WHERE name = UPPER('john')或WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'。WHERE 条件里对索引列用函数会直接让索引失效MySQL、PostgreSQL、SQL Server 都一样：WHERE UPPER(name) = 'JOHN' 或 WHERE DATE(created_at) = '2024-01-01' 这类写法，即使 name 或 created_at 有索引，优化器也大概率放弃使用。因为函数改变了原始值的有序性，B+ 树无法做范围跳查。实操建议：把函数移到等号右边：用 WHERE name = UPPER('john') 替代 UPPER(name) = 'JOHN'（前提是大小写不敏感 collation）日期范围改用闭区间：用 WHERE created_at >= '2024-01-01' AND created_at 替代 <code>DATE(created_at) = '2024-01-01'实在要函数转换，考虑生成列 + 索引：PostgreSQL 支持 CREATE INDEX ON t ((UPPER(name)))；MySQL 5.7+ 可建函数索引列 ALTER TABLE t ADD COLUMN name_upper VARCHAR(64) STORED AS (UPPER(name))，再给该列加索引UPDATE 语句中 SET 子句对索引列赋值可能触发额外索引维护比如 UPDATE users SET status = 'active', updated_at = NOW() WHERE id = 123，如果 updated_at 是二级索引的一部分（比如复合索引 (status, updated_at)），每次更新都会导致该索引页分裂或重排，尤其在高并发写场景下明显拖慢性能。实操建议：避免在 SET 中无谓更新索引列：确认字段值是否真有变化，可用 WHERE status != 'active' AND id = 123 提前过滤把高频更新字段和低频查询字段拆到不同索引中：别把 updated_at 和常用于 WHERE 的 status 绑死在一个复合索引里对时间戳字段，优先用 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 自动更新，减少 SQL 层显式赋值WHERE 条件含隐式类型转换也会绕过索引典型错误：WHERE user_id = '123'，而 user_id 是 INT 类型。MySQL 会把所有 user_id 值转成字符串比对，索引失效；PostgreSQL 则直接报错或拒绝隐式转换（取决于配置）。 唱鸭 音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体