简介：双色球自2003年2月23日首期开售至2025年4月15日全部3287期开奖记录，已按时间顺序完整整理为一份轻量数据包，面向需要批量获取历史号码的趋势分析、频次统计或预测建模用户，能有效省去手工收集与清洗校验的繁琐环节。压缩包共5个文件，核心为一个Excel工作簿和一个可直接导入MySQL的SQL脚本，前者便于筛选排序、数据透视与图表制作，后者适合执行复杂查询和深度统计；另附一个Python辅助脚本及工程配置文件，为二次开发与自动化处理提供便利。每期均包含期号、开奖日期、6个红球（1-33）与1个蓝球（1-16），数据无缺失、无重复，可直接用于冷热号追踪、连号/区间分布、号码频次分析等场景，也可作为自建预测模型的基础训练集。整个压缩包仅约213KB，轻巧便携，目前已有1602人学习下载，适合Excel、MySQL及Python用户快速开展历史开奖数据的整理、挖掘与验证。
1. 为什么盯上这份2003-2025双色球开奖记录：一个能练手又能做分析的数据包
做数据分析或数据库练习的人，最缺的往往不是教程，而是一份真实、干净、量级刚好合适的数据。这份 2003-2025 双色球全部开奖记录，共 3287 期，同时打包了 Excel 和 MySQL 数据文件，恰好把缺口补上了。下载后你既能丢进 MySQL 练查询、写存储过程、做联表统计，也能用 Excel 练筛选、透视表和函数公式；如果你正在学 JavaWeb 项目开发，它还能直接当种子数据喂给 SpringBoot4 + Mybatis 的查询接口。这篇笔记会从表结构设计、导入验证、Excel 清洗讲到容易翻车的几个坑，最后送你一个我常用的两套文件一致性校验方法。
2. 拆解开奖记录数据包：字段含义与 MySQL 表结构设计
2.1 双色球开奖记录的基本字段：不只是六个红球和一个蓝球
双色球一注由 6 个红球和 1 个蓝球组成，红球范围是 1 到 33，蓝球范围是 1 到 16。所以一份完整的开奖记录里，至少会有期号、开奖日期、红球 1 到红球 6、蓝球这几个字段。附带字段通常还包括本期销售额、奖池金额、一等奖注数、单注奖金等，这些信息对研究彩票数据非常有用，比如奖池变化能反映加奖周期，销售额可以看出市场热度。但做表结构时，不要把所有这些字段都堆进一张表，尤其不要给销售额、奖池这类数值型字段用错类型，否则后面做聚合统计时容易算出莫名其妙的结果。
打开数据包后先别急着导入，先看字段名。很多整理者把列名写成red_1、red1、红球一这种混乱命名，我的习惯是先把列名规范成一套英文小写加下划线的形式。如果字段只有期号、日期和开奖号码，最好自己补上sale_amount和pool_amount这两个冗余列的位置，方便以后做奖池分析。不要担心数据包里没有这些字段，结构设计本来就是拿到数据后根据分析目标来定的。
字段类型的选择也有讲究。红球和蓝球本质上是小范围内的整数，用TINYINT UNSIGNED就足够，没必要用INT，后者每行多占 3 个字节，在 3287 行时无感，但你如果把它当成千万级业务的模板，就会暴露出问题。开奖日期用DATE类型，别用字符串，否则按年份过滤、按月份分组都会吃力。期号建议用INT UNSIGNED，但要注意有些数据文件的期号带前导零，比如2025001，这种存成数字会丢失前导零，需要先确认源数据格式再决定用INT还是VARCHAR。
2.2 表结构设计：TINYINT、DATE 和 UNIQUE KEY 怎么选
我一般会新建一个独立库来承载这份数据，而不是把它塞进已有的业务库。建表语句如下，你可以直接在 MySQL 客户端执行：
CREATE DATABASE IF NOT EXISTS lottery DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE lottery; CREATE TABLE ssq_record ( project_no INT UNSIGNED NOT NULL COMMENT '期号', open_date DATE NOT NULL COMMENT '开奖日期', red1 TINYINT UNSIGNED NOT NULL COMMENT '红球1', red2 TINYINT UNSIGNED NOT NULL, red3 TINYINT UNSIGNED NOT NULL, red4 TINYINT UNSIGNED NOT NULL, red5 TINYINT UNSIGNED NOT NULL, red6 TINYINT UNSIGNED NOT NULL, blue TINYINT UNSIGNED NOT NULL COMMENT '蓝球', sale_amount DECIMAL(16,2) DEFAULT NULL COMMENT '本期销售额(元)', pool_amount DECIMAL(16,2) DEFAULT NULL COMMENT '奖池金额(元)', PRIMARY KEY (project_no), UNIQUE KEY uk_open_date (open_date), KEY idx_blue (blue) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段建表逻辑的关键点有几个。TINYINT UNSIGNED用来存红蓝球，是因为范围 0 到 255 完全覆盖 1 到 33 和 1 到 16，比INT省空间且逻辑更严谨。DATE类型保证日期能做区间比较，例如WHERE open_date BETWEEN '2020-01-01' AND '2020-12-31'会走索引。PRIMARY KEY (project_no)直接按期号做主键，因为每一期是唯一的业务标识；UNIQUE KEY uk_open_date是第二道保险，防止同一开奖日期重复导入。最后的KEY idx_blue则是为蓝球聚合查询准备的索引，后面统计蓝球分布时会快很多。
如果你拿到的数据文件里没有销售额和奖池，那把这两列去掉即可，不要把DECIMAL列强行留空。注意DECIMAL(16,2)的 16 表示总位数，2 表示小数位，最大可存 99999999999999.99，单位是元，双色球奖池金额在这个数量级内足够。字符集统一用utf8mb4，虽然开奖记录本身没有中文，但你后期可能会把导入说明写进表注释，或者关联地区表，免得出现乱码。
2.3 一份数据两种玩法：Excel 做探索，MySQL 做精确查询
数据包里同时给 Excel 和 MySQL 文件是有道理的。Excel 适合小规模手工看数，透视表拖几下就能看到蓝球分布、冷热号排序；MySQL 适合跑全量统计，比如计算某个红球连续未出现多少期、两个红球组合历史上共现多少次，这类问题用 Excel 公式硬算也能算，但绝没有 SQL 干净。很多情况下我会先用 Excel 做数据探查，确认字段含义和大致范围，再决定 SQL 怎么写，这个链路效率很高。
另一个常见用途是把它喂给业务系统做测试。如果你正在学 SpringBoot4 和 Mybatis，或者写的是一个 JavaWeb 项目，往库里插入 3287 行真实分布的数据，比手动造一千条假数据更能体现分页、排序、条件查询的效果。比如接口GET /lottery?date=2024-01-01返回某期详情，或者做一个“统计每个蓝球出现次数”的图表接口，数据量大但又不至于大到跑不动，正好用来验证索引和缓存策略。
3. 导入 MySQL 数据文件：从建库、导数据到验证一条龙
3.1 准备工作：确认 MySQL 版本、字符集和建库脚本
先确保本机已经装好 MySQL。如果你刚照着 mysql 安装教程装完 MySQL 8.x，默认字符集就是 utf8mb4，省心很多；如果你还在用 5.7，建议在创建库时显式指定字符集，否则导入文件里出现中文字段注释或附加描述时，很容易变成乱码。装好之后用命令行客户端进入 MySQL，先执行SELECT VERSION();看版本，再执行下面的建库语句。
mysql -u root -pCREATE DATABASE IF NOT EXISTS lottery DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE lottery; SOURCE /path/to/ssq_record.sql;SOURCE命令是 mysql 命令行客户端的内置命令，不是 SQL，所以不能在 Navicat 的查询窗口里执行。如果你习惯用命令行，也可以直接用mysql -u root -p lottery < ssq_record.sql，效果一样。注意 Windows 下SOURCE的路径分隔符要用正斜杠，例如SOURCE E:/data/ssq_record.sql，用反斜杠会解析错误。字符集设置里选utf8mb4_general_ci就够了，没必要为一份彩票数据去追求utf8mb4_unicode_ci的排序规则，两者的性能差异在三千行上感知不到。
如果你没有现成的.sql文件，数据包给的是 CSV 或 Excel 导出的表格，那就先跳过SOURCE，参考下一小节的LOAD DATA INFILE。我建议导数据前先用SHOW VARIABLES LIKE 'secure_file_priv';看一下 MySQL 允许读取外部文件的目录，这一步能省去后面很多路径报错。另外导入前确认账号权限，练习时用 root 没问题，但如果是在公司或模拟项目里，应创建独立账号并只授予SELECT权限，避免误删数据。
3.2 导入数据前先做这一步：核对 Excel 和 MySQL 文件的期数是否一致
拿到数据包后，不要急着导入。先分别打开 Excel 文件和 MySQL 数据文件，确认期数一致。这里说的“期数”不是只看最后一个期号，而是看完整记录数。Excel 文件里可以用COUNTA函数统计期号列的非空单元格数量，MySQL 数据文件如果是.sql，用文本编辑器搜索 INSERT 语句数量很麻烦，我一般直接看导入后的COUNT(*)。之所以先做这一步，是因为很多整理者会先更新 Excel，后更新 MySQL 文件，两边的数据差了最近几期，后面做对比分析会对不上。
具体做法：Excel 里选中期号列，状态栏会显示“计数”，记下这个数；MySQL 文件先不管，等导入后再查COUNT(*)。如果两边不一致，优先以 MySQL 文件为准，因为数据库文件解析时不会受 Excel 自动格式化影响，更可靠。如果差了很多，说明这个数据包版本不完整，别急着删，先看看是否有单独的补丁文件。
3.3 source、LOAD DATA INFILE 和 GUI 工具：三种导入方式怎么选
如果你的 MySQL 数据文件是.sql格式，最简单的是SOURCE或命令行重定向，前面已经给过命令。如果数据包给的是 CSV 格式，那就用LOAD DATA INFILE。下面是一个完整例子：
LOAD DATA INFILE '/var/lib/mysql-files/ssq_record.csv' INTO TABLE lottery.ssq_record FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 ROWS (@project_no, @open_date, @red1, @red2, @red3, @red4, @red5, @red6, @blue, @sale_amount, @pool_amount) SET project_no = @project_no, open_date = STR_TO_DATE(@open_date, '%Y-%m-%d'), sale_amount = NULLIF(@sale_amount, ''), pool_amount = NULLIF(@pool_amount, '');这段逻辑的重点在SET部分。CSV 里的日期是字符串，直接导入DATE列会报错或存成0000-00-00，所以用STR_TO_DATE显式转换。NULLIF(@sale_amount, '')的作用是把空字符串转成NULL，避免空字符串被当成 0，否则统计平均值时会拉低结果。IGNORE 1 ROWS通常是跳过表头，如果数据文件没有表头，就不要加这一行。
LOAD DATA INFILE最容易栽在路径上。MySQL 8.0 默认开启secure-file-priv，只允许从指定目录读取文件，你要先执行SHOW VARIABLES LIKE 'secure_file_priv';查看那个目录在哪，然后把 CSV 放到该目录下。如果你用的是 Docker 安装 MySQL，那文件还需要先通过docker cp复制进容器，再指向容器内的路径。不想走这些流程的话，可以退回到SOURCE或直接用 Navicat/DBeaver 的导入向导，效果一样但能手动选择分隔符和文件编码，适合 Windows 上操作。
3.4 数据导入前必须格式化：把红球、蓝球转为标准格式再入库
很多从网页复制的开奖记录，红球可能长这样：1, 12, 21, 22, 30, 33，中间带逗号空格；蓝球可能是05或5混着。这类数据直接进 MySQL 会破坏表结构。如果 CSV 里每个球占一列，问题不大；但如果数据包里给的是“红球”一列，你就得先拆分再导入。
最稳的办法是在 Excel 里先用“分列”功能，按逗号或空格拆成 6 列，再把每一列设置成“文本”格式，最后另存为 CSV。拆分时会遇到1, 12, 21这种前导空格，Excel 会自动去首尾空格，但01和1会混在一起，所以导入前最好先把所有红球列统一格式，用公式=TEXT(A1,"00")把个位数补成两位。我自己遇到过数据包里红球是1，蓝球是01，导入 MySQL 后蓝球范围检查通过，但红球打印出来全是单个数字，看似没毛病，实际上和官方开奖号码的文本格式对不上，后续做字符匹配时才发现。
3.5 验证导入结果：记录数、期号连续性和红球范围检查
导入完成后，不要直接开始写分析 SQL，先跑一组验证查询，确认数据没被导坏。这组查询我每次都会执行：
-- 1. 基础行数检查 SELECT COUNT(*) AS total_rows, MIN(project_no) AS min_no, MAX(project_no) AS max_no FROM ssq_record; -- 2. 期号重复检查 SELECT project_no, COUNT(*) FROM ssq_record GROUP BY project_no HAVING COUNT(*) > 1; -- 3. 红蓝球范围检查 SELECT project_no FROM ssq_record WHERE red1 NOT BETWEEN 1 AND 33 OR red2 NOT BETWEEN 1 AND 33 OR red3 NOT BETWEEN 1 AND 33 OR red4 NOT BETWEEN 1 AND 33 OR red5 NOT BETWEEN 1 AND 33 OR red6 NOT BETWEEN 1 AND 33 OR blue NOT BETWEEN 1 AND 16;第一段查询看总记录数是否等于 3287，最小期号和最大期号是否符合时间顺序。第二段查重，理论上期号是唯一键，但如果源数据文件本身有重复，建表时的PRIMARY KEY会让导入报错，验证查询可以发现已经导入的数据里有没有重复。第三段的红球范围检查很关键，因为有些手抄数据会把30写成3或把16写成6，这种错误在你用 Excel 看时不易察觉，但会直接影响后续统计准确性。
验证通过后，我习惯再跑一条SELECT open_date, project_no FROM ssq_record ORDER BY open_date LIMIT 5;看看日期和期号是否一一对应。如果 2003 年第一期的期号不是2003001，就要回头检查是不是数据包里的期号定义不同，比如有的用1而不是2003001。这一步不做，后面做按年统计时会把 2003 年混进其他区间。
4. 用 Excel 处理开奖记录：从原始记录到可统计的报表
4.1 先给 Excel 数据“体检”：日期、红球、蓝色球的三类坑
Excel 打开数据文件后，第一件事不是做图，而是先检查日期列和号码列的格式。选中开奖日期列，看单元格是不是真正的日期类型，如果是数值或文本，后面所有按周、按月汇总都会失效。日期在 Excel 里如果显示成2025/5/23，右键设置单元格格式能看到“日期”分类，那没问题；如果显示成5/23且左侧对齐，那八成是文本，先用“分列”功能把它转成真日期。分列时选中日期列，点“数据-分列”，第三步选择“日期 YMD”，完成后再设置单元格格式为yyyy-mm-dd。
红球和蓝球列要小心 Excel 的自动转换。比如开奖号码里的1和12被当成数字，倒是没问题，但文本型的01会被自动去掉前导零变成1，这就导致红球 1 和蓝球 1 在文件里看起来没问题，实际上已经丢失了原始格式。除了格式，还要检查有没有合并单元格。很多整理好的 Excel 文件会把同一月的第一行合并，导致后面的行空着，如果直接拿去做函数统计会漏数据。看到合并单元格，先取消合并并填充同样的值。
第四类坑是空行和空值。双色球早期部分记录可能缺少销售额或奖池字段，Excel 里的空单元格在后续SUMIFS和透视表统计中不会报错，但在COUNTIF里就会被漏计。我的做法是先用筛选把所有列拉到底，看有没有全空的行，如果有没有，删除或标记。你下载的这批 3287 期数据包如果整理规范，这类问题不多，但“不多”不等于没有，体检一次花五分钟，后面省两小时。
4.2 用 SUMIFS 和 SUMPRODUCT 统计“周二蓝球出现次数”这类问题
Excel 里最常用的条件统计函数是SUMIFS和COUNTIFS，但它们不支持把“某列的数组运算结果”作为条件。比如你想统计“开奖日期是周二且蓝球等于 05”的期数，用COUNTIFS没法直接判断星期几，这时候用SUMPRODUCT最稳。假设开奖日期在 B2:B3288，蓝球在 I2:I3288，公式如下：
=SUMPRODUCT((WEEKDAY(B2:B3288,2)=2)*(I2:I3288=5))这个公式的原理是：WEEKDAY返回每个日期对应的星期数字，参数2让星期一等于 1，星期二等于 2，依此类推；(WEEKDAY(...)=2)会得到一个由TRUE/FALSE组成的数组，乘号另一边是(蓝球=5)，两者相乘时TRUE转成 1，FALSE转成 0，最后SUMPRODUCT对乘积求和，结果就是满足两个条件的总行数。用这个公式前提是 B 列是真日期，I 列没有文本，否则会出现#VALUE!。
如果要统计更复杂的多条件，COUNTIFS也有用武之地。比如统计某一年的蓝球 5 出现次数，可以写成：
=COUNTIFS($A$2:$A$3288,"2024*",$I$2:$I$3288,5)这里要求期号列 A 列必须是文本格式，才能用通配符2024*。如果期号是数字，就改成=SUMPRODUCT((YEAR(B2:B3288)=2024)*(I2:I3288=5))。我一般优先用SUMPRODUCT，因为它的数组逻辑更统一，不需要记通配符规则。Excel 文件里直接敲数组公式容易卡，但 3287 行对 Excel 来说是小数据量，实时计算没压力。
4.3 从 MySQL 查询结果生成 Excel：用 Python 写入自定义报表
当你已经习惯了 Excel 做展示，同时又想用 MySQL 跑复杂统计，最顺手的办法是让 Python 在中间当桥梁。先通过 SQL 查出结果，再写入 Excel。下面的例子用sqlalchemy和pandas，这两个库几乎是数据分析标配：
import pandas as pd from sqlalchemy import create_engine engine = create_engine( "mysql+pymysql://user:password@localhost:3306/lottery?charset=utf8mb4" ) sql = """ SELECT YEAR(open_date) AS year, blue, COUNT(*) AS cnt FROM ssq_record GROUP BY YEAR(open_date), blue ORDER BY year, blue; """ df = pd.read_sql(sql, engine) df.to_excel("blue_by_year.xlsx", index=False, sheet_name="按年蓝球分布")上面代码的要点有三处。第一处是连接串里的charset=utf8mb4，如果不加，读出来的一年里包含中文列名时可能乱码；第二处是pd.read_sql，它会把 SQL 查询结果直接变成 DataFrame，后续在 Python 里做透视、筛选都很方便；第三处是df.to_excel，指定sheet_name可以自定义工作表名，index=False避免把 DataFrame 的无意义索引写进 Excel。如果要把多个统计结果写进同一个 Excel 文件，可以用pd.ExcelWriter：
with pd.ExcelWriter("ssq_report.xlsx", engine="openpyxl") as writer: df_year.to_excel(writer, sheet_name="按年统计", index=False) df_blue.to_excel(writer, sheet_name="蓝球分布", index=False)这样生成的文件可以直接用 Excel 打开，且比手动复制粘贴整齐得多。我经常把 MySQL 里跑好的冷热号统计输出成 Excel，然后丢给同事继续做图表，大家都不用在 SQL 和 Excel 之间来回切换。需要留意的是，pymysql在连接 MySQL 8.0 时可能因为认证插件问题报错，如果连不上，先试ALTER USER 'user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';，或者换高版本pymysql。
5. 避坑指南：双色球数据导入和统计最常见的 5 个坑
5.1 现象：Excel 打开 CSV 文件全是乱码
很多人从 MySQL 导出 CSV 后，直接双击用 Excel 打开，结果中文全部变成乱码。原因是 MySQL 默认导出的 UTF-8 文件没有 BOM，Excel 在 Windows 上默认按 ANSI 编码解析，中文就全散了。这个坑在双色球数据包里也常见，因为整理者通常会把期号、日期、奖池说明写在一起。解决方法是：在 Excel 里用“数据-从文本/CSV 导入”并手动选择编码 UTF-8，不要在 Excel 里直接双击打开；如果已经在文件里了，把内容全选复制到记事本，另存为带 BOM 的 UTF-8 文件再重新打开。我每次从 MySQL 导出 CSV 都会加一句--default-character-set=utf8mb4，再确保输出文件开头带 BOM，Windows 下基本能一次通过。
5.2 现象：导入 MySQL 时提示 Duplicate entry
导入.sql或 CSV 时，如果表里已经有过部分数据，MySQL 会报Duplicate entry '2003001' for key 'PRIMARY'。原因很直接：期号重复了。可能是之前导入过但没清理，也可能是数据包本身在整理时复制了两行。解决办法是导入前先执行TRUNCATE TABLE ssq_record;，把旧数据清空再导。如果源文件本身有重复，用GROUP BY检查后去重再导。注意不要用REPLACE INTO来绕过报错，它会先删后插，晚导入的数据会默默覆盖早导入的数据，你完全不知道哪一期被换了。
5.3 现象：导入后红球范围检查失败
执行验证 SQL 时，查出red1 NOT BETWEEN 1 AND 33之类的记录，说明源数据本身有错。常见的错法是“红球 36”这种超出范围，更隐蔽的是“01”被 Excel 变成“1”后，和红球 1 混淆，但范围检查不会报错。如果范围检查失败，先回到原始 Excel 文件，用筛选功能找出异常记录，再和官方开奖信息核对。别指望数据库帮你纠错，它只会忠实地存进去。所以导入前的体检很重要，特别是号码列用文本格式从 CSV 导入，才能保留01和1的差别。
5.4 现象：LOAD DATA INFILE 一直报路径错误
在 MySQL 8.0 里执行LOAD DATA INFILE时，报错信息往往是一大串路径权限问题。原因基本只有一个：secure-file-priv限制了读取目录。你可以执行SHOW VARIABLES LIKE 'secure_file_priv';查看允许的目录，把 CSV 放进那个目录，或者直接把LOAD DATA改成SOURCE命令导入.sql文件。如果你用 Docker 安装 MySQL，还要先docker cp把文件复制到容器里，再指向容器内部路径。我建议新手直接用 Navicat 的导入向导，它能处理分隔符、编码和封号，避免踩这一地的雷。
5.5 现象：查询很慢，明明只有三千多行
只有三千多行的表，怎么查都不该慢，但如果你在上面跑了复杂的GROUP BY加多个OR条件，又没建索引，仍有可能出现几十毫秒的延迟。更常见的是你连到了别人的远程 MySQL，网络延迟占主要因素。解决办法是给常用的查询条件建复合索引，比如经常按蓝球统计，就建KEY idx_blue_red (blue, red1)，然后EXPLAIN SELECT ...查看是否走了索引。如果确认本地查询也慢，检查是不是没有用WHERE条件直接全表排序，ORDER BY也会触发文件排序。开奖记录表不大，慢多半是语句写法问题。
6. 进阶：用一条 SQL 快速验证 Excel 和 MySQL 两套文件是否一致
拿到这份双色球数据包后，我最担心的不是某个字段出错，而是 Excel 文件更新到了 3287 期，MySQL 文件却停在 3275 期。两套文件只有周期一致，后面的分析才可信。验证方法很简单：在 Excel 里用数据透视表统计每个蓝球出现的次数，导出后记为excel_blue_cnt；在 MySQL 里跑同样的统计：
SELECT blue, COUNT(*) AS cnt FROM ssq_record GROUP BY blue ORDER BY blue;把两个结果放在同一张 Excel 表里对比，任何不一致都能直接暴露。蓝球只有 1 到 16 共 16 个数字，比较起来非常快。如果两边的蓝球分布完全一致，基本说明两套文件是同一版本；如果差异很大，先查总数再看具体到哪几个蓝球对不上。一次我在模拟项目里就是这么发现 Excel 文件少了最近 4 期，当时整个人都懵了，还以为 SQL 写错，后来一查是数据包发布者忘了同步数据库文件。从那以后，我的习惯是先做一致性校验再开始任何分析。除了蓝球，还可以用同样的思路验证红球频次，用UNION ALL把六列红球压平：
SELECT n, COUNT(*) AS cnt FROM ( SELECT red1 AS n FROM ssq_record UNION ALL SELECT red2 FROM ssq_record UNION ALL SELECT red3 FROM ssq_record UNION ALL SELECT red4 FROM ssq_record UNION ALL SELECT red5 FROM ssq_record UNION ALL SELECT red6 FROM ssq_record ) t GROUP BY n ORDER BY n;这段 SQL 的精髓是UNION ALL，它不会去重，所以最终记录数是 3287 乘 6，每个红球位置都被统计一次。Excel 那边用COUNTIF对 1 到 33 每个数字统计相同频次，两边一对就知道有没有缺失或重复。这个方法我几乎每次拿到双格式数据都会做，成本不到一分钟，却能让后续的走势分析和频次统计建立在可信的数据上。希望帮到你。
本文还有配套的精品资源，点击获取
