MySQL内置函数深度解析：从基础用法到索引失效陷阱-代码聚汇网

MySQL内置函数深度解析：从基础用法到索引失效陷阱

木-Star·2026-09-03·阅读 22 GEO检测（免费）

MySQL内置函数SQL优化字符串函数

|难度：普通|阅读约 40 分钟

前段时间在帮一个订单统计项目做SQL重构时，我遇到了一条很典型的查询：要把订单备注里的用户手机号脱敏、按支付月份分组、再把同一用户的多条订单号拼成一列。原本Java代码里绕了三层循环才做完的事情，最后用几条MySQL内置函数一条SQL就搞定了。那之后我就特别想把内置函数这件事系统讲清楚——因为很多人对它的认识停留在“需要时查一下”，但真正拉开SQL水平差距的，恰恰是对这些函数的边界、陷阱和执行行为的理解程度。

MySQL内置函数覆盖字符串、数值、日期时间、流程控制、聚合统计等场景，它不是一个“锦上添花”的知识点，而是把复杂业务压缩成一条清晰查询的核心武器。这篇内容适合刚学完基础SQL的初学者，也适合被慢查询、数据统计不准确折腾过的开发者。我不会把官方文档搬一遍，而是挑实际项目里真正影响结果和执行性能的部分，配合能直接复现的案例来讲。

1. 为什么说内置函数是SQL能力的“隐形天花板”

1.1 从ORDER BY和函数的关系说起

很多学习路径把MySQL内置函数放在“了解即可”的位置，但实际上，它是SQL表达能力的上限。举个例子，搜索热词里经常出现“mysql排序”，好像排序只是ORDER BY加个字段名的事。可一旦你遇到这种需求——按用户名的姓氏拼音排序、按订单创建时间的年月排序、按状态字段做自定义排序——你会发现这些全都离不开函数。

更典型的是函数和索引之间的关系。同一个字段，直接排序能命中索引，包一层函数之后可能就直接全表扫描。这不是函数本身写得不对，而是你对MySQL底层执行逻辑缺乏感知。所以我一直觉得，内置函数不是“语法点”，而是连接业务需求和数据库执行引擎的桥梁。

1.2 MySQL内置函数的分类全景

为了后面讨论方便，先把函数按作用域做一个整体梳理。MySQL内置函数常见分类如下：

类别	代表函数	典型业务场景
字符串函数	CONCAT_WS、SUBSTRING_INDEX、REPLACE、GROUP_CONCAT	数据清洗、脱敏、拼接
数值函数	ROUND、CEIL、FLOOR、TRUNCATE、MOD	金额处理、分页计算、取整
日期时间函数	DATE_FORMAT、STR_TO_DATE、DATE_ADD、TIMESTAMPDIFF	统计报表、时间范围判断
流程控制函数	IF、CASE WHEN、IFNULL、COALESCE、NULLIF	状态映射、空值兜底、条件聚合
聚合函数	COUNT、SUM、AVG、MAX、MIN	分组统计、明细汇总
加密/信息函数	MD5、SHA2、USER、DATABASE	安全存储、运维排查

有些函数在分类上有重叠，例如GROUP_CONCAT既是字符串函数也是聚合函数。这种交叉恰恰说明它在实际查询中很有分量。后面每一类我都会挑几个“看着简单但容易翻车”的用法展开讲，而不是把参数列表罗列一遍。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 字符串函数：数据清洗与展示的第一战场

2.1 SUBSTRING_INDEX、INSTR：截取和定位操作不要靠肉眼

SUBSTRING_INDEX可能是最被低估的字符串函数，它的语义是：在给定字符串中，按分隔符查找第N次出现的位置，并返回分隔符左侧或右侧的内容。用法是SUBSTRING_INDEX(str, delim, count)，count为正数时从左往右数，取第count个分隔符左边的部分；count为负数时从右往左数，取第count个分隔符右边的部分。

我给你一个实战场景。一张订单表里存了邮箱，你想把@后面的域名取出来做用户来源分析，传统写法要配合LOCATE和SUBSTRING，写成SUBSTRING(email, LOCATE('@', email) + 1)，逻辑绕且容易出错。用SUBSTRING_INDEX就一行：

sql复制SELECT 
    email,
    SUBSTRING_INDEX(email, '@', -1) AS domain_name
FROM user_order;

再看一个更常见的拆分需求：IP地址“192.168.1.10”，想取最后一段：

sql复制SELECT SUBSTRING_INDEX('192.168.1.10', '.', -1) AS last_part;
-- 结果：10

这里有个容易忽略的关键点：当count为负数时，它是“从右往左数，取分隔符右边的部分”，结果切出来的还是原顺序的右侧内容。很多人第一次用会误以为结果会倒序，其实不是。

INSTR和LOCATE也很容易弄混。INSTR(str, substr)是从str里找substr第一次出现的位置，返回从1开始的下标；LOCATE(substr, str, pos)的参数顺序恰好反过来，还支持从指定位置开始找。写复杂SQL时经常需要“先定位再截取”，如果你把两个函数的参数顺序搞反，返回NULL还算好的，返回错误位置更麻烦，因为数据不会报错，只会悄悄变错。

2.2 CONCAT_WS与GROUP_CONCAT：拼接操作里的两个极端

CONCAT是入门级函数，但它有个早年最容易踩的坑：只要有一个参数是NULL，整个拼接结果就是NULL。比如订单表中部分用户没有填备注，你执行CONCAT(user_name, '-', remark)，遇到备注为NULL的行，结果不是“张三-”，而是整个NULL。这在拼地址、拼名字时非常常见，老手通常直接用CONCAT_WS代替。

CONCAT_WS的第一个参数是分隔符，后面传多个字段，它会自动跳过NULL值：

sql复制SELECT 
    user_name,
    CONCAT_WS('-', user_name, remark) AS user_remark
FROM user_order;

这个函数在很多老项目里还没被普及，但它非常适合处理“存在空值但不想影响整体拼接”的场景。注意一点：CONCAT_WS不会跳过空字符串，它只跳过NULL，如果数据里本身写了空字符串，你看到的拼接结果里仍会有一个位置是空的。

GROUP_CONCAT则是把分组内多行数据拼成一行，常用于行转列或收集子列表。比如想查每个用户的所有订单号，一行一列展示：

sql复制SELECT 
    user_id,
    GROUP_CONCAT(order_no ORDER BY pay_time SEPARATOR '、') AS order_list
FROM user_order
GROUP BY user_id;

GROUP_CONCAT支持在内部做ORDER BY和DISTINCT，也支持自定义分隔符。但存在一个非常实际的坑：默认最大长度是1024字节，超过之后MySQL会静默截断，不会报错。你统计用户拼订单号时，如果订单数多，结果会莫名少一段。解决办法是在会话级调大group_concat_max_len：

sql复制SET SESSION group_concat_max_len = 102400;

同时要注意，GROUP_CONCAT内部需要排序或者去重时，往往会触发临时表操作。数据量大时，这条SQL可能在分组后成为慢查询。能用应用层二次拼接的场景，就不要把所有明细都塞进GROUP_CONCAT。

2.3 REPLACE与REGEXP_REPLACE：全表替换时别忽视顺序和边界

REPLACE(字段, '旧值', '新值')是字符串替换的标配。但它只做字面替换，不支持正则。比如你想把一段文本里所有数字开头的空格清理掉，REPLACE是有心无力的，MySQL 8.0之后可以用REGEXP_REPLACE：

sql复制SELECT REGEXP_REPLACE(remark, '[0-9]+', '#') AS cleaned_remark
FROM user_order;

这里有一个很容易踩的坑：如果新旧值存在包含关系，替换顺序会直接影响结果。举个例子，想把“ABC”替换成“BCD”，再把“BCD”替换成“CDE”，用两个REPLACE嵌套写在一起时，后一个REPLACE可能会作用于前一个REPLACE刚生成的新字符串。这种串行替换必须仔细想清楚数据的中间态，不能只看最终预期。

字符串函数在数据脱敏场景中也很有用，比如手机号只需要保留前3位和后4位，实际写起来就是组合函数：

sql复制SELECT CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS masked_phone
FROM user_order;

写这类SQL时还要留意字符集和排序规则。utf8mb4_general_ci下，字符串比较默认不区分大小写，REPLACE和LIKE也受排序规则影响。如果业务要求严格区分大小写，字段或语句里需要显式指定COLLATE utf8mb4_bin。这个细节如果没有专门处理，统计时会出现“看起来能匹配但实际匹配不上”的灵异现象。

3. 数值处理与类型转换：int+5这类搜索背后的真实问题

3.1 从int(5)到INT+5：显示宽度、存储上限和隐式转换

搜索词里出现“mysql中int+5”的频率不低，我猜测它包含两种典型疑惑：一种是问int(5)里的5到底是什么，另一种是字符串和整数相加为什么结果不是自己预想的值。

先解决int(5)。在MySQL 8.0之前的版本里，INT(5)叫做显示宽度，它只影响一些客户端展示时的填充效果，并不限制存储范围。配合ZEROFILL时，int(5)会把5以内的数字用前导零填充展示成00001，但它不代表字段最大只能存5位数。很多新手在建表时看到INT(5)就以为最多存99999，实际上是错的，INT类型固定占4字节，有符号范围是-2147483648到2147483647，无符号范围是0到4294967295。MySQL 8.0已经移除了整型显示宽度语法，如果你从老项目迁移过来，更要搞清楚这一点。

再解决“int+5”背后的隐式转换。MySQL中数字和字符串做加法时，会尝试把字符串转成数字，转换规则非常“宽容”：从字符串左到右截取能解析为数字的部分，遇到非数字字符就停下。像'100abc'转成数字就是100，'abc100'转成数字就是0，因为它们以非数字开头。所以在MySQL里执行：

sql复制SELECT '5abc' + 5, 'abc5' + 5;
-- 结果：10, 5

不是报错，而是直接猜。这个宽松规则容易让数据在你不注意的情况下被转成错误的值。更麻烦的是，索引列如果被隐式转换，会导致索引失效。比如手机号字段是VARCHAR类型，你写WHERE phone = 13800138000，MySQL会把字符串列里的值逐一转换成数字再比较，结果就是全表扫描。正确写法是WHERE phone = '13800138000'。

3.2 ROUND/FLOOR/TRUNCATE：小数处理的三个函数语义差异

数值计算中最容易出问题的是小数取整。ROUND是四舍五入，TRUNCATE是直接截断，FLOOR是向下取整，但它们在正负数和精度上各有各的边界。

先看ROUND的双参数形式：ROUND(2.675, 2)，很多人以为结果是2.68，实际可能是2.67。原因在于2.675在计算机中无法用浮点数精确表示，内部存储是一个接近但略小于2.675的数，四舍五入时就往下走了。金额敏感场景一定要用DECIMAL类型，不要用FLOAT或DOUBLE。

再看FLOOR和负数的关系。FLOOR(-1.2)结果是-2，因为向下取整指向数轴左侧；CEIL(-1.2)结果是-1，它向上取整。如果业务里要计算“向上取整到整数”，要先用除以精度再取整。TRUNCATE就不一样，它不管正负，只把指定小数位后面的数字直接砍掉，TRUNCATE(-1.29, 1)的结果是-1.2。

FORMAT函数也常被误用。FORMAT(1234567.891, 2)返回字符串“1,234,567.89”，它会做四舍五入，并且自动加千分位逗号。如果你拿这个结果继续参与后续数值计算，很容易触发隐式转换问题，因为带逗号的字符串转回数字时会变得很怪。它更适合作为纯展示层使用。

3.3 金额字段必须养成DECIMAL和CAST的习惯

实际项目中，最稳妥的做法是：金额、积分、优惠券面额等字段全部用DECIMAL(p,s)，避免浮点误差。统计计算后想固定小数位，不要依赖应用层，直接用ROUND或CAST明确结果精度。

看一个订单金额统计场景：

sql复制SELECT 
    user_id,
    ROUND(AVG(amount), 2) AS avg_amount,
    CAST(SUM(amount) AS DECIMAL(10,2)) AS total_amount
FROM user_order
GROUP BY user_id;

CAST是一个常被忽略但很重要的显式转换函数。它可以在查询过程中明确指定结果类型，减少隐式转换的不可控性。CAST('100.46' AS DECIMAL(10,2))可以得到精确数值，CAST(amount AS SIGNED)可以把字符串安全地转成整数。

但要注意，MySQL的CAST对非法内容的处理还是“尽量宽容”。CAST('123abc' AS SIGNED)通常会得到123，不会直接报错。如果你希望出现非法内容时直接中断处理，就得靠SQL_MODE或者应用层做严格校验，CAST本身并不能帮你守住数据质量。

4. 日期时间函数：真正难的不是计算，是时区和语义

4.1 NOW()、CURRENT_TIMESTAMP、SYSDATE()：三个“当前时间”实际不一样

很多人以为NOW()和SYSDATE()都返回当前时间，区别不大。但在一个涉及多行更新的长事务里，这个区别可能直接影响业务正确性。

NOW()返回的是SQL语句开始执行的时间点。即使这条UPDATE语句执行了20秒，NOW()在这20秒里都是一个固定值；SYSDATE()返回的是函数被调用那一瞬间的时间，同一语句里每一行触发时都可能不同。也就是说，你用UPDATE ... SET update_time = NOW()时，一批行的时间是统一的，SET update_time = SYSDATE()则可能是连续变化的秒数。CURRENT_TIMESTAMP和CURRENT_TIMESTAMP()都是NOW()的等价用法。

除此之外，TIMESTAMP列在存储时会做时区转换。会话时区time_zone设置为东八区时，你插入一条2024-08-15 12:00:00，数据库内部按UTC转换后存储；换一个会话把time_zone改成其他区，读出来的值就和写入时不一样。这不是数据丢了，而是时区语义在处理。建议服务器、数据库连接、JDBC参数里的时区保持一致，否则排查起来会非常痛苦。

4.2 DATE_FORMAT与STR_TO_DATE：格式串里的大小写和严格模式

DATE_FORMAT是日期展示的常用函数，它的格式串大小写敏感。比如%Y是4位年份，%y是2位年份；%m是数字月份，%M是英文月份名；%H是24小时制，%h是12小时制。很多报表数据异常都是因为%i和%I搞混，%i才是分钟，%I是12小时制的小时。

反向操作STR_TO_DATE则把字符串解析成日期，常用于导入外部数据时做格式统一。下面这个写法很标准：

sql复制SELECT STR_TO_DATE('2024-08-15 20:30:00', '%Y-%m-%d %H:%i:%s');

STR_TO_DATE有一个非常容易出问题的点：当字符串格式和格式串不匹配时，在严格SQL_MODE下会报错，在非严格模式下会返回NULL。如果来源数据不干净，你需要先对日期字符串做清洗或校验，否则一条坏数据就可能让整个导入中断，或者更隐蔽地变成NULL写进表里。

4.3 DATE_ADD、DATEDIFF、TIMESTAMPDIFF：日期计算的边界语义

DATE_ADD和DATE_SUB是给日期加或减时间间隔的，写法是DATE_ADD(日期, INTERVAL 表达式单位)。实际业务里最典型的坑是月末加一个月。执行：

sql复制SELECT DATE_ADD('2024-01-31', INTERVAL 1 MONTH);

很多人的第一反应是2024-03-02或2024-03-01，但MySQL返回的是2024-02-29。因为1月31日加1个月后，2月没有31日，MySQL自动把结果“校正”到2月最后一天。如果业务要求“满一个月后必须落到固定日期”，这个默认行为就不符合预期，需要在自己业务代码里做特殊处理。

DATEDIFF只计算两个日期之间相差的天数，DATEDIFF('2024-08-20', '2024-08-15')返回5。TIMESTAMPDIFF则更灵活，可以按DAY、HOUR、MINUTE、MONTH等粒度返回差异，但它的参数顺序是TIMESTAMPDIFF(unit, datetime_expr1, datetime_expr2)，返回的是expr2减去expr1的结果。也就是说，DATETIME1在前、DATETIME2在后，和DATEDIFF的常用直觉正好相反，写反了会得到负数。TIMESTAMPDIFF(MONTH, '2024-08-15', '2025-01-10')会返回4，它比较的是真实月份差，不会只看天数。

日期范围统计时，最容易被坑的写法是给日期列包函数。比如统计8月订单：

sql复制-- 不推荐：MONTH(pay_time)上无法有效使用索引
SELECT COUNT(*) FROM user_order WHERE MONTH(pay_time) = 8;

更好的写法是直接用范围比较：

sql复制SELECT COUNT(*) 
FROM user_order 
WHERE pay_time >= '2024-08-01 00:00:00' 
  AND pay_time < '2024-09-01 00:00:00';

这个优化点会在后面索引部分专门展开。

5. 流程控制与条件聚合：用SQL表达业务逻辑的精髓

5.1 CASE WHEN的两种写法和作用范围

CASE WHEN在SQL里的地位类似于编程语言中的if-else。它有两种写法。第一种叫简单CASE，是把一个表达式和多个值依次比较：

sql复制SELECT 
    order_no,
    CASE status
        WHEN 0 THEN '待付款'
        WHEN 1 THEN '已付款'
        WHEN 2 THEN '已发货'
        ELSE '未知状态'
    END AS status_name
FROM user_order;

第二种叫搜索CASE，每个WHEN后面直接跟条件表达式，可以做范围判断：

sql复制SELECT 
    order_no,
    amount,
    CASE 
        WHEN amount >= 1000 THEN '大额订单'
        WHEN amount >= 100 THEN '普通订单'
        ELSE '小额订单'
    END AS amount_level
FROM user_order;

这两种写法的执行逻辑不同。简单CASE只能做等值匹配，搜索CASE可以写任意条件。写业务代码时，如果你需要根据某个字段的多个离散值做翻译，用简单CASE更简洁；如果涉及金额区间、多个字段组合判断，用搜索CASE。

还有一个容易被忽略的点：CASE WHEN没有命中任何分支且没有ELSE时，结果不是原值，而是NULL。如果你没考虑兜底，下游统计SUM时NULL不会计入，COUNT则不会把它算进去，可能导致数据“默默消失”。建议能写ELSE就写ELSE，哪怕兜底值就是“未知”。

5.2 IFNULL、COALESCE、NULLIF：空值兜底里三个隐藏陷阱

IFNULL(expr1, expr2)的语义是：expr1为NULL就返回expr2，否则返回expr1。COALESCE(expr1, expr2, ...)则返回参数列表中第一个非NULL值，它支持多个参数，是SQL标准函数。看起来COALESCE只是IFNULL的强化版，但它们之间有一个关键差异：

IFNULL要求两个参数，COALESCE可以多个。业务上常见的“取第一个有效手机号”逻辑，COALESCE能一行搞定：

sql复制SELECT COALESCE(phone, backup_phone, '无联系方式') AS contact_phone
FROM user_order;

IFNULL对空字符串无能为力。如果列里存的是空字符串而不是NULL，IFNULL(col, '默认值')返回的还是空字符串，因为空字符串不为NULL。想对空字符串也做兜底，正确姿势是用NULLIF先转换：

sql复制SELECT COALESCE(NULLIF(remark, ''), '无备注') AS remark_final
FROM user_order;

NULLIF(expr1, expr2)的作用是当两个表达式相等时返回NULL，否则返回expr1。它经常被用来防止除零。当COUNT()为0时，直接做除法会出现除零错误或NULL，写成SUM(amount) / NULLIF(COUNT(), 0)就能在除数为0时安全得到NULL，下游再做兜底。

5.3 用条件聚合把明细数据变成一维报表

流程控制函数最有价值的应用，是在聚合函数里做条件统计，把“多行明细”折叠成“一行指标”。比如想统计每个用户不同状态下的订单数和金额：

sql复制SELECT 
    user_id,
    COUNT(IF(status = 0, 1, NULL)) AS pending_cnt,
    SUM(CASE WHEN status = 1 THEN amount ELSE 0 END) AS paid_amount,
    SUM(CASE WHEN status = 2 THEN amount ELSE 0 END) AS shipped_amount
FROM user_order
GROUP BY user_id;

这里如果用COUNT(IF(status=0, 1, NULL))，要注意COUNT只统计非NULL值，所以IF的条件分支里，命中时返回1、未命中返回NULL是正确处理；如果写成COUNT(IF(status=0, 1, 0))，它会把未命中的0也统计进去，得到的是全组行数，不是命中数量。SUM里用CASE WHEN条件为真返回amount，否则返回0，逻辑清晰且容易扩展。

这类写法在报表需求中非常普遍。它的核心价值是避免在应用层多次循环查询同一个分组数据。SQL本身有很强的表达能力，把这些转换逻辑放在数据库里，往往比在Java或Python里写一堆循环更简洁、更快。

6. 聚合函数：COUNT、SUM、AVG在分组统计里的隐性差异

6.1 COUNT(*)、COUNT(1)、COUNT(列)与NULL的关系

很多面试题会问COUNT(*)和COUNT(1)的区别。在InnoDB引擎下，它们都统计当前结果集的行数，性能差异几乎可以忽略。真正有区别的是COUNT(列)。COUNT(列)只统计该列不为NULL的行数。

这个差异在业务里的意义很大。比如统计“已填写手机号的用户数”：

sql复制SELECT COUNT(user_id) FROM user_order;
-- 如果user_id是主键，等于统计总行数

SELECT COUNT(phone) FROM user_order;
-- 只会统计phone不为NULL的行，NULL手机号不会被统计

需要注意的是，空字符串不是NULL，所以phone字段如果存了空字符串，COUNT(phone)也会把它统计进去。如果业务上把“空字符串”也视为未填写，就要先做数据清洗：

sql复制SELECT COUNT(NULLIF(phone, '')) FROM user_order;

另外COUNT(DISTINCT col)可以去重统计，COUNT(DISTINCT col1, col2)统计的是组合去重后的行数。多个NULL会被视为同一个值，所以COUNT(DISTINCT phone)不会把多个NULL算成多行。

6.2 SUM和AVG对NULL值的行为

SUM(列)如果遇到整组数据都为NULL，返回结果是NULL而不是0。这个细节经常导致报表里出现空值，前端展示时又没做兜底，最终看板就出现一个空白格子。所以建议统计时统一写IFNULL(SUM(amount), 0)。

AVG(列)在计算时默认忽略NULL值。它“忽略”的意思是：如果一个班级有50人，其中10人缺考，成绩字段为NULL，AVG(score)用的是40个人的总分除以40，而不是除以50。如果业务上想把缺考当0分处理，就需要先转换：

sql复制SELECT AVG(IFNULL(score, 0)) AS avg_score FROM student_score;

这两行SQL的结果可能差出好几分，数据解读方向完全不同。写统计口径时，一定要和业务方确认清楚缺考到底算不算分母。

SUM还有一个隐患：如果传入的是VARCHAR字段，MySQL会做隐式转换。转换规则前面讲过，非数字开头的字符串会转成0。如果某一行数据脏了，比如金额字段误存了“abc”，整条统计结果不会报错，但这个0已经被悄悄加进去了，排查成本极高。要根治这个问题，只能从源头上保证金额字段类型是DECIMAL。

6.3 GROUP_CONCAT统计里的长度截断与性能隐患

GROUP_CONCAT在分组统计里单独提出来讲，是因为它输出的是一个“大文本”，容易触碰到MySQL的限制。

它的默认最大长度是1024字节，受group_concat_max_len参数控制。这个参数可以在会话级动态修改。当拼接结果超过限制时，MySQL不会报错，只会把超出的部分截掉，所以你在报表里看到的结果可能是不完整的。

另外，GROUP_CONCAT通常需要把分组内的多行数据收集起来排序，这个过程会消耗临时表空间。如果单组数据量很大，这个操作可能会成为整个查询的瓶颈。一个折中方案是：不追求一次SQL拼好所有数据，而是只返回明细行的主键或编码，在应用层再根据ID列表去缓存或HBase补全字段。很多大厂的报表服务就是这么做的，并不是所有逻辑都要在SQL里完成。

7. 函数滥用会让索引失效：一个慢查询的排查复盘

7.1 月报表查询为什么全表扫描

有次排查一个订单月报表慢查询，SQL结构大概是这样的：

sql复制SELECT COUNT(*)
FROM user_order
WHERE MONTH(pay_time) = 8 AND YEAR(pay_time) = 2024;

pay_time字段明明建了索引，EXPLAIN结果却显示type=ALL，扫描行数几十万。问题出在MONTH(pay_time)上：B+树索引是按照pay_time的原始值排列的，当查询条件把索引列包进函数后，数据库无法直接根据函数结果去索引树里做范围定位，只能把所有行的pay_time都取出来算一遍MONTH，再判断是否等于8。

这种查询的修复方式不是加索引，而是把条件改写成范围查询：

sql复制SELECT COUNT(*)
FROM user_order
WHERE pay_time >= '2024-08-01 00:00:00'
  AND pay_time < '2024-09-01 00:00:00';

改写后，MySQL可以直接在pay_time索引上做范围扫描，性能立竿见影。排查这类问题的方法也很固定：拿到一条慢SQL后，第一步不是加索引，而是先看WHERE条件里有没有对索引列做函数操作、隐式类型转换、前导通配符LIKE等破坏索引可用性的写法。

7.2 MySQL 8.0函数索引与生成列方案

有些场景确实没法改写成范围条件，比如业务里就是固定要按月分组统计。这时候可以用MySQL 8.0.13引入的函数索引。建索引的语法比较特殊，对表达式需要额外加一层括号：

sql复制CREATE INDEX idx_order_month ON user_order ((DATE_FORMAT(pay_time, '%Y-%m')));

创建之后，DATE_FORMAT(pay_time, '%Y-%m')这个表达式可以直接走索引。它的底层实现其实和虚拟列索引类似，只是给了用户一个更直接的声明方式。

如果是5.7版本，可以显式增加一个生成列，再对生成列建索引：

sql复制ALTER TABLE user_order
ADD COLUMN pay_month VARCHAR(7) 
GENERATED ALWAYS AS (DATE_FORMAT(pay_time, '%Y-%m')) STORED,
ADD INDEX idx_pay_month (pay_month);

STORED列会真实存储计算后的值，占一定磁盘空间；VIRTUAL列则不占用存储，但5.7对VIRTUAL列建索引也有支持。选择哪种方案取决于你的查询比例和空间成本。生成列的好处是查询时可以把它当成普通列来过滤，语法自然，也方便应用层理解。

7.3 隐式类型转换：索引失效的另一种隐蔽形式

函数处理之外，隐式类型转换是另一个容易导致索引失效的元凶，而且它藏得更深。比较常见的情况是：字符串类型的字段和整数常量比较。

比如user_order表里phone字段是VARCHAR，但你执行：

sql复制SELECT * FROM user_order WHERE phone = 13800138000;

MySQL内部会把phone列的字符串值转成数字再比较，索引就失效了。为什么？因为索引存储的是字符串的排序顺序，你要把每个字符串转成数字然后再匹配，无法直接利用原来的字符串索引顺序。正确写法是让常量和字段类型保持一致：

sql复制SELECT * FROM user_order WHERE phone = '13800138000';

还有一种不太显眼但也很常见的问题是字符集不一致导致JOIN无法用索引。一张表是utf8，一张表是utf8mb4，JOIN时MySQL可能