mysql函数在查询中如何提高性能_mysql查询优化技巧

应避免在where子句中对索引列使用函数，如year(create_time)=2024会导致全表扫描；应改写为范围查询：where create_time >= '2024-01-01' and create_time

避免在 WHERE 子句中对字段使用函数

直接在索引列上套函数（比如 WHERE YEAR(create_time) = 2024）会让 MySQL 无法使用该列上的索引，导致全表扫描。哪怕 create_time 有 B+ 树索引，YEAR() 一包，优化器就放弃走索引。

• 改写为范围查询：WHERE create_time >= '2024-01-01' AND create_time
• 对日期做分区表时，也优先按 DATE 或 DATETIME 值本身分区，而非提取年/月后分区
• 如果业务强依赖 MONTH(created_at) 查询，考虑增加生成列并建索引：ALTER TABLE t ADD COLUMN created_month TINYINT AS (MONTH(created_at)) STORED, ADD INDEX idx_created_month (created_month)

用 JSON_EXTRACT 前先确认是否真需要 JSON 字段

MySQL 对 JSON 字段的查询性能天然受限——即使加了虚拟列和索引，JSON_EXTRACT() 仍涉及解析开销，且无法做前缀匹配或范围扫描。

Removal.AI

AI移出图片背景工具

下载

• 简单键值结构（如状态、类型、开关）优先用普通字段，别为了“灵活”全塞进 JSON
• 必须用 JSON 时，对高频查询路径建虚拟列：ALTER TABLE t ADD COLUMN status VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.status'))) STORED, ADD INDEX idx_status (status)
• JSON_CONTAINS() 比多次 JSON_EXTRACT() + 比较更高效，但只适用于存在性判断，不适用数值比较

GROUP_CONCAT 的长度与排序陷阱

GROUP_CONCAT 默认最大长度是 1024 字符，超长会被截断，且默认不保证顺序——这在分页或导出场景下容易引发数据不一致。

• 显式设置长度：SET SESSION group_concat_max_len = 1000000（注意不能超过 max_allowed_packet）
• 强制排序：GROUP_CONCAT(id ORDER BY updated_at DESC SEPARATOR ',')，否则结果顺序由执行计划决定，不可靠
• 避免在大结果集上用 GROUP_CONCAT(DISTINCT ...)，去重逻辑会显著拖慢聚合速度

自定义函数（UDF）和存储函数几乎从不提升查询性能

MySQL 的用户自定义函数（UDF）或存储函数（CREATE FUNCTION）在 SELECT 中调用时，是逐行执行的，无法下推到引擎层，也没有向量化支持。

• 比如把时间戳转中文星期写成函数：get_weekday(ts)，比直接用 DAYNAME(FROM_UNIXTIME(ts)) 还慢
• 函数内含 SQL 查询（即“函数里再查表”）会触发 N+1 问题，且无法被查询缓存覆盖
• 真正要提速，应把逻辑前置到应用层，或用物化视图（通过定时任务+汇总表模拟）替代运行时计算

MySQL 函数本身不慢，慢的是它们打断了索引利用、阻断了优化器决策、还常把计算压力留在查询执行期——关键不是“能不能用”，而是“有没有必要在这一层算”。