避免在WHERE条件中对字段使用函数，因其破坏索引有效性导致全表扫描；应重写查询以直接比较字段值，如用create_time >= '2025-01-01'替代YEAR(create_time) = 2025。
SQL 函数使用导致性能变慢，通常是因为函数改变了字段的可索引性或增加了计算开销。要解决这个问题，关键是理解函数如何影响执行计划，并采取优化手段。
避免在 WHERE 条件中对字段使用函数
当在 WHE
RE 子句中对列使用函数时，数据库无法直接使用索引，会导致全表扫描。
SELECT * FROM users WHERE YEAR(create_time) = 2025; -- 慢
改为：
SELECT * FROM users WHERE create_time >= '2025-01-01' AND create_time
通过重写条件，让数据库能利用 create_time 上的索引。
慎用字符串函数处理大字段
SUBSTR、CONCAT、REPLACE 等字符串函数在大数据量下会显著拖慢查询。
- 尽量不在 SELECT 中对大文本字段做处理，尤其是日志、内容类字段
- 若必须处理，考虑提前在应用层或通过物化视图预计算
- 避免在 JOIN 或 WHERE 中使用如 UPPER(name) = 'ABC'，应统一存储格式或使用索引友好的方式
聚合函数与 GROUP BY 优化
COUNT、SUM、AVG 等函数本身不慢，但数据源大且未优化时会成为瓶颈。
- 确保 GROUP BY 的字段有索引
- 避免对无索引字段做聚合，特别是高基数列
- 考虑使用汇总表或定时统计替代实时计算
使用函数索引（如果数据库支持）
某些数据库如 PostgreSQL、Oracle、MySQL 8.0+ 支持函数索引，可以为表达式创建索引。
例如：CREATE INDEX idx_upper_name ON users (UPPER(name));
这样 WHERE UPPER(name) = 'JOHN' 就能走索引。
但注意维护成本，只对高频查询创建。
基本上就这些。关键是在写 SQL 时时刻想着索引能否生效，尽量让函数远离数据库字段的直接操作，优先从设计和结构上减少运行时计算。性能问题多数出在“实时计算 + 全表扫描”的组合上，拆开它就能提速。
