在关系型数据库的日常调优中，表达式计算的CPU消耗常常被忽视。很多慢查询并非源于全表扫描本身，而是因为优化器不得不在每一行上重复执行函数调用、类型转换或算术运算。理解这些表达式在执行引擎中的真实开销，才能有针对性地改写SQL、设计索引并控制资源使用。
一、表达式在计算引擎中的执行位置
数据库在执行一条SQL时，会先生成逻辑执行计划，再转化为物理执行计划。表达式通常出现在投影（SELECT列表）、过滤（WHERE、HAVING）以及连接条件中。对于每一行候选数据，执行引擎都会调用对应的表达式求值器。如果表达式不可折叠为常量，就无法在编译期完成，只能推迟到运行时逐行计算。
以常见的MySQL为例，其执行器在Item类中封装了各种表达式节点。每次eval()调用都会触发子节点求值、类型转换与函数逻辑。当数据量达到百万级，这种逐行调用的累积成本会直接体现在CPU使用率上。因此，评估成本的第一步是确认表达式是否出现在“每行必算”的位置。
1.1 常量折叠与运行时计算
如果表达式只涉及常量和确定性函数，优化器通常会在准备阶段完成常量折叠。例如 WHERE create_time >= DATE('2023-01-01') + INTERVAL 1 DAY 中的日期计算只做一次。但若写成 WHERE DATE(create_time) = '2023-01-02'，则函数作用在列上，必须逐行执行。
我们可以通过EXPLAIN观察是否使用了索引，以及rows估算是否过大。当表达式阻断索引时，扫描行数近似全表，CPU消耗自然陡增。下面是一段演示常量折叠差异的伪代码：
-- 可折叠：优化器提前算好比较值 SELECT * FROM orders WHERE amount > 100 * 1.1; -- 不可折叠：每行计算函数 SELECT * FROM orders WHERE ROUND(amount, 0) > 110;
二、常见高成本表达式类型
并不是所有表达式的CPU代价都相同。一般来说，类型隐式转换、字符串函数、正则表达式以及用户自定义函数（UDF）属于高成本操作。它们不仅计算慢，还可能阻止向量化执行或批量迭代优化。
下面用一张表归纳几类典型表达式及其相对开销，帮助我们在写SQL时快速判断风险点。
| 表达式类别 | 示例 | CPU相对成本 | 是否阻断索引 |
|---|---|---|---|
| 算术运算 | price * quantity | 低 | 否（若列独立） |
| 类型转换 | CAST(varchar_col AS INT) | 中 | 是 |
| 字符串函数 | SUBSTRING(name, 1, 3) | 高 | 是 |
| 正则匹配 | col REGEXP '^a.*z$' | 很高 | 是 |
| 自定义函数 | my_udf(score) | 视实现而定 | 通常否 |
2.1 隐式转换的隐形代价
当比较双方类型不一致，数据库会插入转换函数。比如在MySQL中，若字符列与数字比较，会将列转为浮点，导致全表扫描。这种写法在开发时不易察觉，却在运行时吞噬CPU。
我们可以通过统一参数类型来避免。以下代码展示问题写法与修正写法：
-- 问题：varchar列与数字比较，触发隐式转换 SELECT * FROM user WHERE phone = 13800000000; -- 修正：使用字符串字面量 SELECT * FROM user WHERE phone = '13800000000';
2.2 函数包裹列的典型反模式
把列塞进函数再过滤，是阻断索引的常见原因。优化器无法从B+树中定位函数值范围，只能读取每行计算。对于大表，这等同于把CPU压力拉满。
替代方案是改写范围条件或增加生成列并建索引。示例如下：
-- 反模式 SELECT * FROM log WHERE DATE_FORMAT(created_at, '%Y-%m-%d') = '2023-01-01'; -- 改写：范围扫描 SELECT * FROM log WHERE created_at >= '2023-01-01 00:00:00' AND created_at < '2023-01-02 00:00:00';
三、用执行计划与性能视图量化消耗
光靠经验不够，我们需要借助数据库自带工具量化表达式成本。PostgreSQL的EXPLAIN (ANALYZE, BUFFERS)能显示实际执行时间与缓冲区命中；MySQL的performance_schema可统计语句CPU时间；SQL Server则有执行计划中的“表达式”开销百分比。
实践中，我们可以先跑基准查询，记录CPU时间，再逐步去掉或下移表达式，对比差异。如下是PostgreSQL中观察函数的示例：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE lower(customer_email) = 'test@ipipp.com';
输出中的“actual time”包含了表达式求值耗时。若过滤行数多但命中索引少，说明函数计算成了瓶颈。此时应考虑建立表达式索引：
CREATE INDEX idx_lower_email ON orders (lower(customer_email));
3.1 表达式索引的权衡
表达式索引能把逐行计算前置到写入期，换取读取时的索引查找。但它会占用存储空间，并拖慢INSERT、UPDATE。是否采用，要看读写比与查询频率。
如果业务只在报表批处理中用到重计算，就不必建索引，而是把表达式放到物化视图里。这样在线事务不受影响，分析查询直接读结果。
四、编写低CPU消耗的SQL建议
总结前文，控制表达式CPU成本的核心原则只有几条：让表达式脱离列、利用常量折叠、用索引覆盖计算、必要时前置计算。具体落地时，可以遵守以下清单。
- 过滤条件左侧不要包裹列函数，改为范围或等价常量。
- 参数类型与列定义保持一致，消除隐式转换。
- 高频复杂表达式建立生成列或表达式索引。
- 用
EXPLAIN ANALYZE类工具验证改写效果。 - 批量计算尽量下推到数据库端，减少应用层循环调用。
当我们把一条WHERE fn(col) = const重写成col BETWEEN a AND b，往往能看见CPU曲线明显回落。这种改写不需要额外硬件，只依赖对表达式求值机制的理解。
4.1 一个综合改写示例
假设有这样一条查询，对时间戳取小时再统计：
SELECT HOUR(created_at) AS h, COUNT(*) FROM event WHERE HOUR(created_at) >= 9 AND HOUR(created_at) < 18 GROUP BY HOUR(created_at);
它在WHERE和SELECT中都调用了HOUR，且过滤阻断索引。若改为范围过滤并保留投影函数，成本会下降：
SELECT HOUR(created_at) AS h, COUNT(*) FROM event WHERE created_at >= '2023-01-01 09:00:00' AND created_at < '2023-01-01 18:00:00' GROUP BY HOUR(created_at);
这样数据库可用索引定位时间段，只在少数行上计算小时，CPU消耗随之降低。评估表达式成本并不是玄学，而是结合执行计划、类型系统与索引结构的系统工程。
SQLexpression_evaluationCPU_cost修改时间：2026-08-05 13:10:21