用於量化投資策略（最高日頻率）研究的金融資料庫，用 MySQL 是否足夠？有哪些可能遇到的瓶頸？
想用開源的mysql來維護各類金融資產和相關經濟變數的歷史數據（例如股票、基金、債券、指數、期貨等的日頻率行情、基本面數據；再例如各類感興趣的經濟指標），但擔心以後數據多了發現無法支持，所以想了解mysql有哪些缺陷可能會限制將來的研究？
如果你是來做高頻數據，SQL絕對不是解決方案，光是調取數據的查詢就要等死你。至於如何解決可以另開一個專題討論。
題主提到的是最高日頻率的數據，其實能否夠這裡要分兩部分來討論。
第一部分是存儲
這個不會成為你的瓶頸。
因為從總容量來說，所有的金融數據（日以上級別）國內的加起來不超過20G（沒有文本數據）
任何一個伺服器的硬碟都足矣可以承受。
從單表來說，最大的表其實不是日行情表，而是債券的幾個表，我見過的最多的表大概有4億條數據。其實從SQL來說還是能夠承受的。
但是如果你真的要提高速度的話，建議對這類表進行拆分，把需要用到的數據放到一個小的表中並做好索引（這個很重要！！）
所以，如果談存儲這個角度，SQL不會遇到瓶頸。
那麼瓶頸在哪裡呢？
第二部分是讀取和計算
這個才是最大的問題所在，你做策略是一個不斷讀取和計算的過程。
一個辦法是把數據都讀出來，然後再計算
這個時候你會發現讀取會是一個很大的瓶頸，先不算SQL本身的查找計算時間
如果是一個10M的數據，你的網速是100k，那麼也需要100秒就是一分多鐘
何況如果你要取所有的股票所有交易日的數據可能還不止10M。
這個時候你就需要寫一些SQL語句盡量減少每次獲取的數據量
但是這樣會增加SQL本身的計算和join所需的時間。
所以這個是蹺蹺板的兩頭，需要你自己去找一個合適的平衡。
一頭是簡單的語句 大量的數據
一頭是複雜的語句 少量的數據
沒有什麼一定是最好的，也沒有什麼一定是最壞的，看個人的情況和能力
當以上都不能解決的時候，前面說的拆表，表結構優化也是解決方案。但是同樣的他其實是在犧牲硬碟空間和時間。
當你得到一樣的時候一定會失去一樣。
再進一步，如果以上都不滿足你的話。那就需要用內存資料庫的解決方案了，因為以我的經驗來說資料庫不可能降到秒級以下，而如果你要做一些策略回測或者優化的工作，或者在實戰中進行一些偏高頻的交易，那麼資料庫一定是不能滿足你的。
最後，這個夠和不夠是一個主觀的因素，還需要結合你自己本身的情況和要求來看這些問題。當然提高自身的能力是最重要的，各個方面的技能！關鍵還是看怎麼用，一般日內的行情數據都存在內存中直接調用，資料庫也只是保存一下數據這樣的操作。如果要用到很多歷史數據，從幾百萬的表中去查詢肯定是不對的，一般都是建立小規格的查詢表提高效率。另外，主鍵、索引等建立也非常關鍵。總之，要看你數據量多大，怎麼查詢，瓶頸在哪裡，然後怎麼優化。相比於mysql我還是建議你用mssql。
想說一句話：說mysql，sql sever做這種小系統性能不行的，基本都沒入過資料庫的門。 這種某個公司單個高頻系統相對於大型資料庫來說1%量級而已，雲系統用戶超級多的另外有別的辦法！
其實我推薦優先考慮mysql+infobright。
大家不要小看mysql的優化能力，其實用好了，還是很牛的。
用hadoop之類的感覺過於重型，一般來說，除非數據量真的達到幾十TB以上，不然沒必要。
nosql之類的，其實也可以考慮，但是對金融應用來說，開發工作量可能會比較大，所以感覺可能不太適合樓主的情況。謝邀
mysql用的不多，但直觀感覺日頻級別的數據需要的資源其實有限了，特別是只看中國市場的話。
問題在於你想要什麼數據和通過數據想幹啥。。。
我的理解把日級別的股票、期貨、宏觀經濟等等數據積累起來你其實是做了一個簡易版的資訊系統，而事實是從事金融行業的大家花一點點錢就可以從萬德之類的第三方資訊供應商那裡搞到這個東西。。。而且只會更專業、更詳細、更全面。
我認為你在後面最可能遇到的問題不是數據用mysql怎麼管理，而是保證數據的全面和數據的獲得上出問題。很多數據獲得途徑是很難整理的，股票價格行情是有數據介面的，但股票分紅、拆分、派息、停盤、公告等等這些信息是需要人去整理的；研究期貨你單單只知道期貨價格肯定不夠，大連現貨市場價格如何，原產地現貨市場價格如何，國外各個市場價格如何等等等等。第三方的諮詢供應商是花了很多人力物力在這個上面的，其實他們的軟體界面製作和資料庫維護難度不會太大。。。
然後下面就是說你想幹啥，做宏觀對沖交易？還是單純靠各種信息混合來做混合選股？一般來說做策略的時候不是在做加法，不是把市場所以狀態都包括進去了就一定能做出來一個好的賺錢的策略，好的策略一般來說是有簡單的或直接的交易邏輯存在的，可能是因為宏觀的經濟走勢走弱導致黃金比石油的價格上升，或者是統計結果顯示當某一特徵出現時某個品種價格會發生對應的走勢，這種策略是直觀的，有賺錢邏輯點的。而且對於這種策略的構造我不需要全市場狀態，只要取出來幾種我關注的即可。
所以我並沒有直接回答了你的問題，不過我覺你想做這個東西意義不是很大。。。總體來說，時間序列數據和非結構化的基本面數據，更適合於nosql資料庫處理。之前google過同樣問題，發現有人給出這樣的解決方案：文件系統分門別類建立層次結構+二進位文件存儲，實踐下來，發現還蠻好用。。。最近有在嘗試把數據導到hdf5中。
工作中我用過mysql和微軟的sql server,不知道是不是沒有設置好的緣故，mysql比sql server性能差了很遠。跑mysql的機器的CPU長期滿負荷。
這讓我對mysql印象不是很好
再次重申，我懷疑是我沒有設置好mysql運行參數，按照常理來說，mysql不應該那麼差
以我經驗,資料庫存金融數據,一般不會有大的問題,更何況還是日頻率的.因為你做的是復盤,你對延遲性要求不會這麼高,你不可能一次性面對幾億條數據要讀取出來這種情況,因為大部分情況下,你可以把數據過濾下,比如按股票過濾,按時間過濾...加上現在SSD,讀取的速度,一般情況下復盤用mysql不會出現瓶頸
其實資料庫出現瓶頸主要還是在低延遲上,比如要幾十ms幫我讀出這些些數據,幾十ms幫我寫數據又不可以鎖死...但題主顯然討論的不在這個範疇
早年曾經從bloomburg上扒了6000多個symbol下來 存在mysql里各種應用貌似無壓力....
kdb+
沒問題。不管你做什麼市場，不管你拿來多少基本面數據問題都不會出在資料庫軟體這一層
如果日後性能不夠那麼原因有可能是
1。 程序寫的不好或表設計問題
2。硬體太破
3。用資料庫做了不該拿資料庫做的事
我目前是用mysql做日頻率歐美股票市場，夠用，不過不是最優化。最重要注意backup和時間較長的讀寫資料庫的語句。 不要用express版本，有大小限制。如果經常刪除裡面的數據，要定時做資料庫優化，以獲得更大利用空間。
剛進來混數據的圈子，也不大懂，但是如果是高頻行情的話，單用資料庫是不行的，有些做量化的公司會把高頻行情數據導成文件存儲的格式。
新手回答，歡迎指正。
你說的日級別的數據mysql應該是足夠用了。
另外，在做研究的時候，不要每次都從資料庫讀數據，而是把該次研究用到的數據從資料庫讀出來另存成文件，多次研究的時候，從文件里讀取比資料庫快得多。
比如，matlab可以存到mat里。
留個坑，以後再填。
p.s.正在選資料庫，用來存放上證深證的大約&萬得低頻數據全庫大概才4g，單張表最大幾百兆，你怎麼並表查詢應該都問題不大
我做過,mysql足夠應對,沒什麼瓶頸
這麼多年的日數據統共也就千萬量級,選個簡單方案就好了.我做的優化是只按主鍵查詢,和用MyISAM引擎(基本上一次寫多次讀,數據安全性不重要)
為什麼都是推薦mysql的?這麼小的庫用oracle也不存在問題吧...看你是什麼類型的作用的資料庫是oltp還是olap的。。如果訪問量大。類似報表系統用olap就好了。
日線數據mysql足夠，小時級基本也能滿足，再高頻的話，我一般直接用mat文件。
日線頻率隨便啥資料庫都行，哪個順手用哪個
推薦閱讀：
※PostgreSQL 與 MySQL 相比，優勢何在？
※Facebook 用戶量十分龐大，為什麼還使用 MySQL 資料庫？
※網路遊戲伺服器與資料庫的關係？
※如何探究電影時長和製作年代的關係？