簡介NBA歷史與當前比賽及球員統(tǒng)計數(shù)據(jù)集收錄了自1946年至今的完整比賽記錄覆蓋球員逐場數(shù)據(jù)、球隊表現(xiàn)、賽程與場館信息并補充了球員身高體重等生物特征資料。資源包共7個文件包含6個CSV表格和1個SQL數(shù)據(jù)庫文件壓縮包總大小79.65MBCSV文件便于用Excel或Python直接讀取SQL文件適合導(dǎo)入MySQL等數(shù)據(jù)庫完成多表關(guān)聯(lián)查詢可用于球員橫向?qū)Ρ?、球隊?zhàn)績分析或構(gòu)建比賽預(yù)測模型。目前已有410人學(xué)習下載。數(shù)據(jù)字段設(shè)計規(guī)范包含player_id、game_id、points、rebounds、assists、steals、blocks等核心指標既有1946年以來的歷史沉淀也涵蓋本賽季及下賽季賽程。借助SQL可輕松整合球員與球隊維度快速復(fù)現(xiàn)經(jīng)典賽季或追蹤職業(yè)生涯軌跡能大幅節(jié)省數(shù)據(jù)清洗時間支撐從基礎(chǔ)統(tǒng)計到深度挖掘的完整數(shù)據(jù)分析流程是籃球數(shù)據(jù)分析入門與進階的理想素材。1. 這份NBA球員數(shù)據(jù)集的價值不在“歷史全”而在表結(jié)構(gòu)已經(jīng)幫你拆好了這份NBA球員數(shù)據(jù)集覆蓋1946年至今的比賽和球員統(tǒng)計記錄6個Excel表格加SQL文件裝的不只是歷史數(shù)據(jù)而是一套已經(jīng)拆好表結(jié)構(gòu)的分析底座。很多人做NBA數(shù)據(jù)分析第一道坎不是SQL寫得不好而是數(shù)據(jù)獲取公開接口有調(diào)用限制網(wǎng)頁抓下來的數(shù)據(jù)又臟又亂最后還得自己清洗半天。這套數(shù)據(jù)集把球員、球隊、比賽三個核心實體拆成了獨立的表單場粒度和賽季匯總兩層數(shù)據(jù)都齊了。它適合四類人練SQL的、做體育數(shù)據(jù)分析的、寫課程設(shè)計或畢業(yè)設(shè)計的、想在本地搭一個完整數(shù)據(jù)分析項目練手的。導(dǎo)入數(shù)據(jù)庫就能寫復(fù)雜查詢打開Excel就能拖透視表不需要寫爬蟲也不需要調(diào)API。打開文件前先想清楚一個問題你拿到的不是“一堆數(shù)據(jù)”而是一個已經(jīng)建模好的關(guān)系結(jié)構(gòu)。后面所有分析動作都是在驗證這個結(jié)構(gòu)對不對、能不能支撐你的業(yè)務(wù)問題。接下來我按“摸清表結(jié)構(gòu) → 導(dǎo)入數(shù)據(jù)庫 → 清洗數(shù)據(jù) → 跑分析 → 避坑 → 搭復(fù)用模板”的順序講每一步都給可執(zhí)行的命令和參數(shù)。2. 先把數(shù)據(jù)裝進本地庫Excel導(dǎo)入SQL Server與MySQL的完整命令拿到數(shù)據(jù)集的第一件事不是寫分析而是把數(shù)據(jù)從Excel和SQL文件里安全地弄進數(shù)據(jù)庫。這個步驟看著簡單實際上決定了后面所有查詢的體驗。字符集、存儲引擎、字段類型這三樣沒搞對后面清洗時全都要返工。2.1 摸清六張表的家底字段、主鍵和表間關(guān)系先別急著導(dǎo)入。用Excel或任意編輯器把每個文件打開看一眼表頭。這類NBA數(shù)據(jù)集通常包含6個Excel表格按粒度可以分成兩類維度表球員、球隊和事實表比賽、球員比賽統(tǒng)計、球員賽季匯總、球隊賽季匯總。常見的表命名和字段如下具體列名以你拿到的文件為準表名常見命名粒度關(guān)鍵字段players每位球員一行player_id, player_name, birthdate, position, draft_year, is_activeteams每支球隊一行team_id, team_name, city, founded_year, is_activegames每場比賽一行g(shù)ame_id, game_date, home_team_id, away_team_id, home_score, away_score, season_typeplayer_game_stats每位球員每場比賽一行g(shù)ame_id, player_id, team_id, minutes, points, rebounds, assists, turnoversplayer_season_stats每位球員每個賽季一行player_id, team_id, season_start, games_played, points, avg_pointsteam_season_stats每支球隊每個賽季一行team_id, season_start, wins, losses, home_record, away_record打開文件后重點確認三件事第一每一張表有沒有主鍵字段通常是player_id、team_id、game_id這類帶id后綴的列第二player_game_stats是連接球員和比賽的事實表它的game_id能否在games表里找到對應(yīng)記錄第三season字段是“2023-24”這種格式還是單獨的起始年份。這三件事確認完再考慮導(dǎo)入。這六張表的關(guān)系可以這樣理解players和teams是維度表提供名字、位置、城市等描述信息games和player_game_stats是明細表記錄每場比賽發(fā)生了什么兩個season_stats表是預(yù)先聚合好的匯總表省去了重復(fù)計算賽季數(shù)據(jù)的麻煩。做分析時優(yōu)先從匯總表入手需要單場維度再下鉆到明細表。2.2 用SQL文件建庫建表執(zhí)行腳本前必改的三個參數(shù)SQL文件里通常是建庫建表語句加INSERT數(shù)據(jù)。先建一個空庫再執(zhí)行整個腳本。以MySQL為例mysql -u root -p -e CREATE DATABASE nba_analysis DEFAULT CHARACTER SET utf8mb4; mysql -u root -p nba_analysis /path/to/nba_dataset.sql如果是SQL Server 2016及以上版本用sqlcmd工具執(zhí)行sqlcmd -S localhost -U sa -P your_password -d NBA -i /path/to/nba_dataset.sql執(zhí)行前檢查SQL文件里三個關(guān)鍵點。第一是字符集文件頭部有沒有SET NAMES utf8mb4。沒有的話包含中文球員名比如國際球員的表導(dǎo)入后大概率亂碼建議文件頭和數(shù)據(jù)庫都統(tǒng)一成utf8mb4。第二是存儲引擎確認建表語句是ENGINEInnoDB如果寫的是MyISAM改成InnoDB再執(zhí)行。MyISAM不支持事務(wù)和外鍵后面做數(shù)據(jù)修復(fù)時會非常被動。第三是DROP TABLE語句SQL文件里通常有DROP TABLE IF EXISTS如果庫里已經(jīng)有同名表且里面有手工修改過的數(shù)據(jù)執(zhí)行前先備份。SQL Server環(huán)境下執(zhí)行還要注意SQL文件里的批處理分隔符。如果你的SQL文件里包含視圖或存儲過程定義文件里會有GO語句sqlcmd能識別如果是從MySQL風格改過來的文件里面有DELIMITER $$需要先在SSMS里把這段存儲過程定義單獨復(fù)制出來執(zhí)行不然整批執(zhí)行會報語法錯誤。這是很多人第一次導(dǎo)入失敗的原因。2.3 Excel表導(dǎo)入的兩種姿勢圖形界面和命令行都走一遍SQL文件負責建表結(jié)構(gòu)6個Excel表格負責灌數(shù)據(jù)。如果SQL文件里已經(jīng)包含了完整的數(shù)據(jù)INSERT語句Excel部分只需要做校驗如果SQL文件只有結(jié)構(gòu)沒有數(shù)據(jù)就需要把Excel導(dǎo)入。圖形界面適合一次性操作。SQL Server Management Studio里右鍵目標數(shù)據(jù)庫 → 任務(wù) → 導(dǎo)入數(shù)據(jù) → 選擇數(shù)據(jù)源“Microsoft Excel” → 選擇工作表 → 映射字段。MySQL Workbench則用Table Data Import Wizard右鍵目標表 → Table Data Import。圖形界面有個好處是導(dǎo)入前能看到字段映射預(yù)覽但每一步都要點鼠標重復(fù)導(dǎo)入時效率很低。命令行方式適合反復(fù)執(zhí)行和寫進腳本。先把Excel另存為CSV文件注意編碼選UTF-8然后執(zhí)行LOAD DATA INFILE /var/lib/mysql-files/players.csv INTO TABLE players CHARACTER SET utf8mb4 FIELDS TERMINATED BY , ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 ROWS;這個命令的參數(shù)說明CHARACTER SET utf8mb4強制按UTF-8解析CSV防止中文亂碼FIELDS TERMINATED BY ,指CSV用逗號分隔ENCLOSED BY 處理字段值里的逗號比如球員名字里有逗號時會被雙引號包起來IGNORE 1 ROWS跳過表頭的列名。MySQL默認對LOAD DATA INFILE有限制文件要放在/var/lib/mysql-files/目錄下或者用LOCAL關(guān)鍵字從客戶端本地上傳。如果報“file not found”錯誤檢查文件路徑和secure_file_priv變量。3. 拿到數(shù)據(jù)先別急著分析NBA統(tǒng)計里繞不開的清洗三板斧NBA數(shù)據(jù)集的臟數(shù)據(jù)非常典型。為什么因為NBA有70多年的歷史早期的統(tǒng)計靠人工記錄口徑和現(xiàn)在完全不一樣球員會重名球隊會遷址換名賽季又跨年。這些歷史包袱讓數(shù)據(jù)清洗成為整個分析流程里最耗時的環(huán)節(jié)。我把最常見的三個問題整理成了三板斧。3.1 球員重名與球隊遷址用player_id和team_id做主鍵而不是名字NBA歷史上有大量重名球員比如叫John Williams的在不同年代就有好幾位。只看球員名字做關(guān)聯(lián)統(tǒng)計結(jié)果一定會翻車。同樣球隊也有這個問題雷霆隊的前身是西雅圖超音速球隊從西雅圖遷到俄克拉荷馬城之后數(shù)據(jù)怎么算如果直接用球隊名做關(guān)聯(lián)歷史數(shù)據(jù)和當前數(shù)據(jù)會分成兩段。這類數(shù)據(jù)集通常已經(jīng)用player_id和team_id做了代理主鍵這是最好的情況。先用一條SQL驗證重名問題是否存在SELECT player_name, COUNT(DISTINCT player_id) AS id_count FROM players GROUP BY player_name HAVING COUNT(DISTINCT player_id) 1 ORDER BY id_count DESC;如果查詢結(jié)果里出現(xiàn)了id_count大于1的行說明確實有重名球員。后續(xù)所有關(guān)聯(lián)查詢一律用player_idplayer_name只做展示。球隊同理所有比賽統(tǒng)計表里的team_id才是不變的身份標識team_name只代表“這一個名字”不代表“這一支球隊”。3.2 賽季劃分與“當前”口徑正則賽季和latest標志位的處理NBA賽季是跨年的2023-24賽季從2023年底打到2024年中。數(shù)據(jù)集的season字段常見寫法是“2023-24”或“202324”分析時需要統(tǒng)一成起始年份作為排序和分組的依據(jù)。另外games表里通常包含季前賽、常規(guī)賽、季后賽三種類型混在一起算勝率會得出沒有意義的結(jié)果。把賽季字符串轉(zhuǎn)成起始年份的寫法MySQL和SQL Server不一樣-- MySQL提取2023-24中的起始年份 SELECT game_id, CAST(SUBSTRING_INDEX(season, -, 1) AS UNSIGNED) AS season_start FROM games; -- SQL Server提取2023-24中的起始年份 SELECT game_id, CAST(LEFT(season, CHARINDEX(-, season) - 1) AS INT) AS season_start FROM games;分析比賽時記住每個查詢都加上賽季類型過濾。先確認數(shù)據(jù)里season_type有哪幾個取值用SELECT DISTINCT season_type FROM games;查一下然后統(tǒng)一加WHERE season_type Regular Season。球員表里的is_active字段也要注意有的數(shù)據(jù)集用布爾值有的用字符串“Y/N”還有的沒有這個字段。要不要篩“當前球員”取決于你的分析目標是全歷史視角還是本賽季視角兩種視角用的表結(jié)構(gòu)完全不同。3.3 缺失值和異常值分鐘數(shù)為0但得分不為0的數(shù)據(jù)要小心還有一種很常見的臟數(shù)據(jù)出場時間為0的球員卻有得分。這不是數(shù)據(jù)錄入錯誤而是NBA規(guī)則里技術(shù)犯規(guī)罰球不算出場時間但得分會計入。這類數(shù)據(jù)會污染場均指標的計算。另外早期比賽數(shù)據(jù)里還可能出現(xiàn)出手數(shù)小于命中數(shù)、籃板數(shù)超過理論值的記錄這些是原始錄入錯誤沒法靠業(yè)務(wù)規(guī)則解釋。清洗策略分兩步。第一步把明顯違反業(yè)務(wù)規(guī)則的記錄標記出來比如SELECT player_name, game_id, minutes, points FROM player_game_stats WHERE minutes 0 AND points 0;這種記錄如果出現(xiàn)在常規(guī)賽明細里大概率是技術(shù)犯規(guī)罰球如果出現(xiàn)在季后賽就要人工核對。第二步?jīng)Q定是刪除還是保留。我的習慣是不直接刪除而是加一個數(shù)據(jù)質(zhì)量標記字段比如把這類記錄標成flag_data_issue 1。因為數(shù)據(jù)分析項目的第一步產(chǎn)出往往是清洗報告列出有多少條記錄存在異常、異常集中在哪些年份和球隊這本身就很有分析價值。直接刪掉會讓報告的“異常發(fā)現(xiàn)”部分無話可寫。4. 從六張表里挖出真東西三類能直接上手的NBA數(shù)據(jù)分析項目數(shù)據(jù)準備好了接下來才是正經(jīng)的分析環(huán)節(jié)。我挑了三個頗有代表性的分析方向分別對應(yīng)SQL窗口函數(shù)、多表聚合和Excel透視表三種技能。這三個方向做下來這套數(shù)據(jù)集的絕大部分價值你就摸透了。4.1 球員生涯趨勢分析用SQL窗口函數(shù)算場均得分曲線單個球員的賽季表現(xiàn)變化是最直觀的分析需求也最能體現(xiàn)數(shù)據(jù)集的價值。先看一個球員的基礎(chǔ)賽季數(shù)據(jù)SELECT player_name, season_start, games_played, points, avg_points FROM player_season_stats WHERE player_name LeBron James ORDER BY season_start;這個查詢能直接看到每個賽季的出場數(shù)和得分數(shù)。但單賽季數(shù)據(jù)波動大傷病、停擺、換隊都會造成突然的下滑或提升直接看原始曲線得到的信息有限。更好用的是移動平均把鄰近三個賽季的場均得分做平滑可以消除單賽季噪音看出真正的長期趨勢SELECT player_name, season_start, avg_points, AVG(avg_points) OVER (PARTITION BY player_name ORDER BY season_start ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS ma_3 FROM player_season_stats WHERE player_name LeBron James;窗口函數(shù)的參數(shù)說明PARTITION BY player_name表示對每個球員單獨計算窗口不會跨球員混算ORDER BY season_start確定排序規(guī)則這是移動平均的方向ROWS BETWEEN 2 PRECEDING AND CURRENT ROW定義窗口范圍是當前賽季及前兩個賽季。得到的三期移動平均曲線比原始數(shù)據(jù)平滑得多巔峰期和衰退期一眼就能看出來。ROWS BETWEEN ... PRECEDING是窗口函數(shù)里最常用的滑窗寫法比RANGE更適合處理時間序列因為RANGE遇到并列排序時會擴大范圍產(chǎn)生預(yù)期外的結(jié)果。4.2 球隊歷史戰(zhàn)績對比賽季勝率與主客場差異統(tǒng)計球隊層面的分析有個繞不開的數(shù)據(jù)重塑問題games表里一場比賽只有一行主隊和客隊在同一行里。要統(tǒng)計每支球隊的勝率需要把一行拆成兩行來算。這里用UNION ALL比用表自連接更直觀、更好維護SELECT team_id, season_start, SUM(is_home) AS home_games, SUM(CASE WHEN is_home 1 AND team_score opp_score THEN 1 ELSE 0 END) AS home_wins, SUM(1 - is_home) AS away_games, SUM(CASE WHEN is_home 0 AND team_score opp_score THEN 1 ELSE 0 END) AS away_wins FROM ( SELECT game_id, home_team_id AS team_id, home_score AS team_score, away_score AS opp_score, 1 AS is_home, season_start FROM games WHERE season_type Regular Season UNION ALL SELECT game_id, away_team_id AS team_id, away_score AS team_score, home_score AS opp_score, 0 AS is_home, season_start FROM games WHERE season_type Regular Season ) t GROUP BY team_id, season_start;邏輯說明子查詢把每場比賽拆成了主客兩行is_home字段標記這行是主隊還是客隊外層查詢按球隊和賽季分組用CASE WHEN判斷主客場的勝負。這個寫法之后想擴展加“凈勝分”也很容易在子查詢里多算一列team_score - opp_score就可以。這個量級的數(shù)據(jù)集在MySQL里跑窗口函數(shù)和UNION ALL沒有任何壓力不需要動用Spark之類的分布式框架。4.3 球員橫向?qū)Ρ扔肊xcel透視表實現(xiàn)MVP級篩選不是所有分析都要寫SQL。6個Excel表格里自帶了賽季匯總表打開它就能做透視表分析適合不想搭數(shù)據(jù)庫、用Excel快速出結(jié)果的場景。操作步驟打開球員賽季匯總表全選數(shù)據(jù)后按CtrlT轉(zhuǎn)成正規(guī)表格插入 → 透視表行區(qū)域放player_name列區(qū)域放season_start值區(qū)域放avg_points設(shè)為平均值數(shù)據(jù)范圍選最近十個賽季這樣可以保證對比的是同時代的球員。透視表做出來后在“行標簽”右側(cè)加篩選條件games_played大于等于50才納入統(tǒng)計然后按“平均值項: avg_points”降序排序就能看到每個球員的場均得分排名。如果透視表太長不好找某個球員直接CtrlF輸入名字快速定位不用拖動滾動條翻幾千行。想突出頂級球員用條件格式 → 數(shù)據(jù)條得分越高條越長視覺上非常直觀。這套操作也回答了“Excel到底適不適合做體育數(shù)據(jù)分析”這個問題做單維度的排名對比Excel透視表比SQL更方便因為它不需要寫GROUP BY拖拽字段就行。5. NBA數(shù)據(jù)集避坑指南字段陷阱、編碼問題和SQL執(zhí)行報錯這部分是我實際用這類歷史體育數(shù)據(jù)集過程中踩過的坑。每一條都是“現(xiàn)象 → 原因 → 解決”的結(jié)構(gòu)你大概率會遇到其中至少兩條。5.1 現(xiàn)象導(dǎo)入SQL文件后中文亂碼現(xiàn)象執(zhí)行完SQL文件后查詢含有中文球員名的表顯示的是“????”或繁體亂碼。原因SQL文件本身是UTF-8編碼但數(shù)據(jù)庫客戶端連接時用了默認的latin1字符集導(dǎo)致寫入時編碼翻譯錯誤。解決執(zhí)行前確認數(shù)據(jù)庫和連接兩層字符集都設(shè)成utf8mb4。MySQL在命令行加參數(shù)mysql -u root -p --default-character-setutf8mb4 nba_analysis /path/to/nba_dataset.sql如果已經(jīng)導(dǎo)入了把亂碼數(shù)據(jù)所在表清空重新導(dǎo)一遍不要試圖用UPDATE修復(fù)亂碼因為源字符已經(jīng)丟了。另外從Excel另存CSV時老版本Excel默認存成ANSI編碼里面如果有中文導(dǎo)入后也是亂碼。要選“CSV UTF-8帶分隔符”格式或者先用記事本打開CSV看中文是否正常顯示再導(dǎo)入。5.2 現(xiàn)象球員統(tǒng)計數(shù)字對不上現(xiàn)象按球員名字匯總得分發(fā)現(xiàn)某位球員的生涯總得分比官方數(shù)據(jù)多了一大截。原因極大概率是重名球員被合并了。NBA歷史上叫Michael Williams、John Williams這類常見名字的球員有好幾位如果分析時用GROUP BY player_name而不是GROUP BY player_id這些球員的得分會算到同一個人頭上。解決所有聚合查詢一律用player_id或player_name加player_id聯(lián)合分組。數(shù)據(jù)集的players表里看到同一年代有兩個相同的名字先查一下是不是不同的人。這也是為什么這個數(shù)據(jù)集的主鍵字段值得特別關(guān)注的原因。5.3 現(xiàn)象日期字段排序不對現(xiàn)象比賽日期按時間排序時“2024-1-5”排在“2024-1-15”后面看起來像亂序。原因Excel里日期保存成了文本格式導(dǎo)入數(shù)據(jù)庫后是VARCHAR類型字符串排序按ASCII碼逐位比較所以“1-15”的第二個字符“1”排在了“1-5”的第二個字符“-”前面。解決導(dǎo)入時把日期字段顯式轉(zhuǎn)換或者導(dǎo)入后用一條UPDATE把文本日期轉(zhuǎn)成真正的DATE類型UPDATE games SET game_date STR_TO_DATE(game_date, %Y-%m-%d) WHERE game_date IS NOT NULL AND game_date ;MySQL用STR_TO_DATESQL Server用CONVERT(DATE, game_date, 120)。轉(zhuǎn)完后把字段類型改成DATE以后排序、比較效率都會正常。如果Excel文件太大不想動也可以在Excel里用“分列”功能把文本日期轉(zhuǎn)成日期格式再另存。5.4 現(xiàn)象Excel雙擊SQL文件打不開現(xiàn)象在Windows里雙擊SQL文件Excel彈出“文件格式與擴展名不匹配文件已損壞”之類的提示或者直接亂碼。原因SQL文件是純文本文件但系統(tǒng)里設(shè)置的默認打開程序是ExcelExcel不識別SQL文件的擴展名。解決SQL文件用Visual Studio Code、Notepad或系統(tǒng)自帶的記事本打開不要雙擊。Excel只負責打開那6個Excel文件兩者職責分開。這個現(xiàn)象沒什么技術(shù)含量但幾乎每個第一次接觸數(shù)據(jù)集的人都會試一次屬于純粹的體力坑。5.5 現(xiàn)象導(dǎo)入幾萬行數(shù)據(jù)耗時很長聯(lián)表查詢也慢現(xiàn)象執(zhí)行SQL文件導(dǎo)入數(shù)據(jù)要等好幾分鐘導(dǎo)入后寫了一條三聯(lián)表的查詢跑了幾十秒才出結(jié)果。原因SQL文件里的INSERT語句沒有包在事務(wù)里每插入一行就提交一次磁盤寫入次數(shù)太多另外表上沒建索引聯(lián)表查詢每次都要全表掃描。解決導(dǎo)入前關(guān)閉自動提交批量導(dǎo)入完成后再一次性提交。MySQL的命令行導(dǎo)入方式可以這樣處理SET autocommit 0; SOURCE /path/to/nba_dataset.sql; COMMIT;建索引是更關(guān)鍵的一步。主鍵字段player_id、game_id、team_id在導(dǎo)入時會自動建索引但外鍵關(guān)聯(lián)字段不一定會建。建議在player_game_stats表的game_id、player_id、team_id三列上各加一個普通索引查詢速度會有數(shù)量級提升。EXPLAIN SELECT ...看一下執(zhí)行計劃如果看到“ALL”類型的訪問方式說明在掃全表這就是慢sql優(yōu)化里需要優(yōu)先處理的信號。這個量級的數(shù)據(jù)索引建好之后窗口函數(shù)和聯(lián)表查詢都該在秒級內(nèi)返回。6. 讓數(shù)據(jù)集活起來用視圖和參數(shù)化查詢搭一個可復(fù)用的分析模板數(shù)據(jù)集最大的價值不是一次性用而是反復(fù)查。我建議把最常用的聯(lián)表邏輯固化成一個寬表視圖再配上參數(shù)化查詢以后做任何分析都不需要重新寫長SQL。先建一個球員單場明細寬表視圖把六張表中的球員維度、球隊維度和比賽維度一次性JOIN好CREATE VIEW v_player_game_detail AS SELECT g.game_id, g.game_date, g.season_start, g.season_type, p.player_id, p.player_name, t.team_id, t.team_name, s.minutes, s.points, s.rebounds, s.assists, s.turnovers FROM player_game_stats s JOIN games g ON s.game_id g.game_id JOIN players p ON s.player_id p.player_id JOIN teams t ON s.team_id t.team_id;視圖建好之后所有臨時分析只需要從這個寬表里SELECT不用再考慮關(guān)聯(lián)條件和表名。再做一個存儲過程把“輸入球員名直接輸出生涯賽季數(shù)據(jù)”封裝成參數(shù)化查詢CREATE PROCEDURE GetPlayerCareer(IN player_name_param VARCHAR(100)) BEGIN SELECT season_start, games_played, points, avg_points FROM player_season_stats s JOIN players p ON s.player_id p.player_id WHERE p.player_name player_name_param ORDER BY season_start; END;調(diào)用時直接輸入名字CALL GetPlayerCareer(Michael Jordan);存儲過程的好處是參數(shù)可以復(fù)用不用每次改SQL文本配合Excel的ODBC連接可以在Excel單元格里直接調(diào)用并刷新結(jié)果把SQL能力搬回Excel界面。如果你更習慣用python做數(shù)據(jù)分析也可以把視圖結(jié)果導(dǎo)出成CSV交給pandas處理后續(xù)的可視化。做球員職業(yè)生涯時間線時用Excel甘特圖展示職業(yè)生涯長度和單賽季場均得分峰值是個不錯的落地視角一屏就能看清整個走勢。我個人養(yǎng)成的習慣是拿到任何數(shù)據(jù)集先不改原始表第一件事是跑一遍每張表的行數(shù)、主鍵唯一性和外鍵完整性把結(jié)果存成一張數(shù)據(jù)質(zhì)量檢查表再做任何修改前備份原表等于給自己留一顆后悔藥。這套NBA數(shù)據(jù)集的表結(jié)構(gòu)設(shè)計得比較干凈分析潛力和鍛煉價值都相當大但最后跑出來的報告能不能讓人信服完全取決于清洗和關(guān)聯(lián)做得扎不扎實。希望幫到你。本文還有配套的精品資源點擊獲取