在业务系统里，MySQL往往既是交易库又是分析数据源。面对数据挖掘与统计需求，很多人第一反应是导出数据用Python处理，但其实多数统计与轻量挖掘任务可以直接在MySQL内完成，关键在于理解其执行模型和内置能力边界。
一、统计场景下的聚合与精度问题
最基础的统计离不开COUNT、SUM、AVG等聚合函数。当数据量达到百万级以上，COUNT(DISTINCT user_id)这类去重统计会因为没有合适索引而触发全表扫描，并且占用大量临时空间。如果业务允许一定误差，MySQL本身不提供HyperLogLog函数，但可以通过应用层或UDF扩展实现近似基数统计，从而把内存占用从线性降为恒定。
另一个容易被忽视的是浮点精度。使用AVG或SUM对FLOAT类型列统计时，可能出现微小偏差。建议金额类统计使用DECIMAL类型，并在SQL中显式指定精度，例如SUM(amount * 1.0)转为高精度中间结果。下面示例展示带精度的日活统计：
-- 统计每天去重用户数，使用DECIMAL避免精度问题 SELECT DATE(create_time) AS day, COUNT(DISTINCT user_id) AS dau, CAST(SUM(amount * 1.0) AS DECIMAL(18,2)) AS total_amount FROM orders WHERE create_time >= '2023-01-01' GROUP BY DATE(create_time) ORDER BY day;
这种写法在千万级订单表上，如果create_time和user_id有联合索引，执行计划会走范围扫描而非全量排序。但需要注意，COUNT(DISTINCT)无法利用索引覆盖，仍可能产生临时表，因此在超高并发统计中建议预计算。
二、用窗口函数做多维下钻分析
MySQL 8.0引入的窗口函数让复杂统计不必多次自关联。比如要计算每个品类销售额占全站比例，同时展示排名，传统写法需子查询，而窗口函数一行解决。它不会减少行数，而是在每行附加聚合结果，非常适合报表类数据挖掘。
以下代码演示如何用SUM() OVER计算占比与累计值，用于漏斗或留存分析：
-- 各品类销售额及占全站比例 SELECT category_id, SUM(amount) AS cat_amount, SUM(amount) OVER () AS total_amount, SUM(amount) / SUM(amount) OVER () AS ratio, RANK() OVER (ORDER BY SUM(amount) DESC) AS rk FROM orders GROUP BY category_id;
窗口函数虽强，但不能在WHERE中过滤窗口结果，需包一层子查询。对于统计挖掘常见的移动平均、同期对比，可用ROWS BETWEEN子句定义滑动窗口，避免应用层拉取原始序列。
三、在SQL中实现轻量关联挖掘
关联规则（如“买了A又买B”）不一定非要上Spark。利用自连接和分组计数，MySQL能算出支持度。核心是把订单明细按用户或订单聚合，再两两组合商品。
示例找出同单内商品共现次数：
-- 同订单内商品两两共现 SELECT a.product_id AS p1, b.product_id AS p2, COUNT(*) AS co_count FROM order_item a JOIN order_item b ON a.order_id = b.order_id AND a.product_id < b.product_id GROUP BY a.product_id, b.product_id HAVING co_count > 100 ORDER BY co_count DESC;
这里用a.product_id < b.product_id去掉重复对和自身配对。若订单表很大，可先按order_id分区，或只针对近期窗口计算。这种纯SQL挖掘延迟低，适合运营实时选品，而不用等离线任务。
四、分区与汇总表保障性能
长期统计不能每次扫原表。合理的做法是建汇总表（如stats_daily）由定时任务写入，以及用分区表把历史冷数据分离。MySQL原生分区支持按时间RANGE分区，让统计只访问当月分区。
下面的DDL展示按月份分区的订单表设计，统计时加上时间条件即可命中单分区：
CREATE TABLE orders (
id BIGINT,
user_id BIGINT,
amount DECIMAL(10,2),
create_time DATETIME
) PARTITION BY RANGE (TO_DAYS(create_time)) (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01'))
);
配合事件调度器或外部脚本，每天凌晨把昨天的聚合结果写进stats_daily，前端报表直接查小表。这样主库不被分析查询拖垮，数据挖掘也能稳定跑在从库。
五、何时该把挖掘移出MySQL
当涉及图计算、复杂聚类或跨年全量训练时，MySQL算力不足，应导出到专用引擎。但在多数业务统计、漏斗、TOPN、共现等场景，写好SQL并利用索引与分区，就能以低成本和低延迟完成数据挖掘与统计，不必过早引入重型架构。
总结来说，先问清统计精度与时效要求，再用聚合、窗口、自连接和汇总表组合解决。把MySQL当作分析入口而非单纯存储，才能兼顾性能与准确性。