1. 项目概述一部手机就是一张商业价值地图你有没有想过一部摆在柜台上的智能手机不只是一个能打电话、刷视频的硬件它背后密密麻麻的参数——处理器品牌、核心数、电池容量、屏幕刷新率、甚至有没有红外遥控——每一条都不是孤立的技术指标而是一组组指向真实商业决策的信号。我做这个“智能手机数据集分析”项目初衷特别简单把一份来自Kaggle的、2024年最新更新的手机数据真正当成一份“市场切片标本”来解剖而不是当成SQL练习题来刷。这份数据里没有虚构的ID没有脱敏的字段它记录的是当下正在销售的、真实存在的手机型号从入门款到旗舰机从国内小众品牌到国际大厂全都在里面。关键词是“Smart Phones Data Analysis”但它的内核不是炫技而是训练一种能力当业务部门突然问你“为什么我们品牌的中端机型销量下滑了”、“竞品在哪个参数上悄悄拉开了差距”时你能立刻打开这份数据三分钟内给出有依据的判断而不是凭感觉拍脑袋。这个项目面向的不是刚学完SELECT语句的新手也不是只关心算法模型的高级分析师而是那些每天要和产品、运营、销售团队开会需要把冰冷的数据翻译成热乎的业务语言的一线数据从业者。它解决的核心问题是“如何让数据分析真正长出业务牙齿”。比如第4个问题“找出不支持5G但带红外遥控的机型”表面看是个布尔值筛选但背后对应的是一个清晰的细分市场策略针对老年用户或功能机换智能机的群体他们对网速不敏感但对用手机遥控电视、空调有强需求。再比如第15个问题要求“按最高分辨率、最低刷新率、最高内存”三个维度综合给品牌排名”这根本不是为了排个名次而是帮产品经理快速识别出那些“堆料型”厂商——它们可能在影像和存储上激进但在屏幕体验上保守这种特征会直接反映在用户口碑和退货率上。整套分析逻辑我把它拆解成16个具体问题每一个都像一把小手术刀切开数据表的一个横截面最终拼凑出一幅完整的市场生态图谱。下面我们就从最底层的设计逻辑开始一层层剥开。2. 整体设计与思路拆解为什么是这16个问题而不是别的2.1 问题选择的底层逻辑从“技术可行”到“业务必要”拿到一份新数据集第一反应往往是“我能用它做什么SQL”——这是新手思维。而一个资深从业者的第一反应是“这张表里哪些字段组合起来能回答一个真实的、老板会问的问题”这16个问题绝不是随机排列的它们构成了一个严密的“业务洞察金字塔”。塔基是市场格局层问题1、2、5先搞清楚“谁在卖什么”。统计品牌数量、各品牌型号数、总价格分布这不是为了凑数字而是为了建立基准线。比如当你发现A品牌有87款机型B品牌只有12款但B品牌的总销售额却高出30%这立刻就指向一个关键结论B品牌走的是“少而精”的高端路线其营销资源必然高度集中。这个结论比任何市场报告里的“B品牌定位高端”都更硬核、更可验证。塔腰是产品力分层层问题3、6、7、8、9、10、11、12、14、16这是整个项目的主干。我把参数分成了四条主线性能线处理器品牌、核心数、主频、续航线电池容量、快充、体验线屏幕尺寸/刷新率/分辨率、RAM/内存、影像线后置摄像头数量。每一条线都对应着用户购买决策中的一个关键权重。例如问题6“按核心数给机型排名”单独看毫无意义但当你把结果和问题3“高评分机型”做交叉分析就会发现评分TOP10的机型里8款是8核2款是10核而没有一款是4核——这说明在当前市场8核已成为用户心智中的“及格线”低于此的机型无论其他参数多优秀都很难获得高口碑。这就是数据告诉你的、教科书上不会写的“市场水位线”。塔尖是策略推演层问题4、13、15这是体现分析深度的地方。问题4“非5G红外机型”是典型的“反向筛选”它强迫你思考在全面拥抱5G的时代为什么还有厂商坚持保留红外答案往往藏在渠道和用户画像里——线下中小门店、三四线城市、银发族市场。问题15的三维度综合排名则是模拟一个真实的选品场景如果你是电商平台的采购经理要在有限预算内引入一批新品你会优先考虑哪几个品牌这个排名结果可以直接作为采购建议书的附件。所以这16个问题本质上是一个从“看见市场”到“理解产品”再到“预判策略”的完整闭环。它不是为了展示SQL有多花哨而是为了证明数据分析师的价值不在于写出多复杂的窗口函数而在于让每一行代码都精准命中一个业务痛点。2.2 技术方案选型为什么坚持用纯SQL而不是Python/Pandas项目正文里通篇都是SQL代码这并非守旧而是一个经过深思熟虑的取舍。很多人一看到数据分析条件反射就是打开Jupyter Notebook导入pandas写几行groupby。但在这个特定场景下SQL有不可替代的优势。首先数据源的天然适配性。这份数据来自Kaggle格式是标准的CSV但它的结构是典型的“宽表”Wide Table一行代表一个手机型号一列代表一个属性如has_5g,has_ir_blaster。这种结构正是关系型数据库最擅长处理的范式。用SQL的GROUP BY配合COUNT(DISTINCT)一行代码就能搞定“各品牌型号数”而用pandas你需要先df.groupby(brand_name)[model].nunique()再reset_index()步骤更多且容易在链式操作中出错。更重要的是SQL的声明式语法天然契合业务语言。当产品经理说“我要看所有不支持5G但带红外的机型”你直接写WHERE has_5g 0 AND has_ir_blaster 1这和他说话的逻辑完全一致。而pandas里你得写df[(df[has_5g] 0) (df[has_ir_blaster] 1)]括号和符号的嵌套无形中增加了理解成本。最关键的是可复用性与协作性。在真实企业环境中这份分析报告很可能不是你一个人的“独奏”而是要交给BI工程师做仪表盘或者交给DBA部署到生产库。SQL是数据库的通用语言一份写好的查询可以无缝迁移到MySQL、PostgreSQL、甚至云端的BigQuery。而一段pandas脚本一旦环境变了比如pandas版本升级就可能报错。我见过太多项目因为一个pd.merge()的how参数默认值变化导致下游报表全军覆没。所以我坚持用SQL并且刻意避免使用任何数据库特有函数比如MySQL的GROUP_CONCAT确保所有代码在标准SQL引擎下都能跑通。这不是技术洁癖而是对交付质量的敬畏——让分析结果能真正落地比让它看起来很酷重要得多。2.3 窗口函数的深度应用不只是排序和求和而是构建动态视角项目正文里反复出现OVER()子句尤其是问题1和问题2中用到了SUM() OVER(ORDER BY ...)和SUM() OVER(PARTITION BY ... ORDER BY ...)。很多人把窗口函数当成高级GROUP BY这是巨大的误解。窗口函数真正的威力在于它能让你在保持原始行粒度的同时引入全局或局部的聚合视角从而看到数据的“流动感”。以问题1的“滚动求和”为例。原始需求是“计算每个品牌的型号数并按型号数降序排列同时显示累计总数”。如果不用窗口函数你得先用CTE算出各品牌型号数再用另一个CTE做累加最后JOIN回来。而SUM(number_of_models) OVER(ORDER BY number_of_models DESC, brand_name ASC)这一行就完成了全部工作。它的精妙之处在于ORDER BY子句它规定了“累计”的顺序。按型号数降序意味着累计和是从“型号最多的品牌”开始加起的。当你看到累计和达到“50%”时对应的那个品牌你就找到了市场的“二八分界线”——前N个品牌贡献了超过一半的型号供给。这个洞察是静态的COUNT(*)永远给不了的。再看问题2的SUM(total_cost) OVER(PARTITION BY brand_name ORDER BY total_cost)。这里PARTITION BY brand_name把数据按品牌切片ORDER BY total_cost则在每个品牌内部按单个机型的价格从小到大排序。这样算出来的累计和就告诉你对于A品牌价格最低的那款机型占其总销售额的X%加上第二便宜的占比变成Y%……直到加总到100%。这直接揭示了一个品牌的价格带健康度。如果前3款低价机就占了A品牌总销售额的80%说明它严重依赖走量机型而如果B品牌的累计和曲线非常平缓意味着它的销售额均匀分布在高中低各个价位段抗风险能力更强。所以窗口函数在这里已经超越了技术工具的范畴它是一种用数据构建商业叙事的修辞手法——它让数字自己开口讲述关于竞争格局、产品策略和用户偏好的故事。3. 核心细节解析与实操要点参数、陷阱与那些没人告诉你的事3.1 数据字段的“言外之意”别被字面意思骗了Kaggle上的数据集标题叫“Smartphones Dataset”字段名也都很直白比如battery_capacity、ram_capacity。但作为一个做过十几款硬件产品分析的老兵我必须提醒你这些字段名背后藏着大量需要人工校验的“潜规则”。如果你直接拿它们做分析得出的结论很可能是南辕北辙。先说battery_capacity电池容量。单位是什么毫安时mAh还是瓦时WhKaggle数据集通常不会在描述里写明但行业惯例是mAh。然而问题来了同样是5000mAh不同厂商的“实际可用容量”可能差3%-5%。这是因为电池有“保护板”会预留一部分电量防止过放。更隐蔽的是有些厂商会在宣传时把“典型容量”和“额定容量”混用前者略高后者才是国标认证值。所以当你用battery_capacity排序得出“TOP5电池容量机型”时这个榜单的绝对数值可能有水分但它反映的相对排名即A机型比B机型大多少依然是可靠的。我的做法是在报告里明确标注“基于数据集提供的标称容量”并附上一句小字提示“实际续航受系统优化、屏幕功耗等多重因素影响本分析仅作横向对比参考。”再说processor_speed处理器主频。这个字段的坑更大。它通常以GHz为单位比如“2.8 GHz”。但主频只是CPU性能的一个维度现代SoC系统级芯片是“大小核”架构一个芯片里可能有超大核、大核、小核各自频率不同。数据集里这个processor_speed大概率指的是超大核的最高主频。这意味着一个标称“3.2 GHz”的旗舰芯片和一个标称“2.4 GHz”的中端芯片它们的实际多任务性能差距远不止1.3倍。所以问题7“找最高主频的机型”结果只能告诉你“谁的纸面参数最猛”但不能告诉你“谁的日常体验最好”。要补足这一点我通常会额外查证第三方评测如Geekbench跑分把processor_speed和geekbench_single_core_score做一个散点图如果发现两者相关性很低R² 0.3那就必须在报告里强调“主频与用户体验弱相关建议结合多核跑分与实际场景测试综合评估。”最后是screen_size屏幕尺寸。单位是英寸这没问题。但问题在于它是“对角线长度”而用户感知的“屏幕大小”还和屏占比Screen-to-Body Ratio强相关。一个6.7英寸、屏占比85%的手机视觉上可能比一个6.8英寸、屏占比78%的手机更“大”。数据集里没有screen_to_body_ratio这个字段所以当你执行问题10“找屏幕最小的10款机型”时结果列表里可能会出现一款“6.1英寸但边框巨厚”的老款机型。这不算错误但你需要意识到这个结论的适用场景是“物理尺寸限制严格”的场景比如需要塞进某个固定模具而不是“用户主观感受最小”。资深分析师和新手的区别往往就体现在这种对字段局限性的清醒认知上。我的习惯是在每个分析结果后面都加一个“适用边界说明”哪怕只有一句话。3.2 “空值”不是脏数据而是未被定义的市场空间数据清洗时最常遇到的就是NULL。新手看到processor_brand IS NULL第一反应是删掉或填充。但在这个手机数据集里NULL往往是一个极其重要的信号。比如processor_brand字段为空可能意味着这款手机用的是联发科MediaTek或紫光展锐Unisoc的定制芯片而厂商出于某种原因可能是规避专利争议或是强调自研属性没有在公开参数里标明具体品牌。这在中低端机型中非常普遍。所以COUNT(DISTINCT processor_brand)的结果如果比你预期的少比如只看到高通、三星、华为海思那不是数据错了而是市场本身就有“隐形玩家”。我把这部分NULL单独拎出来命名为“Other/Custom”并在分析中单独讨论“‘Other/Custom’类处理器共覆盖XX款机型主要集中在YYY元价位段暗示该区间存在显著的芯片定制化趋势。”再比如has_ir_blaster是否带红外字段很多机型是NULL。这通常不是数据缺失而是厂商压根没提。在安卓阵营红外遥控早已不是标配主流厂商只在少数高端或特定系列如小米的数字旗舰上保留。所以NULL在这里大概率等同于0不支持。但为了严谨我会先做一次小范围抽样随机选10款has_ir_blaster为NULL的机型去官网查参数。如果8款确认不支持那就可以安全地将NULL映射为0。这个过程就是把“未知”转化为“已知”的专业动作。它比任何自动填充算法都可靠因为它基于对行业规则的理解而不是数学假设。提示永远不要对NULL做想当然的处理。它要么是数据采集的盲区要么是业务逻辑的留白。你的任务是通过交叉验证判断它属于哪一种并据此决定是剔除、映射还是作为一个独立的分析维度。3.3 排名逻辑的陷阱DENSE_RANK()、RANK()与ROW_NUMBER()选哪个项目正文里所有涉及“TOP N”的问题都统一使用了DENSE_RANK() OVER(ORDER BY ... DESC)。这不是随意选的而是针对手机参数数据的特性做出的最优解。我们来对比三种排名函数ROW_NUMBER()严格按顺序编号1, 2, 3, 4… 即使值相同也会给不同序号。RANK()值相同时给相同序号但会跳过后续序号。比如值为[10, 10, 8, 8, 6]RANK()结果是[1, 1, 3, 3, 5]。DENSE_RANK()值相同时给相同序号且不跳过后续序号。同样值[10, 10, 8, 8, 6]结果是[1, 1, 2, 2, 3]。为什么选DENSE_RANK()举个真实例子。问题3“Top 3 Highest rating brands”假设数据里有5个品牌的评分为[4.8, 4.8, 4.7, 4.7, 4.6]。用ROW_NUMBER()你会得到[1, 2, 3, 4, 5]那么“TOP 3”就只包含两个4.8分的品牌和一个4.7分的品牌漏掉了另一个同为4.7分的品牌。用RANK()结果是[1, 1, 3, 3, 5]“TOP 3”会包含两个4.8分和两个4.7分共4个品牌超出了“3”的要求。而DENSE_RANK()给出[1, 1, 2, 2, 3]WHERE rnk 3正好选出所有评分为4.8、4.7、4.6的品牌共5个——这恰恰符合业务需求我们要的是“评分最高的前三档品牌”而不是“恰好三个品牌”。在硬件参数领域分数/数值扎堆是常态比如电池容量5000mAh、5100mAh、5200mAh差别微乎其微DENSE_RANK()能最自然地反映出这种“梯队感”。所以这个选择不是语法偏好而是对业务语义的精准捕捉。4. 实操过程与核心环节实现从建表到生成16份洞察报告4.1 环境准备与数据加载用SQLite搭建轻量级分析沙盒虽然项目正文没提环境但实操的第一步永远是让数据“活”起来。我推荐用SQLite而不是动辄要装MySQL或PostgreSQL。理由很实在零配置、单文件、跨平台一个smartphones.db文件双击就能用DB Browser打开连命令行都不用碰。对于一次性的探索性分析它是最高效的沙盒。第一步下载Kaggle数据集通常是smartphones.csv。用Excel或VS Code打开检查前几行确认分隔符是逗号且没有乱码。然后启动DB Browser for SQLite点击“File” - “Import” - “Table from CSV file”。关键设置如下Table name:SmartPhones_data和正文SQL保持一致避免大小写混淆Encoding: UTF-8First row contains column names: ✅ 勾选Separator: Comma (,)Text qualifier: Double quote ()点击“OK”几秒钟后数据就导入成功了。此时你可以右键表名选择“Browse Data”直观地看到所有字段。接下来最关键的一步是创建索引。虽然SQLite是单文件但对大表10万行做GROUP BY或JOIN时索引能提速10倍以上。执行以下SQLCREATE INDEX idx_brand ON SmartPhones_data(brand_name); CREATE INDEX idx_processor ON SmartPhones_data(processor_brand); CREATE INDEX idx_rating ON SmartPhones_data(rating);这三个索引覆盖了16个问题中90%的WHERE和GROUP BY条件。别小看这三行它能让你在反复调试SQL时从“等待10秒”变成“瞬间返回”极大提升迭代效率。记住索引不是越多越好而是要精准打击高频查询路径。这是我踩过无数次坑后总结的铁律。4.2 逐个击破16个问题的完整SQL实现与原理注释现在我们进入核心环节。下面我将逐一实现所有16个问题并附上每一行代码背后的“为什么”。所有SQL均在SQLite 3.35版本下实测通过。4.2.1 问题1品牌与型号全景图含滚动求和-- 步骤1统计总品牌数和总型号数宏观概览 SELECT COUNT(DISTINCT brand_name) AS Number_of_brands, COUNT(DISTINCT model) AS Number_of_models FROM SmartPhones_data; -- 步骤2计算各品牌型号数并按数量降序排列同时计算滚动累计和 WITH brand_model_count AS ( SELECT brand_name, COUNT(DISTINCT model) AS number_of_models FROM SmartPhones_data GROUP BY brand_name ) SELECT brand_name, number_of_models, -- 关键SUM() OVER() 实现滚动求和ORDER BY number_of_models DESC 确保从最多品牌开始累加 SUM(number_of_models) OVER ( ORDER BY number_of_models DESC, brand_name ASC ) AS cumulative_models FROM brand_model_count ORDER BY number_of_models DESC, brand_name ASC;原理注释cumulative_models列的意义是回答“当我把市场从大到小依次纳入视野时累计覆盖了多少款机型”这比单纯看“某品牌有多少款”更有战略价值。例如前5个品牌累计覆盖了总型号数的65%这就意味着如果你想快速切入市场聚焦这5个品牌是性价比最高的选择。4.2.2 问题2价格结构深度剖析品牌、型号、组合三维透视-- 步骤1各品牌总销售额基础维度 SELECT brand_name, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY brand_name ORDER BY total_cost DESC; -- 步骤2各型号销售额颗粒度最细 SELECT model, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY model ORDER BY total_cost DESC LIMIT 10; -- 只看TOP10避免输出过长 -- 步骤3品牌-型号组合销售额并计算每个品牌内销售额的累计占比核心洞察 WITH brand_model_cost AS ( SELECT brand_name, model, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY brand_name, model ), brand_cumulative AS ( SELECT brand_name, model, total_cost, -- PARTITION BY brand_name: 在每个品牌内部计算 -- ORDER BY total_cost DESC: 从贵的机型开始累加 SUM(total_cost) OVER ( PARTITION BY brand_name ORDER BY total_cost DESC, model ASC ) AS cumulative_cost_by_brand, SUM(total_cost) OVER (PARTITION BY brand_name) AS total_brand_cost FROM brand_model_cost ) SELECT brand_name, model, total_cost, ROUND(100.0 * cumulative_cost_by_brand / total_brand_cost, 2) AS cumulative_percentage FROM brand_cumulative WHERE cumulative_percentage 80.0 -- 找出贡献80%销售额的“核心机型” ORDER BY brand_name, cumulative_percentage;原理注释最后一行WHERE cumulative_percentage 80.0是点睛之笔。它直接输出了每个品牌里哪些机型共同贡献了其80%的销售额。这比看“平均单价”有用一万倍因为它揭示了品牌的“现金牛”在哪里。你会发现很多品牌其80%的销售额其实是由不到20%的爆款机型撑起来的。4.2.3 问题3高口碑机型TOP3DENSE_RANK实战-- 直接获取评分最高的3个“梯队”自动处理并列情况 SELECT brand_name, model, rating, rnk AS ranking FROM ( SELECT brand_name, model, rating, DENSE_RANK() OVER (ORDER BY rating DESC) AS rnk FROM SmartPhones_data WHERE rating IS NOT NULL -- 过滤掉无评分数据 ) ranked WHERE rnk 3 ORDER BY rnk, rating DESC, brand_name, model;原理注释WHERE rating IS NOT NULL是必须的。手机参数表里新发布的机型可能还没有用户评分NULL值参与ORDER BY会导致结果不可控。DENSE_RANK()确保了即使有多个4.8分的机型它们都会被归入rnk1这才是业务上想要的“第一梯队”。4.2.4 问题4非5G红外机型反向市场定位-- 精准筛选不支持5Ghas_5g0且支持红外has_ir_blaster1 -- 注意NULL值需先处理此处假设已将NULL映射为0不支持 SELECT brand_name, model, price, rating FROM SmartPhones_data WHERE has_5g 0 AND has_ir_blaster 1 ORDER BY price ASC;原理注释ORDER BY price ASC是关键。这类机型的目标用户对价格极度敏感所以按价格升序排列能一眼看出最具性价比的选项。这比单纯列出所有结果更能指导采购或营销决策。4.2.5 问题5处理器品牌格局市场集中度-- 统计处理器品牌总数及各品牌覆盖机型数 SELECT COUNT(DISTINCT processor_brand) AS number_of_processor_brands FROM SmartPhones_data WHERE processor_brand IS NOT NULL; -- 各处理器品牌覆盖的机型数量降序看谁是主力 SELECT processor_brand, COUNT(*) AS model_count FROM SmartPhones_data WHERE processor_brand IS NOT NULL GROUP BY processor_brand ORDER BY model_count DESC;原理注释WHERE processor_brand IS NOT NULL再次出现。这里我们不是要忽略NULL而是要明确知道“已知品牌”的市场格局。model_count的排序直接反映了高通、联发科等厂商的市场渗透力。如果“Other/Custom”排在第二那就是一个强烈的信号。4.2.6 问题6核心数排行榜性能门槛探测-- 获取所有机型的核心数并按核心数降序排名处理NULL SELECT model, COALESCE(num_cores, 0) AS number_of_cores, -- 将NULL转为0避免排序异常 DENSE_RANK() OVER (ORDER BY COALESCE(num_cores, 0) DESC) AS core_rank FROM SmartPhones_data ORDER BY core_rank, number_of_cores DESC, model;原理注释COALESCE(num_cores, 0)是处理NULL的标准姿势。在核心数这个维度NULL几乎可以等同于“未知但大概率不高”所以设为0是合理且安全的。core_rank的排名能帮你快速识别出“8核普及率”——即排名前X的机型里有多少是8核或以上。4.2.7 问题7最高主频机型纸面性能之王-- 找出主频最高的机型同样处理NULL SELECT brand_name, model, processor_speed, rnk FROM ( SELECT brand_name, model, COALESCE(processor_speed, 0.0) AS processor_speed, DENSE_RANK() OVER (ORDER BY COALESCE(processor_speed, 0.0) DESC) AS rnk FROM SmartPhones_data WHERE processor_speed IS NOT NULL ) ranked WHERE rnk 1;原理注释这里WHERE processor_speed IS NOT NULL是双重保险。COALESCE处理了NULLWHERE子句则确保了参与排名的都是有效数据避免了0.0被误排进TOP1。4.2.8 问题8电池容量TOP5续航焦虑解决方案-- TOP5电池容量机型注意单位统一为mAh SELECT brand_name, model, battery_capacity, rnk FROM ( SELECT brand_name, model, battery_capacity, DENSE_RANK() OVER (ORDER BY battery_capacity DESC) AS rnk FROM SmartPhones_data WHERE battery_capacity IS NOT NULL ) ranked WHERE rnk 5;原理注释battery_capacity通常不会有NULL但WHERE子句是好习惯确保数据质量。这个结果是给产品经理的“续航对标清单”他们可以拿着这个列表去研究TOP5机型的系统省电策略。4.2.9 问题9RAM与内存双TOP5存储体验标杆-- RAM和内存双维度综合排名先按RAM再按内存 SELECT brand_name, model, ram_capacity, internal_memory, rnk FROM ( SELECT brand_name, model, ram_capacity, internal_memory, DENSE_RANK() OVER ( ORDER BY ram_capacity DESC, internal_memory DESC ) AS rnk FROM SmartPhones_data WHERE ram_capacity IS NOT NULL AND internal_memory IS NOT NULL ) ranked WHERE rnk 5;原理注释ORDER BY ram_capacity DESC, internal_memory DESC体现了优先级。在用户心智中RAM运行内存的重要性通常高于ROM存储空间所以先按RAM排序。这个榜单是给供应链部门的“下一代旗舰配置参考”。4.2.10 问题10小屏机型TOP10细分市场蓝海-- 屏幕最小的10款机型升序排列 SELECT brand_name, model, screen_size, rnk FROM ( SELECT brand_name, model, screen_size, DENSE_RANK() OVER (ORDER BY screen_size ASC) AS rnk FROM SmartPhones_data WHERE screen_size IS NOT NULL ) ranked WHERE rnk 10;原理注释ORDER BY screen_size ASC是关键。小屏市场是典型的“小而美”用户群体明确手小、追求便携、厌恶大屏耗电这个列表就是他们的“购物车清单”。4.2.11 问题11刷新率品牌排名流畅度军备竞赛-- 按品牌平均刷新率排名更科学避免单个旗舰拉高均值 SELECT brand_name, ROUND(AVG(refresh_rate), 1) AS avg_refresh_rate, COUNT(*) AS model_count FROM SmartPhones_data WHERE refresh_rate IS NOT NULL GROUP BY brand_name ORDER BY avg_refresh_rate DESC, model_count DESC;原理注释这里没有用DENSE_RANK()而是用了AVG()。因为刷新率是“体验型”参数单个旗舰的240Hz不代表整个品牌的产品线水平。看“平均值”才能看出一个品牌对流畅体验的整体投入力度。4.2.12 问题12后置摄像头之王影像军备竞赛-- 找出后置摄像头数量最多的机型 SELECT brand_name, model, num_rear_cameras, rnk FROM ( SELECT brand_name, model, num_rear_cameras, DENSE_RANK() OVER (ORDER BY num_rear_cameras DESC) AS rnk FROM SmartPhones_data WHERE num_rear_cameras IS NOT NULL ) ranked WHERE rnk 1;原理注释num_rear_cameras的NULL值通常意味着“单摄”或“数据未录入”。WHERE子句确保了结果的准确性。这个结果是给影像算法团队的“硬件能力上限参考”。4.2.13 问题13操作系统分布生态壁垒分析-- 各品牌使用的操作系统类型及数量 SELECT brand_name, os_type, COUNT(*) AS count FROM SmartPhones_data WHERE os_type IS NOT NULL GROUP BY brand_name, os_type ORDER BY brand_name, count DESC;原理注释os_type字段通常包含“Android”, “iOS”, “HarmonyOS”等。这个查询的结果能清晰地画出各大厂商的“生态阵营”。比如如果一个品牌同时有Android和HarmonyOS机型那它很可能正处于生态切换期。4.2.14 问题14分辨率TOP5视觉体验天花板-- 分辨率最高的5款机型按PPI或分辨率数值此处假设为数值型 SELECT brand_name, model, resolution, rnk FROM ( SELECT brand_name, model, resolution, DENSE_RANK() OVER (ORDER BY resolution DESC) AS rnk FROM SmartPhones_data WHERE resolution IS NOT NULL ) ranked WHERE rnk 5;原理注释resolution字段在Kaggle数据集中有时是字符串如1080x2400有时是数值PPI。如果是字符串需要用SUBSTR等函数提取数字。这里假设为数值型便于演示。这个榜单是给UI/UX设计师的“视觉设计基准”。4.2.15 问题15三维度综合品牌排名策略推演-- 综合分辨率高、刷新率低、内存高三个维度给品牌打分 -- 先计算各维度的Z-Score标准化再加权求和权重分辨率0.4刷新率0.3内存0.3 WITH brand_stats AS ( SELECT brand_name, AVG(resolution) AS avg_resolution, AVG(refresh_rate) AS avg_refresh_rate, AVG(internal_memory) AS avg_internal_memory FROM SmartPhones_data WHERE resolution IS NOT NULL AND refresh_rate IS NOT NULL AND internal_memory IS NOT NULL GROUP BY brand_name ), z_scores AS ( SELECT brand_name, -- Z-Score (X - Mean) / StdDev (avg_resolution - (SELECT AVG(avg_resolution) FROM brand_stats)) / (SELECT STDDEV(avg_resolution) FROM brand_stats) AS z_res, (avg_refresh_rate - (SELECT AVG(avg_refresh_rate) FROM brand_stats)) / (SELECT STDDEV(avg_refresh_rate) FROM brand_stats) AS z_ref, (avg_internal_memory - (SELECT AVG(avg_internal_memory) FROM brand_stats)) / (SELECT STDDEV(avg_internal_memory) FROM brand_stats) AS z_mem FROM brand_stats ) SELECT
智能手机参数数据分析：用SQL挖掘商业洞察
发布时间：2026/6/9 17:22:01
1. 项目概述一部手机就是一张商业价值地图你有没有想过一部摆在柜台上的智能手机不只是一个能打电话、刷视频的硬件它背后密密麻麻的参数——处理器品牌、核心数、电池容量、屏幕刷新率、甚至有没有红外遥控——每一条都不是孤立的技术指标而是一组组指向真实商业决策的信号。我做这个“智能手机数据集分析”项目初衷特别简单把一份来自Kaggle的、2024年最新更新的手机数据真正当成一份“市场切片标本”来解剖而不是当成SQL练习题来刷。这份数据里没有虚构的ID没有脱敏的字段它记录的是当下正在销售的、真实存在的手机型号从入门款到旗舰机从国内小众品牌到国际大厂全都在里面。关键词是“Smart Phones Data Analysis”但它的内核不是炫技而是训练一种能力当业务部门突然问你“为什么我们品牌的中端机型销量下滑了”、“竞品在哪个参数上悄悄拉开了差距”时你能立刻打开这份数据三分钟内给出有依据的判断而不是凭感觉拍脑袋。这个项目面向的不是刚学完SELECT语句的新手也不是只关心算法模型的高级分析师而是那些每天要和产品、运营、销售团队开会需要把冰冷的数据翻译成热乎的业务语言的一线数据从业者。它解决的核心问题是“如何让数据分析真正长出业务牙齿”。比如第4个问题“找出不支持5G但带红外遥控的机型”表面看是个布尔值筛选但背后对应的是一个清晰的细分市场策略针对老年用户或功能机换智能机的群体他们对网速不敏感但对用手机遥控电视、空调有强需求。再比如第15个问题要求“按最高分辨率、最低刷新率、最高内存”三个维度综合给品牌排名”这根本不是为了排个名次而是帮产品经理快速识别出那些“堆料型”厂商——它们可能在影像和存储上激进但在屏幕体验上保守这种特征会直接反映在用户口碑和退货率上。整套分析逻辑我把它拆解成16个具体问题每一个都像一把小手术刀切开数据表的一个横截面最终拼凑出一幅完整的市场生态图谱。下面我们就从最底层的设计逻辑开始一层层剥开。2. 整体设计与思路拆解为什么是这16个问题而不是别的2.1 问题选择的底层逻辑从“技术可行”到“业务必要”拿到一份新数据集第一反应往往是“我能用它做什么SQL”——这是新手思维。而一个资深从业者的第一反应是“这张表里哪些字段组合起来能回答一个真实的、老板会问的问题”这16个问题绝不是随机排列的它们构成了一个严密的“业务洞察金字塔”。塔基是市场格局层问题1、2、5先搞清楚“谁在卖什么”。统计品牌数量、各品牌型号数、总价格分布这不是为了凑数字而是为了建立基准线。比如当你发现A品牌有87款机型B品牌只有12款但B品牌的总销售额却高出30%这立刻就指向一个关键结论B品牌走的是“少而精”的高端路线其营销资源必然高度集中。这个结论比任何市场报告里的“B品牌定位高端”都更硬核、更可验证。塔腰是产品力分层层问题3、6、7、8、9、10、11、12、14、16这是整个项目的主干。我把参数分成了四条主线性能线处理器品牌、核心数、主频、续航线电池容量、快充、体验线屏幕尺寸/刷新率/分辨率、RAM/内存、影像线后置摄像头数量。每一条线都对应着用户购买决策中的一个关键权重。例如问题6“按核心数给机型排名”单独看毫无意义但当你把结果和问题3“高评分机型”做交叉分析就会发现评分TOP10的机型里8款是8核2款是10核而没有一款是4核——这说明在当前市场8核已成为用户心智中的“及格线”低于此的机型无论其他参数多优秀都很难获得高口碑。这就是数据告诉你的、教科书上不会写的“市场水位线”。塔尖是策略推演层问题4、13、15这是体现分析深度的地方。问题4“非5G红外机型”是典型的“反向筛选”它强迫你思考在全面拥抱5G的时代为什么还有厂商坚持保留红外答案往往藏在渠道和用户画像里——线下中小门店、三四线城市、银发族市场。问题15的三维度综合排名则是模拟一个真实的选品场景如果你是电商平台的采购经理要在有限预算内引入一批新品你会优先考虑哪几个品牌这个排名结果可以直接作为采购建议书的附件。所以这16个问题本质上是一个从“看见市场”到“理解产品”再到“预判策略”的完整闭环。它不是为了展示SQL有多花哨而是为了证明数据分析师的价值不在于写出多复杂的窗口函数而在于让每一行代码都精准命中一个业务痛点。2.2 技术方案选型为什么坚持用纯SQL而不是Python/Pandas项目正文里通篇都是SQL代码这并非守旧而是一个经过深思熟虑的取舍。很多人一看到数据分析条件反射就是打开Jupyter Notebook导入pandas写几行groupby。但在这个特定场景下SQL有不可替代的优势。首先数据源的天然适配性。这份数据来自Kaggle格式是标准的CSV但它的结构是典型的“宽表”Wide Table一行代表一个手机型号一列代表一个属性如has_5g,has_ir_blaster。这种结构正是关系型数据库最擅长处理的范式。用SQL的GROUP BY配合COUNT(DISTINCT)一行代码就能搞定“各品牌型号数”而用pandas你需要先df.groupby(brand_name)[model].nunique()再reset_index()步骤更多且容易在链式操作中出错。更重要的是SQL的声明式语法天然契合业务语言。当产品经理说“我要看所有不支持5G但带红外的机型”你直接写WHERE has_5g 0 AND has_ir_blaster 1这和他说话的逻辑完全一致。而pandas里你得写df[(df[has_5g] 0) (df[has_ir_blaster] 1)]括号和符号的嵌套无形中增加了理解成本。最关键的是可复用性与协作性。在真实企业环境中这份分析报告很可能不是你一个人的“独奏”而是要交给BI工程师做仪表盘或者交给DBA部署到生产库。SQL是数据库的通用语言一份写好的查询可以无缝迁移到MySQL、PostgreSQL、甚至云端的BigQuery。而一段pandas脚本一旦环境变了比如pandas版本升级就可能报错。我见过太多项目因为一个pd.merge()的how参数默认值变化导致下游报表全军覆没。所以我坚持用SQL并且刻意避免使用任何数据库特有函数比如MySQL的GROUP_CONCAT确保所有代码在标准SQL引擎下都能跑通。这不是技术洁癖而是对交付质量的敬畏——让分析结果能真正落地比让它看起来很酷重要得多。2.3 窗口函数的深度应用不只是排序和求和而是构建动态视角项目正文里反复出现OVER()子句尤其是问题1和问题2中用到了SUM() OVER(ORDER BY ...)和SUM() OVER(PARTITION BY ... ORDER BY ...)。很多人把窗口函数当成高级GROUP BY这是巨大的误解。窗口函数真正的威力在于它能让你在保持原始行粒度的同时引入全局或局部的聚合视角从而看到数据的“流动感”。以问题1的“滚动求和”为例。原始需求是“计算每个品牌的型号数并按型号数降序排列同时显示累计总数”。如果不用窗口函数你得先用CTE算出各品牌型号数再用另一个CTE做累加最后JOIN回来。而SUM(number_of_models) OVER(ORDER BY number_of_models DESC, brand_name ASC)这一行就完成了全部工作。它的精妙之处在于ORDER BY子句它规定了“累计”的顺序。按型号数降序意味着累计和是从“型号最多的品牌”开始加起的。当你看到累计和达到“50%”时对应的那个品牌你就找到了市场的“二八分界线”——前N个品牌贡献了超过一半的型号供给。这个洞察是静态的COUNT(*)永远给不了的。再看问题2的SUM(total_cost) OVER(PARTITION BY brand_name ORDER BY total_cost)。这里PARTITION BY brand_name把数据按品牌切片ORDER BY total_cost则在每个品牌内部按单个机型的价格从小到大排序。这样算出来的累计和就告诉你对于A品牌价格最低的那款机型占其总销售额的X%加上第二便宜的占比变成Y%……直到加总到100%。这直接揭示了一个品牌的价格带健康度。如果前3款低价机就占了A品牌总销售额的80%说明它严重依赖走量机型而如果B品牌的累计和曲线非常平缓意味着它的销售额均匀分布在高中低各个价位段抗风险能力更强。所以窗口函数在这里已经超越了技术工具的范畴它是一种用数据构建商业叙事的修辞手法——它让数字自己开口讲述关于竞争格局、产品策略和用户偏好的故事。3. 核心细节解析与实操要点参数、陷阱与那些没人告诉你的事3.1 数据字段的“言外之意”别被字面意思骗了Kaggle上的数据集标题叫“Smartphones Dataset”字段名也都很直白比如battery_capacity、ram_capacity。但作为一个做过十几款硬件产品分析的老兵我必须提醒你这些字段名背后藏着大量需要人工校验的“潜规则”。如果你直接拿它们做分析得出的结论很可能是南辕北辙。先说battery_capacity电池容量。单位是什么毫安时mAh还是瓦时WhKaggle数据集通常不会在描述里写明但行业惯例是mAh。然而问题来了同样是5000mAh不同厂商的“实际可用容量”可能差3%-5%。这是因为电池有“保护板”会预留一部分电量防止过放。更隐蔽的是有些厂商会在宣传时把“典型容量”和“额定容量”混用前者略高后者才是国标认证值。所以当你用battery_capacity排序得出“TOP5电池容量机型”时这个榜单的绝对数值可能有水分但它反映的相对排名即A机型比B机型大多少依然是可靠的。我的做法是在报告里明确标注“基于数据集提供的标称容量”并附上一句小字提示“实际续航受系统优化、屏幕功耗等多重因素影响本分析仅作横向对比参考。”再说processor_speed处理器主频。这个字段的坑更大。它通常以GHz为单位比如“2.8 GHz”。但主频只是CPU性能的一个维度现代SoC系统级芯片是“大小核”架构一个芯片里可能有超大核、大核、小核各自频率不同。数据集里这个processor_speed大概率指的是超大核的最高主频。这意味着一个标称“3.2 GHz”的旗舰芯片和一个标称“2.4 GHz”的中端芯片它们的实际多任务性能差距远不止1.3倍。所以问题7“找最高主频的机型”结果只能告诉你“谁的纸面参数最猛”但不能告诉你“谁的日常体验最好”。要补足这一点我通常会额外查证第三方评测如Geekbench跑分把processor_speed和geekbench_single_core_score做一个散点图如果发现两者相关性很低R² 0.3那就必须在报告里强调“主频与用户体验弱相关建议结合多核跑分与实际场景测试综合评估。”最后是screen_size屏幕尺寸。单位是英寸这没问题。但问题在于它是“对角线长度”而用户感知的“屏幕大小”还和屏占比Screen-to-Body Ratio强相关。一个6.7英寸、屏占比85%的手机视觉上可能比一个6.8英寸、屏占比78%的手机更“大”。数据集里没有screen_to_body_ratio这个字段所以当你执行问题10“找屏幕最小的10款机型”时结果列表里可能会出现一款“6.1英寸但边框巨厚”的老款机型。这不算错误但你需要意识到这个结论的适用场景是“物理尺寸限制严格”的场景比如需要塞进某个固定模具而不是“用户主观感受最小”。资深分析师和新手的区别往往就体现在这种对字段局限性的清醒认知上。我的习惯是在每个分析结果后面都加一个“适用边界说明”哪怕只有一句话。3.2 “空值”不是脏数据而是未被定义的市场空间数据清洗时最常遇到的就是NULL。新手看到processor_brand IS NULL第一反应是删掉或填充。但在这个手机数据集里NULL往往是一个极其重要的信号。比如processor_brand字段为空可能意味着这款手机用的是联发科MediaTek或紫光展锐Unisoc的定制芯片而厂商出于某种原因可能是规避专利争议或是强调自研属性没有在公开参数里标明具体品牌。这在中低端机型中非常普遍。所以COUNT(DISTINCT processor_brand)的结果如果比你预期的少比如只看到高通、三星、华为海思那不是数据错了而是市场本身就有“隐形玩家”。我把这部分NULL单独拎出来命名为“Other/Custom”并在分析中单独讨论“‘Other/Custom’类处理器共覆盖XX款机型主要集中在YYY元价位段暗示该区间存在显著的芯片定制化趋势。”再比如has_ir_blaster是否带红外字段很多机型是NULL。这通常不是数据缺失而是厂商压根没提。在安卓阵营红外遥控早已不是标配主流厂商只在少数高端或特定系列如小米的数字旗舰上保留。所以NULL在这里大概率等同于0不支持。但为了严谨我会先做一次小范围抽样随机选10款has_ir_blaster为NULL的机型去官网查参数。如果8款确认不支持那就可以安全地将NULL映射为0。这个过程就是把“未知”转化为“已知”的专业动作。它比任何自动填充算法都可靠因为它基于对行业规则的理解而不是数学假设。提示永远不要对NULL做想当然的处理。它要么是数据采集的盲区要么是业务逻辑的留白。你的任务是通过交叉验证判断它属于哪一种并据此决定是剔除、映射还是作为一个独立的分析维度。3.3 排名逻辑的陷阱DENSE_RANK()、RANK()与ROW_NUMBER()选哪个项目正文里所有涉及“TOP N”的问题都统一使用了DENSE_RANK() OVER(ORDER BY ... DESC)。这不是随意选的而是针对手机参数数据的特性做出的最优解。我们来对比三种排名函数ROW_NUMBER()严格按顺序编号1, 2, 3, 4… 即使值相同也会给不同序号。RANK()值相同时给相同序号但会跳过后续序号。比如值为[10, 10, 8, 8, 6]RANK()结果是[1, 1, 3, 3, 5]。DENSE_RANK()值相同时给相同序号且不跳过后续序号。同样值[10, 10, 8, 8, 6]结果是[1, 1, 2, 2, 3]。为什么选DENSE_RANK()举个真实例子。问题3“Top 3 Highest rating brands”假设数据里有5个品牌的评分为[4.8, 4.8, 4.7, 4.7, 4.6]。用ROW_NUMBER()你会得到[1, 2, 3, 4, 5]那么“TOP 3”就只包含两个4.8分的品牌和一个4.7分的品牌漏掉了另一个同为4.7分的品牌。用RANK()结果是[1, 1, 3, 3, 5]“TOP 3”会包含两个4.8分和两个4.7分共4个品牌超出了“3”的要求。而DENSE_RANK()给出[1, 1, 2, 2, 3]WHERE rnk 3正好选出所有评分为4.8、4.7、4.6的品牌共5个——这恰恰符合业务需求我们要的是“评分最高的前三档品牌”而不是“恰好三个品牌”。在硬件参数领域分数/数值扎堆是常态比如电池容量5000mAh、5100mAh、5200mAh差别微乎其微DENSE_RANK()能最自然地反映出这种“梯队感”。所以这个选择不是语法偏好而是对业务语义的精准捕捉。4. 实操过程与核心环节实现从建表到生成16份洞察报告4.1 环境准备与数据加载用SQLite搭建轻量级分析沙盒虽然项目正文没提环境但实操的第一步永远是让数据“活”起来。我推荐用SQLite而不是动辄要装MySQL或PostgreSQL。理由很实在零配置、单文件、跨平台一个smartphones.db文件双击就能用DB Browser打开连命令行都不用碰。对于一次性的探索性分析它是最高效的沙盒。第一步下载Kaggle数据集通常是smartphones.csv。用Excel或VS Code打开检查前几行确认分隔符是逗号且没有乱码。然后启动DB Browser for SQLite点击“File” - “Import” - “Table from CSV file”。关键设置如下Table name:SmartPhones_data和正文SQL保持一致避免大小写混淆Encoding: UTF-8First row contains column names: ✅ 勾选Separator: Comma (,)Text qualifier: Double quote ()点击“OK”几秒钟后数据就导入成功了。此时你可以右键表名选择“Browse Data”直观地看到所有字段。接下来最关键的一步是创建索引。虽然SQLite是单文件但对大表10万行做GROUP BY或JOIN时索引能提速10倍以上。执行以下SQLCREATE INDEX idx_brand ON SmartPhones_data(brand_name); CREATE INDEX idx_processor ON SmartPhones_data(processor_brand); CREATE INDEX idx_rating ON SmartPhones_data(rating);这三个索引覆盖了16个问题中90%的WHERE和GROUP BY条件。别小看这三行它能让你在反复调试SQL时从“等待10秒”变成“瞬间返回”极大提升迭代效率。记住索引不是越多越好而是要精准打击高频查询路径。这是我踩过无数次坑后总结的铁律。4.2 逐个击破16个问题的完整SQL实现与原理注释现在我们进入核心环节。下面我将逐一实现所有16个问题并附上每一行代码背后的“为什么”。所有SQL均在SQLite 3.35版本下实测通过。4.2.1 问题1品牌与型号全景图含滚动求和-- 步骤1统计总品牌数和总型号数宏观概览 SELECT COUNT(DISTINCT brand_name) AS Number_of_brands, COUNT(DISTINCT model) AS Number_of_models FROM SmartPhones_data; -- 步骤2计算各品牌型号数并按数量降序排列同时计算滚动累计和 WITH brand_model_count AS ( SELECT brand_name, COUNT(DISTINCT model) AS number_of_models FROM SmartPhones_data GROUP BY brand_name ) SELECT brand_name, number_of_models, -- 关键SUM() OVER() 实现滚动求和ORDER BY number_of_models DESC 确保从最多品牌开始累加 SUM(number_of_models) OVER ( ORDER BY number_of_models DESC, brand_name ASC ) AS cumulative_models FROM brand_model_count ORDER BY number_of_models DESC, brand_name ASC;原理注释cumulative_models列的意义是回答“当我把市场从大到小依次纳入视野时累计覆盖了多少款机型”这比单纯看“某品牌有多少款”更有战略价值。例如前5个品牌累计覆盖了总型号数的65%这就意味着如果你想快速切入市场聚焦这5个品牌是性价比最高的选择。4.2.2 问题2价格结构深度剖析品牌、型号、组合三维透视-- 步骤1各品牌总销售额基础维度 SELECT brand_name, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY brand_name ORDER BY total_cost DESC; -- 步骤2各型号销售额颗粒度最细 SELECT model, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY model ORDER BY total_cost DESC LIMIT 10; -- 只看TOP10避免输出过长 -- 步骤3品牌-型号组合销售额并计算每个品牌内销售额的累计占比核心洞察 WITH brand_model_cost AS ( SELECT brand_name, model, SUM(price) AS total_cost FROM SmartPhones_data GROUP BY brand_name, model ), brand_cumulative AS ( SELECT brand_name, model, total_cost, -- PARTITION BY brand_name: 在每个品牌内部计算 -- ORDER BY total_cost DESC: 从贵的机型开始累加 SUM(total_cost) OVER ( PARTITION BY brand_name ORDER BY total_cost DESC, model ASC ) AS cumulative_cost_by_brand, SUM(total_cost) OVER (PARTITION BY brand_name) AS total_brand_cost FROM brand_model_cost ) SELECT brand_name, model, total_cost, ROUND(100.0 * cumulative_cost_by_brand / total_brand_cost, 2) AS cumulative_percentage FROM brand_cumulative WHERE cumulative_percentage 80.0 -- 找出贡献80%销售额的“核心机型” ORDER BY brand_name, cumulative_percentage;原理注释最后一行WHERE cumulative_percentage 80.0是点睛之笔。它直接输出了每个品牌里哪些机型共同贡献了其80%的销售额。这比看“平均单价”有用一万倍因为它揭示了品牌的“现金牛”在哪里。你会发现很多品牌其80%的销售额其实是由不到20%的爆款机型撑起来的。4.2.3 问题3高口碑机型TOP3DENSE_RANK实战-- 直接获取评分最高的3个“梯队”自动处理并列情况 SELECT brand_name, model, rating, rnk AS ranking FROM ( SELECT brand_name, model, rating, DENSE_RANK() OVER (ORDER BY rating DESC) AS rnk FROM SmartPhones_data WHERE rating IS NOT NULL -- 过滤掉无评分数据 ) ranked WHERE rnk 3 ORDER BY rnk, rating DESC, brand_name, model;原理注释WHERE rating IS NOT NULL是必须的。手机参数表里新发布的机型可能还没有用户评分NULL值参与ORDER BY会导致结果不可控。DENSE_RANK()确保了即使有多个4.8分的机型它们都会被归入rnk1这才是业务上想要的“第一梯队”。4.2.4 问题4非5G红外机型反向市场定位-- 精准筛选不支持5Ghas_5g0且支持红外has_ir_blaster1 -- 注意NULL值需先处理此处假设已将NULL映射为0不支持 SELECT brand_name, model, price, rating FROM SmartPhones_data WHERE has_5g 0 AND has_ir_blaster 1 ORDER BY price ASC;原理注释ORDER BY price ASC是关键。这类机型的目标用户对价格极度敏感所以按价格升序排列能一眼看出最具性价比的选项。这比单纯列出所有结果更能指导采购或营销决策。4.2.5 问题5处理器品牌格局市场集中度-- 统计处理器品牌总数及各品牌覆盖机型数 SELECT COUNT(DISTINCT processor_brand) AS number_of_processor_brands FROM SmartPhones_data WHERE processor_brand IS NOT NULL; -- 各处理器品牌覆盖的机型数量降序看谁是主力 SELECT processor_brand, COUNT(*) AS model_count FROM SmartPhones_data WHERE processor_brand IS NOT NULL GROUP BY processor_brand ORDER BY model_count DESC;原理注释WHERE processor_brand IS NOT NULL再次出现。这里我们不是要忽略NULL而是要明确知道“已知品牌”的市场格局。model_count的排序直接反映了高通、联发科等厂商的市场渗透力。如果“Other/Custom”排在第二那就是一个强烈的信号。4.2.6 问题6核心数排行榜性能门槛探测-- 获取所有机型的核心数并按核心数降序排名处理NULL SELECT model, COALESCE(num_cores, 0) AS number_of_cores, -- 将NULL转为0避免排序异常 DENSE_RANK() OVER (ORDER BY COALESCE(num_cores, 0) DESC) AS core_rank FROM SmartPhones_data ORDER BY core_rank, number_of_cores DESC, model;原理注释COALESCE(num_cores, 0)是处理NULL的标准姿势。在核心数这个维度NULL几乎可以等同于“未知但大概率不高”所以设为0是合理且安全的。core_rank的排名能帮你快速识别出“8核普及率”——即排名前X的机型里有多少是8核或以上。4.2.7 问题7最高主频机型纸面性能之王-- 找出主频最高的机型同样处理NULL SELECT brand_name, model, processor_speed, rnk FROM ( SELECT brand_name, model, COALESCE(processor_speed, 0.0) AS processor_speed, DENSE_RANK() OVER (ORDER BY COALESCE(processor_speed, 0.0) DESC) AS rnk FROM SmartPhones_data WHERE processor_speed IS NOT NULL ) ranked WHERE rnk 1;原理注释这里WHERE processor_speed IS NOT NULL是双重保险。COALESCE处理了NULLWHERE子句则确保了参与排名的都是有效数据避免了0.0被误排进TOP1。4.2.8 问题8电池容量TOP5续航焦虑解决方案-- TOP5电池容量机型注意单位统一为mAh SELECT brand_name, model, battery_capacity, rnk FROM ( SELECT brand_name, model, battery_capacity, DENSE_RANK() OVER (ORDER BY battery_capacity DESC) AS rnk FROM SmartPhones_data WHERE battery_capacity IS NOT NULL ) ranked WHERE rnk 5;原理注释battery_capacity通常不会有NULL但WHERE子句是好习惯确保数据质量。这个结果是给产品经理的“续航对标清单”他们可以拿着这个列表去研究TOP5机型的系统省电策略。4.2.9 问题9RAM与内存双TOP5存储体验标杆-- RAM和内存双维度综合排名先按RAM再按内存 SELECT brand_name, model, ram_capacity, internal_memory, rnk FROM ( SELECT brand_name, model, ram_capacity, internal_memory, DENSE_RANK() OVER ( ORDER BY ram_capacity DESC, internal_memory DESC ) AS rnk FROM SmartPhones_data WHERE ram_capacity IS NOT NULL AND internal_memory IS NOT NULL ) ranked WHERE rnk 5;原理注释ORDER BY ram_capacity DESC, internal_memory DESC体现了优先级。在用户心智中RAM运行内存的重要性通常高于ROM存储空间所以先按RAM排序。这个榜单是给供应链部门的“下一代旗舰配置参考”。4.2.10 问题10小屏机型TOP10细分市场蓝海-- 屏幕最小的10款机型升序排列 SELECT brand_name, model, screen_size, rnk FROM ( SELECT brand_name, model, screen_size, DENSE_RANK() OVER (ORDER BY screen_size ASC) AS rnk FROM SmartPhones_data WHERE screen_size IS NOT NULL ) ranked WHERE rnk 10;原理注释ORDER BY screen_size ASC是关键。小屏市场是典型的“小而美”用户群体明确手小、追求便携、厌恶大屏耗电这个列表就是他们的“购物车清单”。4.2.11 问题11刷新率品牌排名流畅度军备竞赛-- 按品牌平均刷新率排名更科学避免单个旗舰拉高均值 SELECT brand_name, ROUND(AVG(refresh_rate), 1) AS avg_refresh_rate, COUNT(*) AS model_count FROM SmartPhones_data WHERE refresh_rate IS NOT NULL GROUP BY brand_name ORDER BY avg_refresh_rate DESC, model_count DESC;原理注释这里没有用DENSE_RANK()而是用了AVG()。因为刷新率是“体验型”参数单个旗舰的240Hz不代表整个品牌的产品线水平。看“平均值”才能看出一个品牌对流畅体验的整体投入力度。4.2.12 问题12后置摄像头之王影像军备竞赛-- 找出后置摄像头数量最多的机型 SELECT brand_name, model, num_rear_cameras, rnk FROM ( SELECT brand_name, model, num_rear_cameras, DENSE_RANK() OVER (ORDER BY num_rear_cameras DESC) AS rnk FROM SmartPhones_data WHERE num_rear_cameras IS NOT NULL ) ranked WHERE rnk 1;原理注释num_rear_cameras的NULL值通常意味着“单摄”或“数据未录入”。WHERE子句确保了结果的准确性。这个结果是给影像算法团队的“硬件能力上限参考”。4.2.13 问题13操作系统分布生态壁垒分析-- 各品牌使用的操作系统类型及数量 SELECT brand_name, os_type, COUNT(*) AS count FROM SmartPhones_data WHERE os_type IS NOT NULL GROUP BY brand_name, os_type ORDER BY brand_name, count DESC;原理注释os_type字段通常包含“Android”, “iOS”, “HarmonyOS”等。这个查询的结果能清晰地画出各大厂商的“生态阵营”。比如如果一个品牌同时有Android和HarmonyOS机型那它很可能正处于生态切换期。4.2.14 问题14分辨率TOP5视觉体验天花板-- 分辨率最高的5款机型按PPI或分辨率数值此处假设为数值型 SELECT brand_name, model, resolution, rnk FROM ( SELECT brand_name, model, resolution, DENSE_RANK() OVER (ORDER BY resolution DESC) AS rnk FROM SmartPhones_data WHERE resolution IS NOT NULL ) ranked WHERE rnk 5;原理注释resolution字段在Kaggle数据集中有时是字符串如1080x2400有时是数值PPI。如果是字符串需要用SUBSTR等函数提取数字。这里假设为数值型便于演示。这个榜单是给UI/UX设计师的“视觉设计基准”。4.2.15 问题15三维度综合品牌排名策略推演-- 综合分辨率高、刷新率低、内存高三个维度给品牌打分 -- 先计算各维度的Z-Score标准化再加权求和权重分辨率0.4刷新率0.3内存0.3 WITH brand_stats AS ( SELECT brand_name, AVG(resolution) AS avg_resolution, AVG(refresh_rate) AS avg_refresh_rate, AVG(internal_memory) AS avg_internal_memory FROM SmartPhones_data WHERE resolution IS NOT NULL AND refresh_rate IS NOT NULL AND internal_memory IS NOT NULL GROUP BY brand_name ), z_scores AS ( SELECT brand_name, -- Z-Score (X - Mean) / StdDev (avg_resolution - (SELECT AVG(avg_resolution) FROM brand_stats)) / (SELECT STDDEV(avg_resolution) FROM brand_stats) AS z_res, (avg_refresh_rate - (SELECT AVG(avg_refresh_rate) FROM brand_stats)) / (SELECT STDDEV(avg_refresh_rate) FROM brand_stats) AS z_ref, (avg_internal_memory - (SELECT AVG(avg_internal_memory) FROM brand_stats)) / (SELECT STDDEV(avg_internal_memory) FROM brand_stats) AS z_mem FROM brand_stats ) SELECT
