MySQL函数使用避坑指南：从索引失效到最佳实践

有一次排查一个运营后台的慢查询，页面要展示某段时间内的订单列表，开发同学写的条件是 WHERE YEAR(create_time)=2024 AND MONTH(create_time)=8。单看每个函数都没有问题，但数据量一上来，这条 SQL 直接全表扫描，页面卡了十几秒。后来把条件改成 create_time >= '2024-08-01 00:00:00' AND create_time < '2024-09-01 00:00:00'，毫秒级就返回了。

MySQL 函数难吗？常用函数的语法确实不难，真正难的是知道什么时候不该把函数套在索引字段上，以及函数在不同场景下会带来哪些隐形成本。这篇文章我把日常开发、报表统计、排障面试里遇到的 MySQL 函数相关经验做一个梳理，从字符串处理到数值转换，从日期函数到聚合、排序、窗口函数，最后再聊聊自定义函数和存储过程的边界。内容偏实战，新手能跟着用，老手也可以看看有没有自己忽略的细节。

1. 先分清“数据转换”和“查询过滤”：函数用在哪一步差别很大

1.1 一个慢查询引出的判断标准

同样是字符串截取函数 SUBSTRING，用在 SELECT 输出列里和用在 WHERE 过滤条件里，代价完全不同。输出列里做转换，数据量再大也只是多消耗一点 CPU，只要返回行数可控，一般不会造成灾难。但是一旦把函数套在过滤条件的索引字段上，优化器基本失去了利用索引定位的能力。

拿实际场景举例，日志表 access_log 里有上千万条记录，想在应用中统计某个来源渠道的访问量，错误写法很常见：

sql复制SELECT COUNT(*)
FROM access_log
WHERE SUBSTRING(source_code, 1, 3) = 'app';

这段 SQL 的逻辑没有错，但它必须把 source_code 的每一行都截取出来再比对，普通索引帮不上忙。正确做法是先想清楚过滤条件能不能转换成原始列的范围判断。如果业务上“以 app 开头的渠道”本身就是一个稳定规则，就应该在写入时增加 source_type 字段，或者至少把表达式改写为：

sql复制SELECT COUNT(*)
FROM access_log
WHERE source_code LIKE 'app%';

这里不是函数本身有问题，而是数据过滤的时机和位置没有设计好。我在评审 SQL 时基本就按三个层次判断：

• 输出阶段：对结果做格式化、拼接、截断，可以放心用函数。
• 转换阶段：在子查询或派生表中先处理好再参与关联，谨慎但可控。
• 过滤/排序阶段：如果函数包住了索引列，多数时候要重新设计。

1.2 为什么索引字段一旦套函数就容易失去索引能力

要理解这个问题，得回到索引的基本结构。MySQL 的二级索引本质上是把字段的原始值按顺序排好，再通过 B+ 树去定位。如果你写的是 WHERE order_no = 'A1001'，数据库可以直接在索引树里找 'A1001' 这个值。但如果你写的是 WHERE LEFT(order_no, 3) = 'A10'，数据库需要先算出每一行的 LEFT(order_no, 3) 结果，才能知道这一行是否匹配。这个“先算再比”的过程，打断了原本可以二分查找的路径，于是优化器只能放弃索引。

需要说明的是，MySQL 目前没有像 PostgreSQL 那种通用表达式索引。如果确实要按函数后的值来检索，有几个替代方案：

1. 新建一个字段，在业务写入时就把计算结果存下来，再对这个字段建索引。
2. 使用 MySQL 5.7 以后支持的生成列（generated column），在一张表里保存表达式结果，并允许在生成列上建索引。
3. 把函数放到等号右侧，把边界值提前算好传给 SQL，例如 WHERE create_time >= '2024-08-01' AND create_time < '2024-09-01' 而不是 WHERE MONTH(create_time) = 8。

1.3 函数真正擅长的场景：格式化、指标加工、数据清洗

说了很多“别乱用函数”的提醒，但函数本身是处理数据的利器，尤其是数据清洗和指标统计阶段。举例来说，从第三方渠道导出的手机号可能混着空格、横线、国家区号，用 REPLACE、TRIM、REGEXP_REPLACE 清洗后再入库，效率比在 Java、Python 里逐条处理高得多。再比如做月度报表，用日期函数把 create_time 转成 2024-08 这样的月份维度再分组，在输出阶段非常自然。

关键在于建立一种意识：函数是数据加工工具，不是过滤时偷懒的手段。 写 SQL 之前先问一句：这个过滤条件，我能不能不套函数就表达出来？如果绕不开，再考虑生成列或者冗余字段，而不是直接让数据库做全量计算。

2. 字符串函数：SUBSTRING、SUBSTRING_INDEX 与字符集坑

2.1 “sub_str 函数”到底该怎么写：SUBSTRING 和 SUBSTRING_INDEX 别混

不少新手会搜 sub_str 这种写法，实际上 MySQL 没有 SUB_STR 函数，常见的是 SUBSTR、SUBSTRING 和 SUBSTRING_INDEX。前两者是同一个函数，都可以从字符串中的指定位置开始截取一定长度的字符，例如：

sql复制SELECT SUBSTRING('2024-08-15', 1, 4);  -- 返回 2024
SELECT SUBSTR('2024-08-15', 6, 2);     -- 返回 08
SELECT SUBSTRING('2024-08-15', -5, 2); -- 从倒数第5位开始截2位，返回 08

注意一个细节：SUBSTRING 的位置参数按字符算，不是按字节算。这在处理中文的时候比较友好。例如 SUBSTRING('你好，世界', 1, 2) 返回“你好”，不会出现截出半个中文的情况。

SUBSTRING_INDEX 是按分隔符截取，用途完全不同。业务中经常用“身份证号”或“订单号”里提取某一段，典型写法是：

sql复制SELECT SUBSTRING_INDEX('浙江省-杭州市-西湖区', '-', 1);  -- 浙江省
SELECT SUBSTRING_INDEX('浙江省-杭州市-西湖区', '-', 2);  -- 浙江省-杭州市
SELECT SUBSTRING_INDEX('浙江省-杭州市-西湖区', '-', -1); -- 西湖区

如果要从 'a,b,c,d' 中取出第二段，不能直接 SUBSTRING_INDEX(str, ',', 2)，因为这会返回 a,b。需要使用嵌套写法：

sql复制SELECT SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c,d', ',', 2), ',', -1);

这个嵌套的套路很常用，建议直接记下来。它的执行逻辑是：先取前两段 a,b，再从结果上取最后一段 b。类似的技巧在处理“分类路径取父级”“编码按层级拆解”时非常好用。

2.2 中文字符统计用 CHAR_LENGTH，LENGTH 是按字节算的

实际开发中很容易踩一个坑：统计某个备注字段是不是超过 50 个字。新人写了 WHERE LENGTH(remark) > 50，结果把一堆 20 个汉字的记录也查出来了，因为 LENGTH 在 utf8mb4 字符集下一个汉字占 3 个字节，50 个字实际占 150 个字节。而 CHAR_LENGTH 才是按字符个数统计：

sql复制SELECT LENGTH('数据库');        -- 返回 9，utf8mb4 下每个中文 3 字节
SELECT CHAR_LENGTH('数据库');   -- 返回 3

给用户备注、评论内容做长度校验时，应当使用 CHAR_LENGTH。如果字段可能包含 emoji，比如 CHAR_LENGTH('你好😄') 返回 3，而 LENGTH 会因为 emoji 占 4 个字节而返回更大的数字。虽然这两个函数都没法直接避免字符串被截断的问题，但至少统计口径上要符合业务预期。

2.3 拼接、查找、替换的日常组合

字符串拼接在报表里经常用到。比如要给一批用户批量生成导出的文件名，可以用 CONCAT 把日期、批次、用户ID 连起来：

sql复制SELECT CONCAT('export_', DATE_FORMAT(NOW(), '%Y%m%d'), '_', user_id, '.csv')
FROM user_order
WHERE order_date = '2024-08-15';

多个字段拼接时要注意 NULL。MySQL 里任何值和 NULL 拼接，结果都是 NULL。例如用户表里 nick_name 为空，CONCAT(nick_name, '-', level) 会变成 NULL，而不是把空字符串拼进去。我一般用两个办法处理：

• 用 CONCAT_WS，它会自动跳过 NULL 值，例如 CONCAT_WS('-', nick_name, level, city)。
• 先用 IFNULL 给字段一个默认值。

查找字符串位置的函数主要有 LOCATE、INSTR 和 POSITION。它们返回子串第一次出现的位置。常用于判断某个内容是否包含指定关键词。注意返回的是从 1 开始的索引，找不到则返回 0：

sql复制SELECT LOCATE('o', 'hello');      -- 返回 5
SELECT INSTR('hello', 'o');       -- 返回 5
SELECT LOCATE('x', 'hello');      -- 返回 0

如果你需要判断“是否包含”，也可以直接用 LIKE 或 REGEXP_LIKE。MySQL 8.0 以后正则函数更完整，像 REGEXP_LIKE、REGEXP_REPLACE、REGEXP_SUBSTR 都可以直接用。但正则表达式更容易写复杂，而且性能一般比 LIKE 差，建议只在真正需要多模式匹配时使用。比如验证手机号是否合法，可以写：

sql复制SELECT phone,
       REGEXP_LIKE(phone, '^1[3-9][0-9]{9}$') AS is_valid
FROM user_contact;

这类加在输出列上的函数不会造成索引失效，适合做数据质量探查。如果数据量很大且要在过滤条件里用，最好还是先清洗到独立字段。

下面把最常用的字符串函数整理成一张速查表，方便收藏：

3. 从“int + 5”到隐式转换：数值函数比想象中更需要谨慎

3.1 为什么 int + 5 也可能写出问题

搜索热词里有“mysql中int+5”，看得出来不少同学在处理字段值加固定数时遇到过困惑。int_col + 5 本身没有任何问题，但一旦字段类型不是数值类型，事情就变复杂了。比如一个订单状态字段被设计成了 varchar，值可能包含数字和字母，执行 SELECT order_status + 5 时 MySQL 会尝试把字符串转成数字。大部分情况下它能转出开头的数值部分，但结果可能和你预期完全不一致。

举一个我实际遇到的例子。某个接口的版本号存在 version 字段，类型是 varchar，值有 v1、v10、v2 这种。运营同事想给每个版本号在报表里加 1，直接写了 version + 1。结果 v10 被转成 10，得到 11，但业务上想要的可能是版本号升级后变成 v11 还是版本序号加 1，口径完全想歪了。这种时候必须先明确字段的业务含义，再用正确的函数处理，而不是依赖隐式转换。

隐式转换还有一个隐蔽风险：当字段是字符串类型，但你在 WHERE 里和数字比较时，MySQL 会把字段转成数字来比较。这意味着即使这个字段上有索引，优化器也可能无法高效使用。比如订单号 order_no 是 varchar，存的是 1001、1002 这类数字，写 WHERE order_no = 1001 虽然能查出结果，但可能会让索引失效，或者出现类似 '1001abc' 也被匹配的隐患。稳妥的写法是：

sql复制SELECT *
FROM orders
WHERE order_no = '1001';

给条件里的值显式加引号，让 MySQL 不必做类型转换。

3.2 ROUND、FLOOR、CEILING、DIV 和 MOD 的使用要点

数值处理中常用到取整、四舍五入、除法和取余。ROUND 并不是任何时候都按“四舍五入”理解的，但对日常开发来说最需要注意的是浮点数精度。如果不希望出现 ROUND(2.675, 2) 得到 2.67 这种和直觉相悖的结果，要么把字段类型设成 DECIMAL，要么先转换成精确类型再计算：

sql复制SELECT ROUND(2.675, 2);                               -- 浮点情况下结果可能不是预期
SELECT ROUND(CAST('2.675' AS DECIMAL(10, 3)), 2);     -- 返回 2.68

FLOOR 是向下取整，CEILING 是向上取整。常见的分页算法里，总页数可以写成：

sql复制SELECT CEILING(total_count / :page_size) AS total_page
FROM (SELECT COUNT(*) AS total_count FROM orders) t;

DIV 是整数除法，MOD 是取余。取模运算常用于分库分表、轮询分配，例如判断一个用户应该进入哪个编号的分表，可以在 SQL 里直接算：

sql复制SELECT MOD(user_id, 16) AS shard_no
FROM users
WHERE user_id = 123456;

写业务代码时还有一个高频场景：小数位数格式化。注意 FORMAT 函数它会把结果转成带千分位分割符的字符串，比如：

sql复制SELECT FORMAT(1234567.891, 2);  -- 返回 1,234,567.89

如果只是要控制小数位数并保留数值类型，用 ROUND；如果是为了导出报表给业务方看，用 FORMAT 或应用层格式化。最怕的是在 SUM 之后直接 ROUND，但外层又拿这个结果参与二次运算，导致精度问题被放大一笔。

3.3 数值转换：CAST、CONVERT 与字符串转数值的隐式陷阱

显式类型转换写起来更清晰：

sql复制SELECT CAST('123' AS UNSIGNED);            -- 123
SELECT CONVERT('2024-08-15', DATE);        -- 2024-08-15
SELECT CAST(3.14159 AS DECIMAL(10,2));     -- 3.14

如果字符串不是合法的数字，比如 'abc123'，CAST('abc123' AS UNSIGNED) 会返回 0，而且 MySQL 并不会直接报错。这一点在数据清洗时要小心。我曾经在做数据迁移时遇到一个现象：源数据表里有一个“手机号后四位”的字段，有些数据是数字，有些数据带了空格和 # 符号。在临时表里直接 CAST(col AS UNSIGNED) 得到一批 0，后来才发现是非法字符导致的。

对于“判断某个字符串能否转成数值”的需求，最可靠的是先用正则表达式做一次过滤：

sql复制SELECT *
FROM temp_data
WHERE col NOT REGEXP '^[0-9]+$';

把不合法的数据捞出来人工核对，而不是让数据库默默把非法值转成 0。这也是我后来写清洗脚本时的一个原则：凡是转换后可能出现数据丢失的地方，先查一遍非法值，宁可在代码里显式报错，也不要让 0 混进业务报表。

4. 日期时间函数：范围查询、统计口径和时区三座大山

4.1 日期范围查询的优化写法

回到开头那个慢查询。YEAR(create_time) = 2024 AND MONTH(create_time) = 8 确实很直观，但当 create_time 上有索引时，这条 SQL 很难直接利用范围扫描。改写方案是：把“某年某月”转换成“时间点区间”。

sql复制-- 不推荐：函数包住索引列
SELECT COUNT(*)
FROM orders
WHERE YEAR(create_time) = 2024 AND MONTH(create_time) = 8;

-- 推荐：使用半开区间，能走索引
SELECT COUNT(*)
FROM orders
WHERE create_time >= '2024-08-01 00:00:00'
  AND create_time <  '2024-09-01 00:00:00';

这里的边界值没必要自己在应用里拼，直接用日期函数当场算出来也行，因为函数作用在常量一侧，不会影响索引：

sql复制SELECT COUNT(*)
FROM orders
WHERE create_time >= DATE_FORMAT('2024-08-15', '%Y-%m-01')
  AND create_time <  DATE_ADD(DATE_FORMAT('2024-08-15', '%Y-%m-01'), INTERVAL 1 MONTH);

很多人写日期范围查询时容易漏掉一天的结束时间。比如查“8 月 15 日”的数据，写成：

sql复制WHERE create_time BETWEEN '2024-08-15' AND '2024-08-16'

这个写法会把 8 月 16 日 0 点的数据也纳入，实际上多了临界值。更稳妥的半开区间是：

sql复制WHERE create_time >= '2024-08-15 00:00:00'
  AND create_time <  '2024-08-16 00:00:00'

4.2 DATE_FORMAT、DATEDIFF 与 TIMESTAMPDIFF 的统计口径

做报表时 DATE_FORMAT 是最常用的输出格式化函数。它能把时间转成各种展示格式：

sql复制SELECT DATE_FORMAT('2024-08-15 14:30:00', '%Y-%m-%d') AS day_part;    -- 2024-08-15
SELECT DATE_FORMAT('2024-08-15 14:30:00', '%Y-%m-%d %H:%i:%s') AS ts; -- 2024-08-15 14:30:00
SELECT DATE_FORMAT('2024-08-15 14:30:00', '%H') AS hour_part;         -- 14

需要注意的是 DATE_FORMAT 的结果是字符串，不是日期类型。如果你把格式化后的结果再用来比较大小，例如 DATE_FORMAT(create_time, '%Y-%m-%d') > '2024-08-01'，这本质上是字符串比较。大多数时候因为格式一致结果不会出错，但效率上和索引利用上往往不理想。

计算两个日期之间相差多少天，最简单的函数是 DATEDIFF，只取日期部分进行比较：

sql复制SELECT DATEDIFF('2024-09-01', '2024-08-15');  -- 返回 17

但要计算相差多少小时、多少分钟，就要用到 TIMESTAMPDIFF，而且它的参数顺序是“大时间减小时分”还是“结束时间减开始时间”很容易搞错。TIMESTAMPDIFF(unit, start_date, end_date) 返回的是 end_date - start_date，别写反。例如：

sql复制SELECT TIMESTAMPDIFF(HOUR, '2024-08-15 00:00:00', '2024-08-16 12:00:00'); -- 返回 36
SELECT TIMESTAMPDIFF(MINUTE, start_time, end_time) AS duration_minutes
FROM call_log;

周维度统计也常用 YEARWEEK 或 WEEK。这里有个坑：一周是从周日开始还是周一开始，在没有明确参数时可能跟领导要的统计口径不一样。建议统计周报时先确认口径，再显式设置模式：

sql复制SELECT YEARWEEK(create_time, 1) AS week_no, COUNT(*) AS order_cnt
FROM orders
GROUP BY YEARWEEK(create_time, 1);

4.3 时区：为什么存进去是 12 点，读出来多 8 小时

MySQL 的时间类型里，TIMESTAMP 写入时会从当前会话时区转换到 UTC 存储，查询时再转换回来。DATETIME 则不做任何转换，存什么就是什么。这也导致一个常见现象：应用连接串里没设置 serverTimezone，MySQL 用了 UTC，应用又在北京时区，于是查出来的时间比实际多了 8 个小时。

我通常建议团队按以下规则处理：

• 数据库中统一存 DATETIME，并且明确约定存储的是业务本地时间还是 UTC。
• 应用连接串的 serverTimezone 要和服务端实际时区一致，避免连接层转换。
• 展示层需要转时区时，优先在应用层处理，而不是依赖 CONVERT_TZ 做跨时区转换。跨时区转换的逻辑在应用代码里更容易测试和复用。

如果一定要在 MySQL 里做时区转换，语法是这样的：

sql复制SELECT CONVERT_TZ('2024-08-15 12:00:00', '+00:00', '+08:00');

不过这个函数依赖 MySQL 的时区表，部分云数据库环境里未加载时区数据时会返回 NULL，所以上线前一定要自测。

5. 聚合、排序与窗口函数：报表场景中容易被忽略的细节

5.1 COUNT、SUM、AVG 遇到 NULL 时的行为

聚合函数看着简单，但是和 NULL 一碰就会出现预期差。COUNT(*) 统计的是行数，COUNT(column) 统计的是该列非 NULL 的行数。如果一个订单表里 pay_time 允许为空，统计“已支付订单数”的时候：

sql复制SELECT COUNT(*) FROM orders WHERE pay_time IS NOT NULL;

也可以直接写作：

sql复制SELECT COUNT(pay_time) FROM orders;

两者结果是一样的，但这种写法要求你清楚 COUNT(字段) 会忽略 NULL。SUM(IFNULL(amount, 0)) 和 SUM(amount) 的结果其实相同，NULL 在 SUM 中会被忽略，不会参与求和，也不会把结果变成 NULL。但是 AVG 会受 NULL 影响：如果一批数据里有 10 条，其中 3 条金额为 NULL，AVG(amount) 相当于除以 7 而不是 10。要得到包含 NULL 在内的均值，需要先把 NULL 转成 0 再求平均：

sql复制SELECT AVG(amount)                AS avg_without_null,
       AVG(IFNULL(amount, 0))     AS avg_treat_null_as_zero
FROM orders;

这两种结果代表完全不同的业务含义。统计在线时长、销售额均值这类指标时，一定要先和业务确认清楚口径。

5.2 GROUP_CONCAT 的排序与长度限制

把同一个分组里的内容拼成一行是 GROUP_CONCAT 的看家本领。例如查询每个用户的订单号列表：

sql复制SELECT user_id,
       GROUP_CONCAT(order_no ORDER BY create_time ASC SEPARATOR ',') AS order_list
FROM orders
GROUP BY user_id;

这里有两个很容易踩的坑。

第一，GROUP_CONCAT 默认最大长度是 1024 字节，数据量一大，拼出来的字段会被静默截断。遇到大批量明细拼接时，需要先设置：

sql复制SET SESSION group_concat_max_len = 102400;

但要注意这个设置只影响当前会话，生产环境要改默认值需要在 MySQL 配置里调整或每次连接后重新设置。

第二，拼接顺序需要显式指定，不写 ORDER BY 的话，结果顺序不受保证。很多人在 MySQL 5.7 下看到的结果刚好是有序的，就以为不用写，后来换版本或者数据分布变化后顺序就乱了。排序和分隔符最好都写清楚。

如果遇到一对多的父子数据要横向展开，而不是拼成字符串，比如每个订单关联多个商品，想要在应用层展示成商品列表，我更推荐用 JSON 函数组装：

sql复制SELECT order_id,
       JSON_ARRAYAGG(product_name) AS product_list
FROM order_detail
GROUP BY order_id;

MySQL 5.7 开始支持 JSON_ARRAYAGG 和 JSON_OBJECTAGG，查询结果可以直接接给 Java 或 JavaScript 解析，比在数据库里拼逗号分隔字符串更规范。

5.3 排序时遇到“编号10排在9前面”的问题

普通的 ORDER BY 按字典序排时，字段 order_no 如果存的是字符串类型的编号，10 会排在 9 前面：

sql复制SELECT order_no FROM orders ORDER BY order_no;
-- 可能返回 1, 10, 11, 2, 3 ...

想把编号按数值大小排序，常见写法是：

sql复制SELECT order_no FROM orders ORDER BY CAST(order_no AS UNSIGNED);

也可以取巧写成 ORDER BY order_no + 0，利用隐式转换实现数值排序。但为了可读性和意图清晰，我建议还是写 CAST 或 CONVERT。这种方式只影响排序结果，不会修改数据本身，前提是字段内容确实是数字。

业务上更合理的做法，是编号本来就单独存一个数值序列。如果经常要按编号排序，设计表结构时就别把数字序列塞进字符串字段里。

5.4 MySQL 8.0 窗口函数：让“取每个用户最近一单”不再靠子查询

MySQL 8.0 之后，窗口函数极大方便了分组内取数。以前写“每个用户最近的订单”，通常要用相关子查询或者先排序再分组，一旦数据量大了效率很低。现在用 ROW_NUMBER() 窗口函数：

sql复制SELECT user_id, order_id, create_time
FROM (
    SELECT user_id,
           order_id,
           create_time,
           ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn
    FROM orders
) t
WHERE rn = 1;

需要注意：窗口函数的结果不能在 WHERE 中直接使用，必须在派生表里包一层再过滤。这条规律刚开始用窗口函数的人很容易踩，报错或者结果不对时先看看是不是在同一个查询层级里使用了 rn 来过滤。

窗口函数里常用的还有：

sql复制-- 每个用户按时间升序累计金额
SELECT user_id,
       create_time,
       SUM(amount) OVER (PARTITION BY user_id ORDER BY create_time) AS cum_amount
FROM orders;

-- 同时取出分组内最大值和当前行值做比较
SELECT user_id,
       amount,
       MAX(amount) OVER (PARTITION BY user_id) AS group_max_amount
FROM orders;

实际开发中，聚合函数 + 窗口函数可以省掉很多复杂的子查询和临时表。尤其是运营报表这种需要保留明细行的场景，不再需要先 GROUP BY 再 LEFT JOIN 回原表去取明细里某个值。对排查数据问题也友好很多，一行 SQL 里的逻辑更直观。

6. 自定义函数和存储过程的边界：平时能不用尽量不用，要用就按工程标准

6.1 自定义函数的常见限制

MySQL 允许创建自定义函数，语法不算复杂：

sql复制DELIMITER $$

CREATE FUNCTION get_order_year(order_date DATE)
RETURNS INT
DETERMINISTIC
BEGIN
    RETURN YEAR(order_date);
END$$

DELIMITER ;

但这个函数实际意义不大，因为直接用内置函数就行。自定义函数真正有价值的场景很少，我遇过的典型场景包括：

1. 团队内部有很多历史老 SQL，统一封装某个复杂转换逻辑，在多个报表中复用。
2. 加密或脱敏规则隔离，不想在每段 SELECT 里重复写 REPLACE、SUBSTRING 的组合。
3. 某些计算结果在没有窗口函数的旧版本里逻辑很复杂，封装成函数能降低后续 SQL 的阅读成本。

但自定义函数有几个工程上的麻烦：

• 函数内部一般要写事务或循环逻辑时，性能通常比同等的单条 SQL 差很多。
• 函数的高层语义对 DBA 不透明，线上执行计划不好审计。
• MySQL 开启二进制日志后，创建自定义函数可能遇到 log_bin_trust_function_creators 限制。如果不想临时开参数，就必须保证函数是 DETERMINISTIC 或声明不包含读数据修改，有主从复制时尤其要注意。
• 版本升级时，自定义函数可能因为语法兼容性问题变成迁移负担。

所以我的习惯是：先用普通 SQL 和内置函数解决，解决不了再考虑是否真的需要存储过程或自定义函数，而不是为了“看起来工程化”主动增加一层逻辑。

6.2 存储过程里的循环为什么总是慢

如果业务的核心诉求是“批量修改大量数据”，很多人会写一个存储过程，用游标逐行处理：

sql复制DELIMITER $$

CREATE PROCEDURE update_scores()
BEGIN
    DECLARE done INT DEFAULT 0;
    DECLARE uid INT;
    DECLARE cur CURSOR FOR SELECT user_id FROM users WHERE score = 0;
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

    OPEN cur;
    read_loop: LOOP
        FETCH cur INTO uid;
        IF done THEN
            LEAVE read_loop;
        END IF;
        UPDATE users SET score = score + 1 WHERE user_id = uid;
    END LOOP;
    CLOSE cur;
END$$

DELIMITER ;

这种写法逻辑正确但效率很低。逐行 UPDATE 会频繁触发行锁、事务日志同步和网络交互，执行速度远不如单条 SQL：

sql复制UPDATE users SET score = score + 1 WHERE score = 0;

很多情况下，逐行循环的必要性来自“每行需要不同的计算逻辑”。这种时候可以考虑用 CASE WHEN 表达式或临时表，先算好每条数据的目标值，再一次性更新。比如：

sql复制UPDATE users
JOIN (
    SELECT user_id,
           CASE
               WHEN score < 60 THEN 60
               ELSE score + 1
           END AS new_score
    FROM users
) tmp ON users.user_id = tmp.user_id
SET users.score = tmp.new_score;

存储过程真正有价值的地方在于处理多步骤、需要事务保证和固定执行顺序的批处理任务，比如数据归档、对账补偿、定时清理历史数据。但即使是这种场景，我也建议只在数据库端做“不得不做”的活。批量任务能和业务应用解耦就尽量解耦，放到调度平台里用脚本执行，便于日志采集、报警和重跑。

6.3 创建存储过程或函数前的检查清单

如果你确实需要写自定义函数或存储过程，落地前我建议先过一遍这个检查清单：

1. 是不是所有逻辑都能用普通 SQL 完成？如果能，不用写成函数。
2. 函数或过程是否被多个 SQL 复用？只在一个地方用的话，直接写在应用层可能更好维护。
3. 函数是否声明了正确的 DETERMINISTIC / READS SQL DATA 等特性？主从环境下这影响能不能被同步执行。
4. 有没有考虑字符集和排序规则？函数参数和返回值如果类型不匹配，容易在连接时发生隐式转换。
5. 有没有写异常处理？存储过程中的每一步都应该能够明确提示“失败在哪一行数据上”。
6. 有没有测试大数据量下的执行时间？存储过程里一行行循环在 1 万行时能跑，不代表 100 万行也能跑。

以我个人的项目经验来说，真正在线上稳定运行很久的存储过程基本都是两类：一类是运维自己的定时归档流程，另一类是财务对账这种逻辑固定、不允许改动的计算任务。业务应用里临时需要的复杂逻辑，放在代码里反而更透明、更好测试。

7. 面试题常问的 MySQL 函数相关点，我是怎么准备的

搜索热词里有不少“MySQL 面试题”，函数是面试中没法绕开的基础。但面试官往往不会只问“SUBSTRING 的用法”，而是会把函数和索引、优化、业务场景结合起来。我给自己总结过一套答题框架，先后顺序很重要。

第一步，先说函数的分类：字符串函数、数值函数、日期时间函数、聚合函数、流程控制函数和窗口函数，以及每个分类里最常用的两三个函数。

第二步，主动抛“WHERE 里对索引列使用函数会失效”这个优化点。面试官问到日期函数时，不要只背 DATE_FORMAT 的格式，而应该主动说，如果是查某年某月的数据，我会用 >= 和 < 构造半开区间，避免在 create_time 上套 YEAR() 和 MONTH()。

第三步，结合一个真实场景讲清楚。比如用户要“最近 30 天的订单”，可以这样回答：

sql复制SELECT order_id, amount
FROM orders
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND create_time < NOW()
ORDER BY create_time DESC;

然后说明 DATE_SUB(NOW(), INTERVAL 30 DAY) 的结果是常量，不是索引列上套函数，对索引没有影响。

第四步，如果面试官继续追问，就讲对 NULL 的处理经验。比如 COUNT(字段) 会忽略 NULL，AVG(字段) 不会把 NULL 当 0，CONCAT 遇到 NULL 也可能返回 NULL。这些细节往往能体现你处理真实数据的经验，比单纯背文档要好。

第五步，如果问道 MySQL 8.0 新特性，把窗口函数拿出来，用一个“每个用户最近一单”的 ROW_NUMBER() 例子回答，这比在 5.7 里用变量或子查询的写法更能体现你平时跟进新版本的习惯。

这套框架好处在于它既有知识广度，又有场景深度。面试官顺着任何一层追问，你都有内容接住；如果对方想收住，你也已经展示完了解决问题的思路。

最后分享一个我自己的小习惯：平时维护 SQL 的时候，我会顺手把每个关键查询的执行计划打开看一遍，用 EXPLAIN 确认有没有 MySQL 在没有预判的情况下做了隐式类型转换或文件排序。很多问题写出来后肉眼很难发现，但执行计划一眼就能暴露出来。尤其是在 type 列看到 ALL，或者 Extra 列出现 Using filesort、Using temporary 时，我会习惯性回到 SQL 里的函数和转换上去找原因。MySQL 函数本身并不复杂，真正让数据查询变慢、让报表结果对不上的，往往是它们在使用边界上的位置。希望这篇整理能让你少踩几个类似的坑。