做数据分析的人都知道真正挤占时间的往往不是建模调参而是把乱七八糟的原始表收拾成能用的样子。前阵子接手一张订单明细表缺省值占了一成多手机号格式五花八门日期列里还混着字符串那一刻我才重新正视MySQL数据预处理这件事——它不是跑几条UPDATE就完事而是一整套有顺序、有取舍、有技巧的工程动作。这篇内容适合正在用MySQL做报表、跑数、搭宽表、做特征工程的开发或分析同学。我会按照预处理的分工边界、清洗动作、类型转换与派生字段、性能瓶颈、踩坑排查这条主线展开把我在实际项目里验证过的写法、放弃过的方案和踩过的坑一并写出来希望能给你一套可以直接参考的预处理思路。1. 预处理边界怎么划哪些活该让MySQL干哪些不该让它干1.1 数据库层和应用层的分工本质是成本问题很多刚接触预处理的人会陷入一个误区所有清洗逻辑都往SQL里塞觉得“能在库层解决就不写代码”。反过来另一拨人则认为MySQL只该做存取数据清洗必须交给上层Java、Python。这两种极端我都经历过后来发现真正的判断标准只有一条——计算成本和数据传输成本哪个更大。如果原始数据已经有几千万行应用层每次拉全表都要经过网络传输光是带宽和序列化开销就够喝一壶。这时候把清洗、过滤、聚合放在数据库层让返回结果集变小明显更划算。反过来如果清洗逻辑极其复杂比如要调外部接口、依赖规则引擎、需要多轮上下文判断硬塞进SQL会写出一坨几百行、可读性极差的嵌套子查询维护成本比收益大得多那就该让应用层做。我个人的分工习惯是单表内可描述的、规则固定的、I/O密集型的清洗动作放MySQL多源关联、规则经常变、需要实时决策的放应用层或调度层。预处理不是炫技是让整体链路最省钱、最稳定。1.2 适合放在MySQL里的典型预处理任务MySQL里最常见的预处理任务基本可以收敛成下面这几类。我按使用频率排了个清单你可以对照自己的业务看看任务类型典型动作使用场景缺失值处理COALESCE填充、IFNULL兜底、NULL标记订单金额、用户年龄、渠道来源等字段去重DISTINCT、GROUP BY、ROW_NUMBER窗口函数明细表去重、按用户取最新状态字符清洗TRIM、REPLACE、LOWER/UPPER、正则替换手机号、地址、备注字段的格式统一类型转换CAST、CONVERT、日期格式化字符串日期转DATE、字符串数字转DECIMAL派生字段CASE WHEN打标签、日期函数提取年月年龄段、订单时段、是否新客等特征异常值修正范围过滤、阈值替换剔除负数金额、修正超长文本排序与分桶ORDER BY后编号、NTILE分桶排行榜、评分区间划分这些任务有一个共同点规则明确、单遍扫描可完成、不依赖外部信息。把它们放在MySQL里既能享受索引和引擎层的优化也能避免大表全量拉取的网络压力。2. 清洗第一步NULL、去重和字符归一化的几种写法与取舍2.1 NULL不是垃圾值先分类再决定怎么处理面对NULL新手最容易犯的错就是“直接删掉”。但实际上NULL在业务里的含义可能是“用户没填”也可能是“系统没采集到”这两者的处理策略完全不同。我在某个用户画像项目里就把“注册渠道”字段的NULL拆成了两条老用户历史数据没记录的统一填充为unknown新用户漏传的则标记为late_fill后续分析口径完全不一样。处理NULL的第一步是先统计分布搞清楚NULL的规模。用这个SQL能快速看占比SELECT COUNT(*) AS total_rows, SUM(CASE WHEN user_phone IS NULL THEN 1 ELSE 0 END) AS null_phone, SUM(CASE WHEN user_phone IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_ratio FROM user_profile;知道占比之后再决定用哪种处理方式业务默认值填充比如未知渠道填unknown、积分默认0用COALESCE(channel, unknown)或IFNULL(score, 0)。统计值填充中位数或均值填充只适合数值型常用于金额、时长字段但要注意填充后对分布的影响。保留NULL如果NULL本身承载业务信息就不该填。MySQL里NULL的判断要用IS NULL不要写成 NULL这点经常有人栽跟头。还有一个小细节如果后续要用GROUP BY做聚合NULL会被单独分成一组。如果不想让“未知”和“缺失”混在一个桶里预处理阶段最好先把NULL替换成显式值再打标签或分组。2.2 去重前先想清楚“重复”的定义去重看似简单一个DISTINCT就能跑但实际操作里最容易翻车的是——你没有先定义什么叫重复。比如订单表里同一用户在同一秒下了两单这两行是重复吗不一定。如果业务上允许同一秒产生多笔订单那它们就是合法记录。再比如用户表里一个用户出现两次但一次手机号填了139开头一次填了138开头按手机号判断是两个人按用户ID判断是同一个人。去重的维度一旦选错后面所有统计都会失真。我常用的去重思路是先写一条计数SQL验证重复规模再决定处理方案-- 先看按业务主键统计的重复情况 SELECT user_id, order_no, COUNT(*) AS dup_cnt FROM order_detail GROUP BY user_id, order_no HAVING COUNT(*) 1 LIMIT 20;如果确实要保留每组里最新的一条用窗口函数更可控DELETE FROM order_detail WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id, order_no ORDER BY create_time DESC) AS rn FROM order_detail ) t WHERE t.rn 1 );注意MySQL版本要在8.0以上才支持窗口函数5.7及以下得用连接子查询或者临时表绕一下。另外DISTINCT看起来简单但它是对查询结果集的去重如果表里有唯一主键而是某几个业务字段重复DISTINCT是帮不上忙的必须按业务维度重新分组。2.3 字符归一化JOIN前最容易翻车的一环字符清洗看着不起眼但往往是JOIN对不上的头号原因。我遇到过的真实案例两张表的用户手机号一张存的是“139 1234 5678”带空格一张存的是“13912345678”还有一张表的渠道字段是全角冒号“来源”另一张是半角“:来源”JOIN的时候怎么都对不上排查半天才发现是字符差异。字符归一化要做到位至少得覆盖这几个动作去首尾空白TRIM(column)。统一大小写账号、邮箱、英文名统一LOWER()或UPPER()避免大小写差异导致匹配失败。替换特定字符把全角数字、全角标点转半角用REPLACE(REPLACE(column, , :), , ,)逐层替换。清理内部多余空格REGEXP_REPLACE(column, \\s, )MySQL 8.0。固定长度格式化手机号统一去掉空格和横杠再拼接成统一格式。我一般会把字符清洗写成一条预处理SQL落成新的清洗列而不是反复在原字段上update。原因很简单保留原始值出问题还能回溯直接覆盖原字段一旦清洗规则判断错误原始数据就丢了恢复成本极高。3. 类型转换与派生字段把原始表收拾成可以直接建模的宽表3.1 类型转换的隐形坑隐式转换会让索引失效很多预处理要处理“类型不对”的字段比如日期列实际存的是字符串金额列里混着千分位逗号。最常见的类型转换是CAST和CONVERT-- 字符串日期转DATE类型 SELECT CAST(order_date AS DATE) FROM order_detail; -- 字符串数字转DECIMAL SELECT CAST(amount AS DECIMAL(10, 2)) FROM order_detail;真正要警惕的是隐式转换。如果某列是字符串类型但里面存的全是数字你直接和数值去比较WHERE user_phone 13912345678MySQL会把字符串转成数字去比较。一旦列上建有索引这种写法会导致索引失效因为引擎得先对每一行做转换再比较全表扫描就来了。我自己踩过的案例是某张表的user_id被建成VARCHAR业务侧传参时没加引号结果一个简单等值查询跑到800多毫秒。EXPLAIN查出来是类型转换导致索引失效改成WHERE user_id 123456之后毫秒级返回。所以类型转换要注意的不仅是SQL怎么写更要确认关联字段两侧的类型是否一致不一致时宁可先显式CAST也别依赖MySQL的隐式规则。3.2 CASE WHEN和日期函数生成派生字段预处理里很大一部分工作是“造字段”——把原始字段加工成业务可解读的标签。最常用的就是CASE WHEN配合日期函数、字符串函数一起用。举个例子从用户表生成年龄段、注册时间段、活跃等级三个特征SELECT user_id, CASE WHEN age 18 THEN 未成年 WHEN age BETWEEN 18 AND 29 THEN 青年 WHEN age BETWEEN 30 AND 45 THEN 中年 ELSE 高龄 END AS age_group, CASE WHEN YEAR(register_time) 2021 THEN 2021年新客 WHEN YEAR(register_time) 2022 THEN 2022年新客 ELSE 老客 END AS register_cohort, CASE WHEN last_login_days 30 THEN 沉睡用户 WHEN last_login_days BETWEEN 8 AND 30 THEN 活跃下降 ELSE 高活跃 END AS active_level, DATE_FORMAT(order_time, %Y-%m) AS order_month FROM user_profile;这类派生字段有几个要点日期函数YEAR()、MONTH()、DATE_FORMAT()在数据量大的时候计算开销不小如果这个字段每次查询都要算不如在预处理阶段物化成物理列直接建索引。CASE WHEN的排列顺序要看清楚MySQL从上到下匹配命中了就停所以范围的先后顺序不能乱否则会把数据分错桶。预处理产出的派生字段一定要保持命名口径和业务定义一致。我见过一个项目里“活跃用户”在A表是30天内登录在B表是7天内登录最后两个口径的数据对不上吵了一个星期才定位到是定义不一致。这个锅不在SQL但也从侧面说明预处理必须要维护一份口径文档。3.3 预处理的产出到底该落成物理列还是视图派生字段算完之后要决定是直接改成物理表结构还是用视图每次实时计算。我的判断标准很简单字段的稳定性和查询频次。如果这个字段是稳定口径、每天都要用、要被多个报表拉取就物化成物理列比如在原始表上ALTER TABLE ADD COLUMN age_group VARCHAR(20)然后一次性UPDATE填充。物化列的好处是后续查询可以直接走索引坏处是多占存储、更新时有额外开销。如果字段口径还在探索期或者只给一个临时的探索分析用就建视图CREATE OR REPLACE VIEW v_user_profile AS SELECT user_id, CASE ... END AS age_group, ... FROM user_profile;视图的优点是零存储成本、口径改动方便缺点是每次查询都要实时计算数据量一大就拖慢速度。实践里我经常是先用视图跑通逻辑、核对结果确认口径没问题之后再物化成物理列双保险推进。4. 预处理跑不快的时候我先查这些地方4.1 用EXPLAIN确认预处理慢在哪一步预处理SQL跑得慢第一反应不是改SQL而是先看执行计划。EXPLAIN的输出里我最关心的几个字段是type、key、rows、Extra。type如果是ALL说明在走全表扫描。数据量大时就要考虑是否能用索引、是否要把过滤条件下推。key显示NULL说明索引没用上。rows是预估扫描行数和实际差异很大的时候统计信息和实际数据可能偏差大需要ANALYZE TABLE刷新一下。Extra里出现Using filesort、Using temporary大概率是排序或分组没优化好。一个常见例子预处理要按用户分组取最新订单写成子查询加ORDER BY create_time DESC可能会触发临时表和文件排序很慢。看到Using temporary之后我一般会改成窗口函数写法或者给user_id和create_time建组合索引效果立竿见影。4.2 临时表、内存参数和批量方式的调整预处理经常涉及中间结果MySQL会在内存里建临时表内存不够就落盘落盘之后性能断崖式下降。如果发现SQL里有大量GROUP BY、DISTINCT、ORDER BY并且系统内存还够可以适当调大临时表上限tmp_table_size 64M max_heap_table_size 64M注意tmp_table_size和max_heap_table_size实际生效时取两者较小值。我一般不推荐把这个参数调得过大因为并发高的时候一个会话吃几百MB内存其他会话就被挤爆了。更稳妥的做法是减少临时表出现能用索引覆盖的排序就不让filesort能拆成两段处理的不硬塞在一个SQL里。另一个调整思路是用SELECT ... INTO OUTFILE或者CREATE TABLE AS SELECT把预处理中间结果落成独立小表让后续查询走物理表索引。比如先把几千万行原始数据清洗成几百万行宽表后续所有报表都查宽表而不是每次都对着原表做同样的清洗计算。4.3 大数据量下的分批UPDATE与快照一致性预处理里不可避免要跑大批量的UPDATE。几千万行的单条UPDATE很危险一是事务太大回滚日志和锁持有时间都非常长二是一旦中途失败回滚可能比更新本身还慢。我常用的做法是按主键范围分批更新每一批提交一个小事务-- 每批处理10万行 UPDATE order_detail SET age_group CASE ... END WHERE id BETWEEN 1 AND 100000; UPDATE order_detail SET age_group CASE ... END WHERE id BETWEEN 100001 AND 200000;如果主键不是均匀分布的用LIMIT配合循环也行但要注意LIMIT的扫描起点会越来越靠后效率不一定好。更稳妥的是先SELECT出主键范围再做区间更新。整个过程我会用一个循环脚本来控制每批之间稍微停几毫秒避免压垮主库。涉及多表联动更新时要考虑快照一致性。比如把A表清洗后的结果同步到B表INSERT ... SELECT默认是读已提交的快照但如果源表在复制过程中发生变化目标表可能和源表不一致。对于关键业务表我一般会选择低峰期执行或者先锁源表再同步保证两表数据一致后立刻释放。5. 预处理跑崩跑错后的排查链路三个高频事故复盘5.1 事故一UPDATE卡住、锁等待飙升某次我对一张三千万行的订单表做字段填充一条UPDATE扔上去之后等了五分钟还没结束紧接着业务方反馈其他查询全被堵住了。我第一时间查了当前事务和锁等待-- 查看当前正在执行的事务 SELECT * FROM information_schema.innodb_trx\G -- 查看锁等待情况 SELECT * FROM sys.innodb_lock_waits\G排查结果我那条UPDATE走了全表扫描逐行锁定了大量记录而其他业务查询要读同一批行全部卡在锁等待上。根本原因有两个一是UPDATE的WHERE条件没有走索引二是单条UPDATE事务太大所有更新在一个事务里提交。修复方案很简单WHERE条件改成主键范围分批更新。每个批次控制在5万到10万行每批独立COMMIT。跑完之后锁等待立刻消失。这个事故让我记住一条铁律大表UPDATE必须有索引条件必须分批提交宁可多写几行循环代码也不要在线上赌一条巨型SQL。5.2 事故二预处理结果和预期对不上有一次做日期预处理把字符串日期2023-01-01转成DATE类型统计出来的月度订单量和报表系统差了整整一天。排查链路是这样的第一步我先单独跑一条SQL看转换结果SELECT order_date, CAST(order_date AS DATE) AS cast_date FROM order_detail WHERE id 1000;结果发现部分行的order_date不是正常的YYYY-MM-DD格式而是2023/1/1这种斜杠格式CAST之后变成NULL数据直接丢了。根源是上游导入数据时读了一个混合格式的Excel日期列既有一到两位的月份也有斜杠分隔。第二步验证格式分布SELECT CASE WHEN order_date REGEXP ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ THEN 标准格式 WHEN order_date REGEXP ^[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}$ THEN 斜杠格式 ELSE 其他 END AS fmt, COUNT(*) FROM order_detail GROUP BY fmt;确认之后我在预处理脚本里先做格式统一UPDATE order_detail SET order_date REPLACE(order_date, /, -) WHERE order_date LIKE %/%.%;后面再CAST数据就对上了。这类问题的核心是预处理不只处理“干净”的数据更要处理“脏”的数据并且要在转换前先验证数据格式分布否则你以为转换成功了实际丢了一部分都没发现。5.3 事故三去重后数据量明显偏低还有一次我用SELECT COUNT(DISTINCT user_id)统计去重用户数结果比业务方给出的预期少了近15%。当时第一反应是“业务方口径错了”后来仔细排查问题出在我的口径上。我的写法是直接对user_id去重但部分老数据里的user_id是NULL。MySQL的COUNT(DISTINCT user_id)不会统计NULL值所以这些行直接消失了。而业务方的口径是“注册过的用户都算”NULl实际上代表的是没有绑定账号的历史访客不应该算进用户数也不该被当成同一人合并。修正后的做法是先把NULL替换成显式业务编码再参与去重统计SELECT COUNT(DISTINCT COALESCE(user_id, visitor_ || session_id)) AS valid_users FROM user_event_log;这个事故说明统计函数的语义、NULL的处理方式、业务口径这三者必须对齐。预处理阶段如果没把NULL归一化后面所有聚合统计都可能出偏差而且这种偏差非常隐蔽不逐项核对很难发现。最后分享两个预处理的小技巧排查过这么多次之后我养成了两个习惯对你应该也有用。第一个习惯是所有预处理脚本都写成可重入的。也就是说同一套清洗脚本跑两遍结果不会变不会因为重跑导致数据翻倍或重复更新。实现方式很简单UPDATE语句加条件幂等写入插入动作先按业务主键删除再插入。第二个习惯是先做小样本验证再全量跑。不管SQL逻辑写得多自信我都先加一个LIMIT 10000或者按id 100000跑一遍肉眼核对结果确认口径没问题之后再放开全量。别看这一步多花几分钟它能省下你后面排查几小时甚至几天的功夫。数据预处理永远不是“写完SQL就结束”它是一个反复验证、逐步收敛的过程而那些脏数据会在你每一次粗心大意的时候悄悄给你上一课。 
长河君 · 2026/10/19 6:25:34 · 阅读 1.2k MySQL数据预处理实战：从清洗到性能优化的完整指南
做数据分析的人都知道真正挤占时间的往往不是建模调参而是把乱七八糟的原始表收拾成能用的样子。前阵子接手一张订单明细表缺省值占了一成多手机号格式五花八门日期列里还混着字符串那一刻我才重新正视MySQL数据预处理这件事——它不是跑几条UPDATE就完事而是一整套有顺序、有取舍、有技巧的工程动作。这篇内容适合正在用MySQL做报表、跑数、搭宽表、做特征工程的开发或分析同学。我会按照预处理的分工边界、清洗动作、类型转换与派生字段、性能瓶颈、踩坑排查这条主线展开把我在实际项目里验证过的写法、放弃过的方案和踩过的坑一并写出来希望能给你一套可以直接参考的预处理思路。1. 预处理边界怎么划哪些活该让MySQL干哪些不该让它干1.1 数据库层和应用层的分工本质是成本问题很多刚接触预处理的人会陷入一个误区所有清洗逻辑都往SQL里塞觉得“能在库层解决就不写代码”。反过来另一拨人则认为MySQL只该做存取数据清洗必须交给上层Java、Python。这两种极端我都经历过后来发现真正的判断标准只有一条——计算成本和数据传输成本哪个更大。如果原始数据已经有几千万行应用层每次拉全表都要经过网络传输光是带宽和序列化开销就够喝一壶。这时候把清洗、过滤、聚合放在数据库层让返回结果集变小明显更划算。反过来如果清洗逻辑极其复杂比如要调外部接口、依赖规则引擎、需要多轮上下文判断硬塞进SQL会写出一坨几百行、可读性极差的嵌套子查询维护成本比收益大得多那就该让应用层做。我个人的分工习惯是单表内可描述的、规则固定的、I/O密集型的清洗动作放MySQL多源关联、规则经常变、需要实时决策的放应用层或调度层。预处理不是炫技是让整体链路最省钱、最稳定。1.2 适合放在MySQL里的典型预处理任务MySQL里最常见的预处理任务基本可以收敛成下面这几类。我按使用频率排了个清单你可以对照自己的业务看看任务类型典型动作使用场景缺失值处理COALESCE填充、IFNULL兜底、NULL标记订单金额、用户年龄、渠道来源等字段去重DISTINCT、GROUP BY、ROW_NUMBER窗口函数明细表去重、按用户取最新状态字符清洗TRIM、REPLACE、LOWER/UPPER、正则替换手机号、地址、备注字段的格式统一类型转换CAST、CONVERT、日期格式化字符串日期转DATE、字符串数字转DECIMAL派生字段CASE WHEN打标签、日期函数提取年月年龄段、订单时段、是否新客等特征异常值修正范围过滤、阈值替换剔除负数金额、修正超长文本排序与分桶ORDER BY后编号、NTILE分桶排行榜、评分区间划分这些任务有一个共同点规则明确、单遍扫描可完成、不依赖外部信息。把它们放在MySQL里既能享受索引和引擎层的优化也能避免大表全量拉取的网络压力。2. 清洗第一步NULL、去重和字符归一化的几种写法与取舍2.1 NULL不是垃圾值先分类再决定怎么处理面对NULL新手最容易犯的错就是“直接删掉”。但实际上NULL在业务里的含义可能是“用户没填”也可能是“系统没采集到”这两者的处理策略完全不同。我在某个用户画像项目里就把“注册渠道”字段的NULL拆成了两条老用户历史数据没记录的统一填充为unknown新用户漏传的则标记为late_fill后续分析口径完全不一样。处理NULL的第一步是先统计分布搞清楚NULL的规模。用这个SQL能快速看占比SELECT COUNT(*) AS total_rows, SUM(CASE WHEN user_phone IS NULL THEN 1 ELSE 0 END) AS null_phone, SUM(CASE WHEN user_phone IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_ratio FROM user_profile;知道占比之后再决定用哪种处理方式业务默认值填充比如未知渠道填unknown、积分默认0用COALESCE(channel, unknown)或IFNULL(score, 0)。统计值填充中位数或均值填充只适合数值型常用于金额、时长字段但要注意填充后对分布的影响。保留NULL如果NULL本身承载业务信息就不该填。MySQL里NULL的判断要用IS NULL不要写成 NULL这点经常有人栽跟头。还有一个小细节如果后续要用GROUP BY做聚合NULL会被单独分成一组。如果不想让“未知”和“缺失”混在一个桶里预处理阶段最好先把NULL替换成显式值再打标签或分组。2.2 去重前先想清楚“重复”的定义去重看似简单一个DISTINCT就能跑但实际操作里最容易翻车的是——你没有先定义什么叫重复。比如订单表里同一用户在同一秒下了两单这两行是重复吗不一定。如果业务上允许同一秒产生多笔订单那它们就是合法记录。再比如用户表里一个用户出现两次但一次手机号填了139开头一次填了138开头按手机号判断是两个人按用户ID判断是同一个人。去重的维度一旦选错后面所有统计都会失真。我常用的去重思路是先写一条计数SQL验证重复规模再决定处理方案-- 先看按业务主键统计的重复情况 SELECT user_id, order_no, COUNT(*) AS dup_cnt FROM order_detail GROUP BY user_id, order_no HAVING COUNT(*) 1 LIMIT 20;如果确实要保留每组里最新的一条用窗口函数更可控DELETE FROM order_detail WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id, order_no ORDER BY create_time DESC) AS rn FROM order_detail ) t WHERE t.rn 1 );注意MySQL版本要在8.0以上才支持窗口函数5.7及以下得用连接子查询或者临时表绕一下。另外DISTINCT看起来简单但它是对查询结果集的去重如果表里有唯一主键而是某几个业务字段重复DISTINCT是帮不上忙的必须按业务维度重新分组。2.3 字符归一化JOIN前最容易翻车的一环字符清洗看着不起眼但往往是JOIN对不上的头号原因。我遇到过的真实案例两张表的用户手机号一张存的是“139 1234 5678”带空格一张存的是“13912345678”还有一张表的渠道字段是全角冒号“来源”另一张是半角“:来源”JOIN的时候怎么都对不上排查半天才发现是字符差异。字符归一化要做到位至少得覆盖这几个动作去首尾空白TRIM(column)。统一大小写账号、邮箱、英文名统一LOWER()或UPPER()避免大小写差异导致匹配失败。替换特定字符把全角数字、全角标点转半角用REPLACE(REPLACE(column, , :), , ,)逐层替换。清理内部多余空格REGEXP_REPLACE(column, \\s, )MySQL 8.0。固定长度格式化手机号统一去掉空格和横杠再拼接成统一格式。我一般会把字符清洗写成一条预处理SQL落成新的清洗列而不是反复在原字段上update。原因很简单保留原始值出问题还能回溯直接覆盖原字段一旦清洗规则判断错误原始数据就丢了恢复成本极高。3. 类型转换与派生字段把原始表收拾成可以直接建模的宽表3.1 类型转换的隐形坑隐式转换会让索引失效很多预处理要处理“类型不对”的字段比如日期列实际存的是字符串金额列里混着千分位逗号。最常见的类型转换是CAST和CONVERT-- 字符串日期转DATE类型 SELECT CAST(order_date AS DATE) FROM order_detail; -- 字符串数字转DECIMAL SELECT CAST(amount AS DECIMAL(10, 2)) FROM order_detail;真正要警惕的是隐式转换。如果某列是字符串类型但里面存的全是数字你直接和数值去比较WHERE user_phone 13912345678MySQL会把字符串转成数字去比较。一旦列上建有索引这种写法会导致索引失效因为引擎得先对每一行做转换再比较全表扫描就来了。我自己踩过的案例是某张表的user_id被建成VARCHAR业务侧传参时没加引号结果一个简单等值查询跑到800多毫秒。EXPLAIN查出来是类型转换导致索引失效改成WHERE user_id 123456之后毫秒级返回。所以类型转换要注意的不仅是SQL怎么写更要确认关联字段两侧的类型是否一致不一致时宁可先显式CAST也别依赖MySQL的隐式规则。3.2 CASE WHEN和日期函数生成派生字段预处理里很大一部分工作是“造字段”——把原始字段加工成业务可解读的标签。最常用的就是CASE WHEN配合日期函数、字符串函数一起用。举个例子从用户表生成年龄段、注册时间段、活跃等级三个特征SELECT user_id, CASE WHEN age 18 THEN 未成年 WHEN age BETWEEN 18 AND 29 THEN 青年 WHEN age BETWEEN 30 AND 45 THEN 中年 ELSE 高龄 END AS age_group, CASE WHEN YEAR(register_time) 2021 THEN 2021年新客 WHEN YEAR(register_time) 2022 THEN 2022年新客 ELSE 老客 END AS register_cohort, CASE WHEN last_login_days 30 THEN 沉睡用户 WHEN last_login_days BETWEEN 8 AND 30 THEN 活跃下降 ELSE 高活跃 END AS active_level, DATE_FORMAT(order_time, %Y-%m) AS order_month FROM user_profile;这类派生字段有几个要点日期函数YEAR()、MONTH()、DATE_FORMAT()在数据量大的时候计算开销不小如果这个字段每次查询都要算不如在预处理阶段物化成物理列直接建索引。CASE WHEN的排列顺序要看清楚MySQL从上到下匹配命中了就停所以范围的先后顺序不能乱否则会把数据分错桶。预处理产出的派生字段一定要保持命名口径和业务定义一致。我见过一个项目里“活跃用户”在A表是30天内登录在B表是7天内登录最后两个口径的数据对不上吵了一个星期才定位到是定义不一致。这个锅不在SQL但也从侧面说明预处理必须要维护一份口径文档。3.3 预处理的产出到底该落成物理列还是视图派生字段算完之后要决定是直接改成物理表结构还是用视图每次实时计算。我的判断标准很简单字段的稳定性和查询频次。如果这个字段是稳定口径、每天都要用、要被多个报表拉取就物化成物理列比如在原始表上ALTER TABLE ADD COLUMN age_group VARCHAR(20)然后一次性UPDATE填充。物化列的好处是后续查询可以直接走索引坏处是多占存储、更新时有额外开销。如果字段口径还在探索期或者只给一个临时的探索分析用就建视图CREATE OR REPLACE VIEW v_user_profile AS SELECT user_id, CASE ... END AS age_group, ... FROM user_profile;视图的优点是零存储成本、口径改动方便缺点是每次查询都要实时计算数据量一大就拖慢速度。实践里我经常是先用视图跑通逻辑、核对结果确认口径没问题之后再物化成物理列双保险推进。4. 预处理跑不快的时候我先查这些地方4.1 用EXPLAIN确认预处理慢在哪一步预处理SQL跑得慢第一反应不是改SQL而是先看执行计划。EXPLAIN的输出里我最关心的几个字段是type、key、rows、Extra。type如果是ALL说明在走全表扫描。数据量大时就要考虑是否能用索引、是否要把过滤条件下推。key显示NULL说明索引没用上。rows是预估扫描行数和实际差异很大的时候统计信息和实际数据可能偏差大需要ANALYZE TABLE刷新一下。Extra里出现Using filesort、Using temporary大概率是排序或分组没优化好。一个常见例子预处理要按用户分组取最新订单写成子查询加ORDER BY create_time DESC可能会触发临时表和文件排序很慢。看到Using temporary之后我一般会改成窗口函数写法或者给user_id和create_time建组合索引效果立竿见影。4.2 临时表、内存参数和批量方式的调整预处理经常涉及中间结果MySQL会在内存里建临时表内存不够就落盘落盘之后性能断崖式下降。如果发现SQL里有大量GROUP BY、DISTINCT、ORDER BY并且系统内存还够可以适当调大临时表上限tmp_table_size 64M max_heap_table_size 64M注意tmp_table_size和max_heap_table_size实际生效时取两者较小值。我一般不推荐把这个参数调得过大因为并发高的时候一个会话吃几百MB内存其他会话就被挤爆了。更稳妥的做法是减少临时表出现能用索引覆盖的排序就不让filesort能拆成两段处理的不硬塞在一个SQL里。另一个调整思路是用SELECT ... INTO OUTFILE或者CREATE TABLE AS SELECT把预处理中间结果落成独立小表让后续查询走物理表索引。比如先把几千万行原始数据清洗成几百万行宽表后续所有报表都查宽表而不是每次都对着原表做同样的清洗计算。4.3 大数据量下的分批UPDATE与快照一致性预处理里不可避免要跑大批量的UPDATE。几千万行的单条UPDATE很危险一是事务太大回滚日志和锁持有时间都非常长二是一旦中途失败回滚可能比更新本身还慢。我常用的做法是按主键范围分批更新每一批提交一个小事务-- 每批处理10万行 UPDATE order_detail SET age_group CASE ... END WHERE id BETWEEN 1 AND 100000; UPDATE order_detail SET age_group CASE ... END WHERE id BETWEEN 100001 AND 200000;如果主键不是均匀分布的用LIMIT配合循环也行但要注意LIMIT的扫描起点会越来越靠后效率不一定好。更稳妥的是先SELECT出主键范围再做区间更新。整个过程我会用一个循环脚本来控制每批之间稍微停几毫秒避免压垮主库。涉及多表联动更新时要考虑快照一致性。比如把A表清洗后的结果同步到B表INSERT ... SELECT默认是读已提交的快照但如果源表在复制过程中发生变化目标表可能和源表不一致。对于关键业务表我一般会选择低峰期执行或者先锁源表再同步保证两表数据一致后立刻释放。5. 预处理跑崩跑错后的排查链路三个高频事故复盘5.1 事故一UPDATE卡住、锁等待飙升某次我对一张三千万行的订单表做字段填充一条UPDATE扔上去之后等了五分钟还没结束紧接着业务方反馈其他查询全被堵住了。我第一时间查了当前事务和锁等待-- 查看当前正在执行的事务 SELECT * FROM information_schema.innodb_trx\G -- 查看锁等待情况 SELECT * FROM sys.innodb_lock_waits\G排查结果我那条UPDATE走了全表扫描逐行锁定了大量记录而其他业务查询要读同一批行全部卡在锁等待上。根本原因有两个一是UPDATE的WHERE条件没有走索引二是单条UPDATE事务太大所有更新在一个事务里提交。修复方案很简单WHERE条件改成主键范围分批更新。每个批次控制在5万到10万行每批独立COMMIT。跑完之后锁等待立刻消失。这个事故让我记住一条铁律大表UPDATE必须有索引条件必须分批提交宁可多写几行循环代码也不要在线上赌一条巨型SQL。5.2 事故二预处理结果和预期对不上有一次做日期预处理把字符串日期2023-01-01转成DATE类型统计出来的月度订单量和报表系统差了整整一天。排查链路是这样的第一步我先单独跑一条SQL看转换结果SELECT order_date, CAST(order_date AS DATE) AS cast_date FROM order_detail WHERE id 1000;结果发现部分行的order_date不是正常的YYYY-MM-DD格式而是2023/1/1这种斜杠格式CAST之后变成NULL数据直接丢了。根源是上游导入数据时读了一个混合格式的Excel日期列既有一到两位的月份也有斜杠分隔。第二步验证格式分布SELECT CASE WHEN order_date REGEXP ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ THEN 标准格式 WHEN order_date REGEXP ^[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}$ THEN 斜杠格式 ELSE 其他 END AS fmt, COUNT(*) FROM order_detail GROUP BY fmt;确认之后我在预处理脚本里先做格式统一UPDATE order_detail SET order_date REPLACE(order_date, /, -) WHERE order_date LIKE %/%.%;后面再CAST数据就对上了。这类问题的核心是预处理不只处理“干净”的数据更要处理“脏”的数据并且要在转换前先验证数据格式分布否则你以为转换成功了实际丢了一部分都没发现。5.3 事故三去重后数据量明显偏低还有一次我用SELECT COUNT(DISTINCT user_id)统计去重用户数结果比业务方给出的预期少了近15%。当时第一反应是“业务方口径错了”后来仔细排查问题出在我的口径上。我的写法是直接对user_id去重但部分老数据里的user_id是NULL。MySQL的COUNT(DISTINCT user_id)不会统计NULL值所以这些行直接消失了。而业务方的口径是“注册过的用户都算”NULl实际上代表的是没有绑定账号的历史访客不应该算进用户数也不该被当成同一人合并。修正后的做法是先把NULL替换成显式业务编码再参与去重统计SELECT COUNT(DISTINCT COALESCE(user_id, visitor_ || session_id)) AS valid_users FROM user_event_log;这个事故说明统计函数的语义、NULL的处理方式、业务口径这三者必须对齐。预处理阶段如果没把NULL归一化后面所有聚合统计都可能出偏差而且这种偏差非常隐蔽不逐项核对很难发现。最后分享两个预处理的小技巧排查过这么多次之后我养成了两个习惯对你应该也有用。第一个习惯是所有预处理脚本都写成可重入的。也就是说同一套清洗脚本跑两遍结果不会变不会因为重跑导致数据翻倍或重复更新。实现方式很简单UPDATE语句加条件幂等写入插入动作先按业务主键删除再插入。第二个习惯是先做小样本验证再全量跑。不管SQL逻辑写得多自信我都先加一个LIMIT 10000或者按id 100000跑一遍肉眼核对结果确认口径没问题之后再放开全量。别看这一步多花几分钟它能省下你后面排查几小时甚至几天的功夫。数据预处理永远不是“写完SQL就结束”它是一个反复验证、逐步收敛的过程而那些脏数据会在你每一次粗心大意的时候悄悄给你上一课。