MySQL内置函数全解析：字符串、日期、聚合与性能优化实战

做数据库开发这些年，我见过太多新手盯着一行SQL抓耳挠腮，最后发现只是内置函数没用对。MySQL内置函数是日常SQL里最频繁接触的那批工具，字符串拼接、日期格式化、条件判断、分组统计，几乎每一条正经的业务查询都离不开它们。这篇内容围绕MySQL内置函数，从字符串、数值、日期、聚合、条件逻辑到性能红线逐一拆解，最后用一个订单周报案例把常用函数串起来，适合刚接触数据库的开发者，也适合写过一段时间SQL但总在一些边界问题上栽跟头的人。

很多朋友觉得函数这东西随便查手册就行，真正写起来才发现坑全藏在细节里：字符截取是按字节还是按字符、GROUP_CONCAT结果莫名被截断、WHERE里套了一个函数后索引直接失效、NULL参与聚合时结果静悄悄变错。这些情况光靠文档搞不定，得靠实战踩坑慢慢攒。这篇就把我实际项目中用函数留下的经验和教训一次说清楚。

1. 字符串函数：业务开发里最常碰到的第一关

1.1 拼接、截取与清洗的基本姿势

字符串处理是业务SQL里出现频率最高的一类需求。拼接多个字段或常量，通常用CONCAT，如果拼接过程中可能出现NULL，就得小心了——CONCAT只要收到一个NULL，整个结果就变成NULL，这一条经常把新手坑得莫名其妙。想忽略NULL安全拼接，用CONCAT_WS，它会把分隔符作为第一个参数，NULL值会被自动跳过。比如CONCAT_WS('-', '2024', NULL, '01')的结果是'2024-01'，而CONCAT('2024', NULL, '01')直接就NULL了。

截取字符串时，SUBSTRING、LEFT、RIGHT各有适用场景。LEFT和RIGHT适合从边缘截固定长度，SUBSTRING适合截中间一段。MySQL的SUBSTRING默认按字符位置截取，不是按字节，所以处理中文时比某些按字节截断的数据库要友好。但做字符长度统计时又容易踩坑：LENGTH返回的是字节数，一个中文字符在UTF8编码下占3个字节，CHAR_LENGTH返回的才是字符个数。比如LENGTH('你好')结果是6，CHAR_LENGTH('你好')结果是2。如果业务要统计留言长度或做昵称截断，必须用CHAR_LENGTH，否则线上会出现中文字符被拦腰切断的乱码事故。

清洗场景里，TRIM、LTRIM、RTRIM能去掉首尾空格，默认只去空格，也可以指定字符，比如TRIM(BOTH '0' FROM '00123')可以去掉首尾的0。REPLACE做简单替换非常顺手，替换换行符、去掉多余空格都靠它。LPAD和RPAD可以用来补位，比如订单号补零、金额格式化，虽然这些事在程序层也能做，但在SQL里直接搞定会省一次内存和传输开销。

提示：判断字符串是否为空，很多人习惯写=''，但这会漏掉NULL。稳妥的写法是结合函数判断：TRIM(字段) = '' OR 字段 IS NULL，或者直接用IFNULL(TRIM(字段), '') = ''。

1.2 LIKE、正则与模糊搜索的隐藏坑

模糊匹配最常用的是LIKE，配合%和_两个通配符。%表示任意长度的任意字符，表示单个任意字符。它最值得警惕的是转义问题。业务字段里如果真的包含%或，比如商品名称里带折扣“50%OFF”，写LIKE '%50%OFF%'时通配符会把所有带50的字符串都捞出来。解决办法是用ESCAPE指定转义符，写LIKE '%50%OFF%' ESCAPE ''。这条细节在用户输入直接参与拼接时尤其重要，同时也是SQL注入的一个潜在入口。

REGEXP提供了更强大的正则匹配能力，适合做字符类判断、电话号码格式校验这类LIKE不好表达的活。比如REGEXP '^1[0-9]{10}$'可以判断手机号格式。但正则有性能开销，数据量大的时候正则扫描是逐行匹配，不像LIKE还能在特定条件下走索引前缀，所以能用LIKE解决的就别轻易上正则。

模糊搜索还有一个方向容易忽略：排序规则。如果字段使用的排序规则大小写不敏感，LIKE 'abc%'会把ABC也匹配出来，这在做账号或标签匹配时可能产生预期外的结果。想强制区分大小写，可以给字段加COLLATE utf8mb4_bin，或者用BINARY包裹字段。解决这类问题要结合字段定义一起看，不能只看函数本身。

1.3 GROUP_CONCAT：把多行拧成一行

GROUP_CONCAT是我在报表开发里很依赖的函数，作用是把分组内的多行值合并成一个字符串，默认用逗号分隔。典型场景是查一个订单下所有商品名称，或者一个用户的所有角色标签。

它有几个参数值得记住：SEPARATOR指定分隔符，DISTINCT去重，ORDER BY控制组内排序。比如GROUP_CONCAT(DISTINCT tag ORDER BY tag SEPARATOR '|')可以把去重后的标签按字典序拼起来。很多人忽略了它还有长度上限，默认受max_allowed_packet限制，常见默认值在1MB左右，如果拼接的商品很多或字符串很长，结果会被静默截断，不会报错。排查这类问题比较费劲，因为SQL看着是通的，结果却是缺胳膊少腿的。我建议做大数据量拼接前先把该参数调大，或者明确业务上限。

GROUP_CONCAT另一个坑是NULL值，它默认会把NULL跳过去，如果需要保留占位，得先用IFNULL把NULL转成空字符串或其他占位符再拼。

2. 数值与类型转换：别让小数和随机数翻车

2.1 四舍五入、取整与安全的数值运算

数值运算函数看起来简单，但业务对精度的要求藏得很深。ROUND做四舍五入，可以指定保留小数位，ROUND(3.14159, 2)结果是3.14。要注意ROUND在不同数据库里的舍入规则，MySQL采用的是四舍五入，而不是银行家舍入，这一点在金融场景下要留意，涉及钱的统计最好在程序层或SQL里明确精度规则，避免因为舍入规则不同导致对不上账。

取整函数里CEIL向上取整、FLOOR向下取整，CEIL(2.1)结果是3，FLOOR(2.9)结果是2。它们适合分页计算、库存拆分等场景。MOD取余数的用途广泛，比如把订单ID按模分片、判断奇偶、做轮询分配。POWER、SQRT、ABS这些数学函数偶尔也会用到，比如计算距离、百分比变化率。百分比变化率有一个容易出错的地方：分母为0时AVG或除法直接报错或返回NULL，需要先做分母判断，一般用IF或NULLIF把异常情况拦下来。

数值函数设计之初就很直接，真正容易出事故的不是函数本身，而是传入参数的精度。比如金额用FLOAT或DOUBLE存储，累计求和后出现0.1+0.2不等于0.3的浮点误差，这不是函数的锅，是存储类型的问题。业务上涉及金额、积分这类需要精确计算的字段，应该用DECIMAL，SUM和AVG的精度才有保障。

2.2 RAND()随机排序的性能陷阱

RAND()返回一个0到1之间的随机小数。最经典的错误用法是ORDER BY RAND()，它的实现会对全表每一行生成随机数再排序，数据量小时没感觉，几十万行以上响应时间会戏剧性拉长，因为排序没法利用索引，相当于全表扫描加文件排序一起上。我在一个模拟项目里测试过，一张20万行的表，ORDER BY RAND()查询耗时从几十毫秒直接冲到两秒以上。

取随机行的替代思路是：先COUNT(*)拿到总量，再在应用层随机生成一个偏移量，用LIMIT 1 OFFSET ?去取，这样只做一次主键定位，性能稳定得多。如果需求是随机抽样固定条数，也可以按主键范围分段取数，实现简单且快。需要随机业务编号或验证码时，可以结合RAND和LPAD生成，比如LPAD(FLOOR(RAND() * 1000000), 6, '0')，但要留意随机数碰撞，真正要求不重复的场景应该走业务表或原子序号，不能完全依赖函数随机。

2.3 CAST与隐式类型转换的坑

MySQL在比较不同类型的值时会做隐式转换。最典型的坑是字符串字段和数字比较时，字符串会被转成数字，比如字段存放的是订单号，类型是VARCHAR，查询条件写成WHERE order_id = 123456，MySQL会把字符串'123456'转成数字再比较，如果字段里有非数字字符，转换后结果是0或部分匹配，导致索引失效并产生意外行。正确做法是参数侧也传字符串：WHERE order_id = '123456'。

CAST和CONVERT负责显式类型转换，CAST(amount AS DECIMAL(10,2))、CAST(create_time AS DATE)这类写法可以把数据转换成需要的形态，适合在INSERT、比较、拼接前做预处理。CONVERT还可以指定字符集，比如CONVERT(name USING utf8mb4)，解决从其他字符集导入乱码的问题是常见操作。

隐式转换另一个高频场景是日期和时间。字符串'2024-01-01'和DATE类型比较时，MySQL能自动识别，但如果字符串格式不规范，比如'2024/01/01'或'20240101'，自动识别就可能出错，最好先用STR_TO_DATE把字符串转成标准日期再比较，一步到位避免踩坑。

3. 日期时间函数：统计报表的时间基准

3.1 获取当前时间与格式化

取当前时间最常用的写法是NOW()，它返回当前的日期和时间。还有个容易混淆的是CURDATE()，只返回日期部分，CURTIME()只返回时间部分。从业务角度，NOW()适合记录操作时间，CURDATE()适合做当天数据过滤。CURRENT_TIMESTAMP和NOW()效果基本一致，在不同连接方式下表现也几乎相同，日常选一个顺手用就行。

日期格式化在所有函数里可能是最容易被反复查手册的，DATE_FORMAT(date, format)的格式串里，%Y是四位年份，%y是两位，%m是两位月份，%d是两位日期，%H是24小时制小时，%i是分钟，%s是秒。做报表时拼接各种时间粒度，其实就是改格式串。比如按天分组用DATE_FORMAT(create_time, '%Y-%m-%d')，按月分组用'%Y-%m'，按小时用'%Y-%m-%d %H'，简单高效。

反向操作是STR_TO_DATE，把字符串解析成日期，它在数据清洗和接口对接时很重要。比如外部系统传过来一个'2024/01/02 15:30:00'的字符串，直接比较和排序都会出问题，用STR_TO_DATE('2024/01/02 15:30:00', '%Y/%m/%d %H:%i:%s')转成标准DATETIME就能正常使用。格式串必须和字符串严格对应，%i和%m写错位置会导致解析失败或者得到错误值。

3.2 时间计算与区间判断

做时间窗口计算时，DATE_ADD和DATE_SUB几乎是必备。DATE_ADD(create_time, INTERVAL 1 DAY)表示加一天，DATE_SUB(create_time, INTERVAL 2 HOUR)表示减两小时。INTERVAL后面可以跟DAY、HOUR、MINUTE、MONTH、YEAR等，也可以组合写，比如INTERVAL '1-2' YEAR_MONTH表示1年2个月。这类函数适合做“近7天”“上个月”“本季度”等滚动时间窗口。

计算两个日期之间相差多少天，DATEDIFF只算天数差，它直接比较日期部分，不关心时间。TIMESTAMPDIFF更灵活，可以指定单位，计算两个日期时间之间差了多少秒、分钟、小时、天、月甚至年，比如TIMESTAMPDIFF(MINUTE, start_time, end_time)统计通话时长和任务耗时很合适。需要注意TIMESTAMPDIFF的返回值是整数，月数、年数也是按整数值计算，不是小数，做精确到小数月的计算还得自己换算。

区间判断最怕写成函数套在字段上。比如查某天的订单，新手常写WHERE DATE(create_time) = '2024-01-01'，这写法UPDATE上没问题，但大数据量表上DATE(create_time)会让create_time上的索引无法使用，查询会扫全表。更优的写法是范围查询：WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，既准确又保留索引能力。这个经验我在第6章还会重点展开。

3.3 时区与会话设置

日期函数看起来简单，时区问题一掺和就复杂了。MySQL的NOW()返回的是会话时区的当前时间，而服务器时区和会话时区可以不同。如果连接池里的会话时区设置不一致，同一句SQL在不同连接上执行得到的日期时间可能是不同的，这在多实例、跨机房部署的架构里很容易出现。排查这类问题时先检查time_zone变量和JDBC连接的serverTimezone参数。

UNIX_TIMESTAMP和FROM_UNIXTIME是做时间戳转换的核心工具。业务表里如果存了INT类型的时间戳，查询时用FROM_UNIXTIME(ts, '%Y-%m-%d %H:%i:%s')可以转成可读格式。反过来插入时用UNIX_TIMESTAMP(NOW())生成当前时间戳。这里同样存在时区问题，FROM_UNIXTIME的转换结果受会话时区影响，同一时间戳在UTC和东八区会话下显示的小时数相差8小时。修复方案是把应用连接、数据库会话的时间设置成一致，或者统一按UTC存储、展示层再转换，具体怎么选要看业务对自然时间的依赖程度。

4. 聚合函数与分组统计：GROUP BY背后的规矩

4.1 COUNT计数三兄弟

COUNT()和COUNT(1)在MySQL里性能基本没差别，数据库引擎对这两种写法做了优化，计的都是行数。真正需要区分的是COUNT(具体字段)，它只统计该字段不为NULL的行数。这个差异在业务统计里能造成数据偏差：比如统计订单表里有多少订单填写了备注，COUNT(remark)和COUNT()结果必然不同，后者把没有备注的订单也算进去了。

COUNT结合DISTINCT可以做去重统计，COUNT(DISTINCT user_id)统计活跃用户数，COUNT(DISTINCT product_id)统计销售商品种类数。需要注意的是DISTINCT COUNT的精确性依赖字段的NULL情况，如果字段含NULL，COUNT(DISTINCT 字段)不会把NULL算进去，某些业务场景需要先用IFNULL把NULL换成默认值再统计。

对超大数据量的COUNT，函数本身没太多优化空间，MySQL的InnoDB引擎在没有WHERE条件时统计全表行数也需要扫描。这个阶段考虑的不是换函数，而是换方案，比如走维护计数表或离线统计，这也算聚合函数使用的一个重要认知。

4.2 SUM/AVG/MAX/MIN的NULL语义

SUM对NULL的处理是按0参与还是跳过？实际结果是：SUM忽略NULL行，比如一组数据是1、2、NULL、3，SUM结果是6，AVG结果是2，不是6/4=1.5。这个NULL语义很容易导致统计结果和预期不一致。如果希望NULL按0参与计算，得先用IFNULL或COALESCE把NULL转成0再聚合。

AVG在整列全为NULL时返回NULL，不是0。在报表前端展示时会出现一个空白的平均值，这时需要用IFNULL包裹，比如IFNULL(AVG(score), 0)兜底。MAX和MIN对NULL的处理也是忽略，这就不会引起歧义，但如果在分组统计后想取每组极值对应的整行数据，直接查MAX不太方便，需要借助子查询或窗口函数，这也拓展到聚合函数和窗口函数配合的问题。

MAX/MIN另有一个常见用途是找日期区间：MAX(create_time)表示最近一次记录时间，MIN(create_time)表示最早一次记录时间。准备口径时要注意这两个值是否带时分秒，如果只按日期分组聚合，MAX(create_time)返回的是该组内最晚的完整时间点，可能包含时间部分，展示和排需处理好。

4.3 ONLY_FULL_GROUP_BY与HAVING过滤

MySQL从某个版本开始在默认SQL模式中启用ONLY_FULL_GROUP_BY，它要求SELECT后面出现的非聚合列必须出现在GROUP BY子句中。很多老项目在低版本MySQL上跑得好好的SQL，一升级到新版就报错，报错信息提示sql_mode的问题。比如SELECT user_id, order_amount FROM orders GROUP BY user_id，如果order_amount没有聚合处理，升级后直接报错。解决方法是把order_amount改成SUM(order_amount)，或者把非聚合字段也加进GROUP BY。

HAVING和WHERE的区别是新手高频提问点。WHERE在分组前过滤原始行，HAVING在分组聚合后过滤结果集，所以WHERE里不能使用聚合函数，而HAVING可以。比如筛选“订单数量超过100的用户”必须用HAVING COUNT(*) > 100。这个顺序在SQL语义上是严格规定的，理解它以后写分组统计会顺手很多。

分组后排序也有讲究，ORDER BY位置在GROUP BY之后，所以按聚合结果排序是合法的，比如GROUP BY user_id ORDER BY SUM(amount) DESC取消费榜。但如果ORDER BY后面用了SELECT里没体现的别名，要注意别名优先级，MySQL里可以写ORDER BY total DESC，其中total是SELECT中定义的别名，这也是常见的细节优化点。

5. 条件逻辑函数：在SQL里写if-else

5.1 IF、IFNULL、NULLIF、COALESCE的区分与选用

IF(expr, val1, val2)是SQL里最直白的条件函数，条件为真返回val1，否则返回val2，写法非常接近编程语言的if-else。IFNULL(expr1, expr2)专门处理NULL，expr1不为NULL就返回expr1，否则返回expr2。NULLIF(expr1, expr2)则相反，两者相等就返回NULL，否则返回expr1，经常用来防除零，比如NULLIF(denominator, 0)让除零的结果变成NULL而不是报错。COALESCE(expr1, expr2, ...)返回参数列表里第一个非NULL值，适合多重兜底，比如COALESCE(real_name, nick_name, '匿名用户')取第一个不为空的字段。

这几个函数表面相似，实际语义差异很大。我做一个实名认证信息展示的时候，希望优先显示真实姓名，其次显示昵称，都没有就显示“匿名用户”，用COALESCE一次搞定。而IFNULL最多只能传两个参数，碰到三个以上字段的兜底就会嵌套得很丑。另外IF的第二、第三个参数可以接表达式甚至子查询，所以在SQL里实现一些简单的分支判断是可行的。

条件函数嵌套时要留意返回类型一致性，IF(条件, 1, 'x')这种写法在不同场景下可能发生隐式转换，返回值类型按更长的类型定，导致比较结果异常。编码规范里一般建议同一表达式内返回同类型的值，减少后续处理的麻烦。

5.2 CASE WHEN的写法与场景选择

CASE WHEN是SQL标准里最规范的分支写法，有两种形式。简单形式CASE expr WHEN value1 THEN result1 WHEN value2 THEN result2 ELSE default END，适合等值判断。搜索形式CASE WHEN condition1 THEN result1 WHEN condition2 THEN result2 ELSE default END，适合范围判断、多条件组合，比如对订单金额分档：WHEN amount > 1000 THEN '大额' WHEN amount > 500 THEN '中等' ELSE '小额' END。

CASE WHEN在写统计报表时的价值几乎是无可替代的。它可以把多个分类条件放在同一个SELECT里，一次扫描算出多个指标。比如统计不同支付方式的订单数，传统的做法是多条SQL分别查，每条SQL扫描一遍表，用CASE WHEN可以写成一条SQL：SUM(CASE WHEN pay_type = 'alipay' THEN 1 ELSE 0 END) AS alipay_cnt，SUM(CASE WHEN pay_type = 'wechat' THEN 1 ELSE 0 END) AS wechat_cnt，这样一次扫描出多个汇总值，效率和对结果的掌控都更好。

CASE WHEN和IF的选择：两者功能有重叠，但CASE WHEN更接近SQL标准，可读性更强，能处理复杂分支，IF更小巧。团队协作时建议统一用CASE WHEN，因为它在多条件场景下结构清晰，后续维护的人不用在脑子里模拟嵌套括号。CASE WHEN还经常配合GROUP BY做二维交叉统计，比如“按月份和支付方式交叉统计订单量”，一条SQL就能完成，在BI报表和运营看板中非常实用。

注意：CASE WHEN每个分支返回的数据类型要一致或兼容，否则可能出现隐式转换。虽然MySQL不会直接报错，但结果类型可能不是预期，尤其在UNION或后续运算中会放大问题。

6. 内置函数的性能红线：先优化SQL再优化配置

6.1 WHERE左侧套函数的索引失效问题

很多函数性能问题不是函数慢，而是它处在WHERE条件左侧导致索引失效。这个规律在MySQL优化器里非常关键：当字段被函数包裹后，B+树索引的列值经过函数变换，无法直接用于范围定位，优化器只能放弃索引，走全表扫描或扫描更大的索引范围。

最常见的反面教材就是日期字段比较。我之前排查过一条慢SQL，每天凌晨跑一次的数据清理任务要处理几十万行数据，查询条件写WHERE DATE(created_at) = CURDATE() - INTERVAL 1 DAY，结果单次查询耗时十几秒。改成WHERE created_at >= (CURDATE() - INTERVAL 1 DAY) AND created_at < CURDATE()以后，同一查询耗时降到几十毫秒。原因是前者对created_at套了函数，后者直接用了范围比较，索引可以正常发挥作用。

这类问题还包括对字符串列做LOWER或UPPER、对数值列做数学运算、对字符列做LEFT截取等。判断一个写法会不会让索引失效，可以执行EXPLAIN看一下type列，如果从ref或range退化成ALL，基本就是函数包裹字段造成的。优化手段有两个方向：一是改写SQL，把函数挪到参数侧；二是在不能改动SQL的前提下，考虑加一个生成的列并建索引，比如建一个创建日期的冗余生成列，再对该列建索引，专门供这类查询使用。

6.2 隐式转换与字符集排序规则

隐式转换导致的索引失效是一个更隐蔽的性能问题。字段类型是VARCHAR，查询条件参数用的是INT，MySQL会把字段转换成数值型再比较，索引同样无效。典型场景是手机号、订单号这类实际是字符串但长得像数字的字段。排查办法也是EXPLAIN，查看警告信息中是否有隐式转换提示。

字符集排序规则对LIKE前缀查询的影响也很大。字段排序规则是utf8mb4_general_ci时，LIKE 'abc%'匹配到ABC也是正常的，因为比较对大小写不敏感。父线上的数据量一旦大起来，这会让原本以为精确的查询捞回一堆不想要的记录。如果业务需要精确匹配，最好在建表时用utf8mb4_bin或utf8mb4_0900_ai_ci之外的选择，或者在查询中用BINARY强制二进制比较。BINARY(字段) LIKE 'abc%'这种方式可以让匹配变为大小写敏感，但这种写法包裹了字段，又会在索引使用上遇到问题，所以更合理的方案是在字段定义层面解决，而不是查询层面。

6.3 函数使用的场合取舍

函数不必避讳，但要分场合。在SELECT列表里做计算、格式化，一般对索引没有影响，因为那是输出层的加工。在JOIN的ON条件里套函数，会直接影响关联方式，让原本的索引关联退化成嵌套循环。在GROUP BY或ORDER BY里套函数，会让分组和排序无法利用索引，产生临时表和文件排序。

批量更新或大批量导出时，如果每行都要调用函数，也要先算好成本。比如大型导出任务里，对每一行都执行正则替换、多层嵌套函数，单条不慢，几十万行叠加起来就是灾难。处理办法是尽量把计算下推到合适的层，或者分批次处理，避免单条SQL高负荷运转。

还有一个治理思路：函数逻辑尽量收敛。业务里经常可以看到同一段“日期转星期几”的逻辑在几个SQL里各写一遍，这样出现问题时要改多处。可以考虑抽成统一的视图或存储函数，让团队引用同一份逻辑，既保证口径一致，也方便后续优化。

7. 一个综合实战：订单数据周报怎么用函数拼出来

7.1 需求与表结构

很多朋友单项函数用得熟，一碰到完整业务报表就不知道从哪下手。我拿一个模拟的订单周报需求来演示。需求是输出最近一周每一天的订单量、订单总额、客单价、各类支付方式订单量，并给每一天打上星期标签。订单表结构简化成：order_id、user_id、amount、pay_type、status、created_at。其中pay_type取值范围是alipay、wechat、card，status包括success、pending、cancel。

这个需求的核心是把日期函数、聚合函数、条件函数组合在一起，一次查询把周报数据算出来，避免多次扫描同一张表。

7.2 分步拆解SQL

第一步锁定时间窗口。因为要取最近一周，先用DATE_SUB(CURDATE(), INTERVAL 6 DAY)算出起始日期，再结合日期范围条件查询，确保created_at上的索引可用。第二步要对created_at做DATE格式化，按DATE(created_at)分组，统计每天的数据。第三步在SELECT里用CASE WHEN统计不同支付方式的数量。第四步用ROUND处理客单价小数位，用IFNULL处理无数据日的兜底，用DATE_FORMAT生成星期标签。

组装后的SQL类似这样：

SELECT DATE_FORMAT(DATE(created_at), '%Y-%m-%d') AS day_label, DATE_FORMAT(DATE(created_at), '%W') AS weekday_name, COUNT(*) AS order_cnt, ROUND(SUM(amount), 2) AS total_amount, ROUND(IFNULL(AVG(amount), 0), 2) AS avg_amount, SUM(CASE WHEN pay_type = 'alipay' THEN 1 ELSE 0 END) AS alipay_cnt, SUM(CASE WHEN pay_type = 'wechat' THEN 1 ELSE 0 END) AS wechat_cnt, SUM(CASE WHEN pay_type = 'card' THEN 1 ELSE 0 END) AS card_cnt FROM orders WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) AND created_at < DATE_SUB(CURDATE(), INTERVAL -1 DAY) AND status = 'success' GROUP BY DATE(created_at) ORDER BY day_label;

这条SQL同时运用了几类核心函数：日期计算函数负责裁剪时间窗口，格式化函数负责输出日报标签，聚合函数负责计数与求和，条件函数负责分渠道统计。如果某一天没有订单，聚合结果不会出现这一行，报表侧如果想补零，可以在程序层做日期补全，也可以在SQL层使用时间维度表左连接，两种方案各有适用场景，但整体数据处理逻辑已经能覆盖绝大多数周报需求。

7.3 完整示例与验证结果

假设数据分布正常，上面SQL的结果会类似这样：

验证逻辑时先把SQL拆成小段，分别验证时间窗口、分组粒度和聚合口径。我习惯先只跑日期过滤，确认返回的时间范围没错，再叠加聚合函数，最后加CASE WHEN分支统计。分步验证能快速定位哪段逻辑出了问题，而不是等完整的报表数据出来以后一头雾水。

8. 常见报错与排查技巧实录

8.1 高频报错与原因速查

把日常工作中积累的报错和排查清单整理成一张速查表，遇到类似问题可以快速对照定位。

排查这类报错时我一般先看完整错误信息里的表字段和上下文位置，再查执行计划，最后通过删减部分条件来隔离问题范围。

8.2 我的排查习惯与避坑心得

内置函数使用报错时，先想清楚数据长什么样，再想SQL怎么写，这个顺序别反。举个例子，从外部接口导入的日期字段看起来是DATETIME，实际是VARCHAR存了各种格式，直接DATE_FORMAT会出现乱码或空值。排查时先SELECT DISTINCT来观察字段的真实值分布，再决定清洗方案。

线上环境不建议拿生产表反复试函数，我一般先造一个模拟数据的小表，把所有边界情况放进去验证。测试数据至少覆盖NULL、空字符串、超长字符串、特殊格式日期这几类。比如测试STR_TO_DATE时，把'2024-01-02'、'2024/1/2'、'2024-1-2'、''都塞进去，才能看到不同的解析行为。

函数调试还有个实用技巧：把复杂函数拆开执行。比如GROUP_CONCAT嵌套了DISTINCT和SEPARATOR，先去掉DISTINCT只看拼接结果，再加DISTINCT看去重效果，最后加SEPARATOR看分隔符字段是否正常。这样每步都明确验证，问题定位比一次写完再查要快很多。

写完SQL别忘了看执行计划，EXPLAIN并不复杂，重点看type、key、rows三列。type从ALL变成ref或range，说明索引生效了；rows从几十万降到几百，说明扫描行数大幅减少。一个查询完成后再顺手用EXPLAIN验证一次，这一习惯能预防大量隐性性能问题。

内置函数的核心价值不是炫技，而是减少业务代码与数据库之间的搬运工作。一条能直接在SQL里完成的统计，不应该费劲查全表到应用层慢慢算。把常用函数的边界条件记熟，把性能红线刻在脑子里，时间长了，写SQL的效率和正确率会明显拉开差距。