這個個人認為是要看資料量，資料量小怎麼處理都可以，資料量大還是要根據效能之類做相應的處理。把資料都取出來是不推薦的一種行為。

做資料分析，我們要先看一下mysql的自帶的函式或者自己寫的函式、儲存過程之類的能不能幫助我們把問題給解決掉。資料中常用的統計彙總是不是就可以了。以下兩個函式是日常用的比較多的

group by/group_concat

group by/group_concat可以利用分組功能，將資料彙總到一個欄位，同時也可以進行相應的排序，例如將所學生的成績按照課程名稱彙總到3個欄位中，形如：

（姓名，課程名稱，課程成績）->(張三，數學|英語|...，90|80|...)

結合其它函式就可以很方便地找出想要的資料。

case when

case when類似於其它程式語言中的if...else...，我們可以透過對欄位值的判斷，然後得到我們想要的結果，形如，統計所有課程為數字的學生數，我們就可以透過

（case 課程名稱 when "數學" then 姓名 else null end）

所以透過這些函式的使用，可以幫助我們做一些簡單的邏輯判斷和較為複雜的彙總統計功能。

工作中我們碰到從訂單中隨機抽取某幾個訂單做為中獎名單，除了利用程式語言或者匯出資料在excel上處理，其實我們可以利用Mysql中的rand函式處理，

整體的原理是利用rand產生的一個0到1的小數，然後乘以一寫的倍數得到一個整數，再後透過整數與從訂單編號中取出的某幾位數相減，得到一個差值，取最大或者最小值做為我們選擇的依據，這樣一個簡單的隨機抽樣的方案就出來的。

Mysql中匯出資料，如果做為分析最好不要大批次地導，想清楚需要得到什麼分析結果，想想能不能利用工具本身的函式幫助我們解決問題，實在不行再想其它的工具幫助我們解決問題。

個人感覺這類問題毫無意義，一看就知道不是技術人提的，邏輯混亂。

出題者你能否告訴我一下，是槍好還是刀好嗎？

一切問題脫離了場景，便就沒有了答案。

業務需求決定了技術的選型以及採用的方式，技術是為業務服務的，業務成就技術。

沒有最好的方法，只有相對合適的方法。

一次取還是多次取，是受業務場景、資料量以及基礎設施等條件制約。假設資料量很小，那完全可以一次性取出，反之則可以透過分批處理來保證整個過程的穩定性與可靠性。

另外一個關鍵詞：“分析”。也就是說無論是一次還是分批，最終是要對資料進行整理與分析的。雖說資料庫主要的作用是用來儲存的，但是還是有一定的計算與整理能力的。我們在讀取資料的時候，為了方便更好的分析，可以考慮提前做一下處理。比如只讀取分析需要的維度資料，其他不需要的就不要讀取，降低壓力的同時也提高了效率。

兄弟呀，這就好比去銀行取錢。你老婆叫你取五塊錢買包鹽，你總不能去櫃檯取五次一塊吧；認識個妹紙不錯，不能動之以情，你想取錢去曉之以利，不琢磨你也知道，一次取好還是多次取好吧；再比如馬雲太太想稱稱自家的錢有多少噸，你想她能一次性取嗎。總之一句話，這是個度的問題，存乎一心，總的原則就是不給別人添麻煩，不給自己找罪受。太任性就是縱慾過“度”.

這裡需要有個假設：

假設資料必須從資料庫取出在程式內處理，而且所有資料都取出來後才可以處理。

在此假設下，要考慮的就是資料讀取效率的權衡。

單次讀取和多次讀取的區別在哪裡呢？

如果是多使用者的環境，並且資料量非常大，最好多次讀取，也給別的使用者讀取資料庫的機會。

如果是單使用者或者資料量不太大，兩種方式都可以，單次的邏輯簡單，總耗時較低。

當然，一切還是從實際出發，也許透過儲存過程就能把活幹了，還減少了資料傳輸的資源消耗。

在海量資料，高併發情況下，每次sql語句執行時間不要超過200ms，禁止連表查詢，禁止group by等涉及計算的sql語句。

mysql負責儲存，不要負責資料分析，合理利用冗餘欄位來減少連表，大資料量的分析，另外建庫，從主庫同步資料過去，讀取之後存中間表，或透過Hadoop等方式做資料分析

這實際上涉及到資料量問題，我之前有做過類似資料分析專案，我可以明確給的建議是如果是資料量小，就1000行那種，直接提取出來分析是最快的方案。如果是百萬級別的資料，機器記憶體無法支撐的情況下，這時候就需要分批處理，除非你有特殊的需求。

在資料量小的情況下，你還可以直接在SQL語句進行計算，當然平常我比較推薦在程式碼中計算，SQL只做讀寫，維護起來簡單明瞭。

在大資料下一般都要分塊處理，有個好處是利用叢集能夠將批次資料用相同的指令碼分到不同機器上去計算，計算後將資料再寫入叢集即可。

當然有些時序資料或者實時資料無法做到分塊處理，還是那句話，具體需求才能具體解決問題。

MySQL關係型資料庫管理系統，MySQL在當下是屬於最流行的關係型資料庫處理系統

它使用c和c＋＋編寫並使用了很多種的編譯器保證資料來源程式碼的可移植性，MySQL5.0的搜尋引擎，有很高的插入，但不支援事務。

主要還是看資料量來，這就涉及到MySQL的函式關係，在資料量小的情況下，直接用SQL進行計算就可以，簡單也方便維護，而在百萬級的資料下，則需要分塊資料進行處理。

group by 功能在方便你計算的時候做一個片段分類，但是MySQL資料作為儲存建議不要大批次的匯出。

MySQL關係型資料庫作為當下最流行的資料，它是一種開放原始碼的關係型資料庫管理系統。採用了結構化查詢語言的資料庫管理語言進行資料管理，MySQL因為其速度可靠性的高效率下，選擇MySQL是管理內容的最好選擇。

MySQL的資料匯入分為兩種，先匯入SQL指令碼，再匯入這種方法，直接複製資料的目錄和它的檔案。這種方法比較簡便，對於處理一些簡單的資料比較實用，而對於處理大型的資料話這就涉及到了分塊處理，需要用到函式，group by則是一個很好的選擇，它可以對資料片段進行處理，對大型資料比較實用，而對於小資料用SQL處理就行，另外，MySQL做為儲存不適合計算。

這種要看具體的情況才能決定是一次性提好還是分多次提取這取決於你的資料量

MySQL作為最常見的開放原始碼關係型資料庫管理系統，任何人都可以在general public license的許可權許可下載和進行修改，對於資料的匯入來說，MySQL分為兩種一是先匯入資料庫裡面的SQL指令碼再匯入，其次直接把資料庫的資料進行複製，當然這種情況可能發生不相容。

二是SQL的指令碼形式這種方法比較複雜，但是也比較穩定和效率，在處理資料的時候，一般的小資料建議直接用SQL處理就行，而涉及到大的資料還是要考慮其他方法，這其中就涉及到函式。group by這個函式就可以用於分段相同的資料處理，這樣比較方便，另外MYSQL只用於做資料的儲存，不適合用於計算資料。

這個是不一定的，各有各的好處和分情況看呢就MySQL來說它是一個開放原始碼的關係型資料庫管理系統，可以根據自己的個性下載和修改。

對於資料的處理這就涉及到函數了 group by 就是一個很不錯的函式，作用是透過一定的規則將一個數據分成多個小區域，針對於若干小區域進行資料的處理

但是在針對一些小資料的時候SQL就可以處理