对索引列使用函数会导致索引失效，因破坏b+树有序性；应将函数移至等号右侧或改用范围查询，如where name = upper('john')或where created_at >= '2024-01-01' and created_at

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 则直接报错或拒绝隐式转换（取决于配置）。

实操建议：

• 参数类型必须和字段类型严格一致：应用层传参时别用字符串拼接数字 ID，用预编译参数绑定
• 检查执行计划：MySQL 用 EXPLAIN 看 type 是否为 const/ref，而非 ALL 或 index；PostgreSQL 用 EXPLAIN ANALYZE 看是否出现 Seq Scan
• 字符串字段用 COLLATE 显式声明排序规则，避免因连接字符集不同引发隐式转换

批量 UPDATE 没控制范围容易锁表或超时

一条 UPDATE orders SET status = 'shipped' WHERE created_at 如果匹配百万行，在未加 LIMIT 或未分批次时，可能持有行锁/间隙锁过久，阻塞其他事务，甚至触发锁等待超时（<code>Lock wait timeout exceeded）。

实操建议：

• 永远带 LIMIT + 循环更新：先 SELECT id FROM orders WHERE created_at ，再用这批 <code>id 做 UPDATE ... WHERE id IN (...)
• WHERE 条件尽量走主键或唯一索引：避免全表扫描式更新，否则 LIMIT 也救不了性能
• 在低峰期执行，同时设置会话级超时：SET innodb_lock_wait_timeout = 10（MySQL），防止一个长事务拖垮整个库

最常被忽略的是：开发阶段用小数据量测不出问题，上线后数据量一上去，函数索引失效、隐式转换、批量锁表就全冒出来——不是 SQL 写错了，是它在生产环境根本没走你预期的索引路径。