Ⅰ sql千萬級數據怎麼導出
千萬級導出TXT吧。否則其他載體可能放不下
Ⅱ mysql查詢千萬級別大表某一天的數據sql怎麼寫
查詢條件寫一天不就行么 跟是不是千萬級別的表有啥關系，卡的話加索引
Ⅲ MySQL 對於千萬級的大表要怎麼優化
第一優化你的sql和索引；
第二加緩存，memcached,redis；
第三以上都做了後，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這里就不多說了；
第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；
第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；
mysql資料庫一般都是按照這個步驟去演化的，成本也是由低到高；
有人也許要說第一步優化sql和索引這還用說嗎？的確，大家都知道，但是很多情況下，這一步做的並不到位，甚至有的只做了根據sql去建索引，根本沒對sql優化（中槍了沒？），除了最簡單的增刪改查外，想實現一個查詢，可以寫出很多種查詢語句，不同的語句，根據你選擇的引擎、表中數據的分布情況、索引情況、資料庫優化策略、查詢中的鎖策略等因素，最終查詢的效率相差很大；優化要從整體去考慮，有時你優化一條語句後，其它查詢反而效率被降低了，所以要取一個平衡點；即使精通mysql的話，除了純技術面優化，還要根據業務面去優化sql語句，這樣才能達到最優效果；你敢說你的sql和索引已經是最優了嗎?
再說一下不同引擎的優化，myisam讀的效果好，寫的效率差，這和它數據存儲格式，索引的指針和鎖的策略有關的，它的數據是順序存儲的（innodb數據存儲方式是聚簇索引），他的索引btree上的節點是一個指向數據物理位置的指針，所以查找起來很快，（innodb索引節點存的則是數據的主鍵，所以需要根據主鍵二次查找）；myisam鎖是表鎖，只有讀讀之間是並發的，寫寫之間和讀寫之間（讀和插入之間是可以並發的，去設置concurrent_insert參數，定期執行表優化操作，更新操作就沒有辦法了）是串列的，所以寫起來慢，並且默認的寫優先順序比讀優先順序高，高到寫操作來了後，可以馬上插入到讀操作前面去，如果批量寫，會導致讀請求餓死，所以要設置讀寫優先順序或設置多少寫操作後執行讀操作的策略;myisam不要使用查詢時間太長的sql，如果策略使用不當，也會導致寫餓死，所以盡量去拆分查詢效率低的sql,
innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在數據記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以並發的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一致性的非鎖定快照讀，也就是根據資料庫隔離級別策略，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是當前讀，讀取原始行；因為普通讀與寫不沖突，所以innodb不會出現讀寫餓死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競爭相同鎖的情況就少，就增加了並發處理，所以並發讀寫的效率還是很優秀的，問題在於索引查詢後的根據主鍵的二次查找導致效率低；
ps:很奇怪，為什innodb的索引葉子節點存的是主鍵而不是像mysism一樣存數據的物理地址指針嗎？如果存的是物理地址指針不就不需要二次查找了嗎，這也是我開始的疑惑，根據mysism和innodb數據存儲方式的差異去想，你就會明白了，我就不費口舌了！
所以innodb為了避免二次查找可以使用索引覆蓋技術，無法使用索引覆蓋的，再延伸一下就是基於索引覆蓋實現延遲關聯；不知道什麼是索引覆蓋的，建議你無論如何都要弄清楚它是怎麼回事！
盡你所能去優化你的sql吧！說它成本低，卻又是一項費時費力的活，需要在技術與業務都熟悉的情況下，用心去優化才能做到最優，優化後的效果也是立竿見影的！
Ⅳ sql server 到底能否處理百萬級，千萬級的數據
sql server 到底能否處理百萬級，千
最近又想起曾經被忽悠過n 次的問題。
剛畢業的時候，很多次去面試的時候被問及sql server 能處理能力，
以及上百萬級別的數據的優化問題？我當然是說東又扯西的，說了一大堆方法
我吹你吹了半天後，得到的提問著告訴我的很輕描淡寫的答案是：不行，
sql server 不行，百萬級別還是換oracle 好。
我當時總是很茫然的接受答案。因為我沒玩過，我沒發言權。(但是我搞
的緣由？是到今日，自己面試別人了，也還是不明白當時那些面試官的心態。)
。。。。。。兩年時間過去了。。。。。。
我很有幸在一個小門戶（其實也還好，不是那麼小了），玩過百萬級的數
據了。真是很榮幸還能玩到bbs 庫這樣的實時操作比較多的庫。
當我再一次在面試中被問到sql server 的處理能力的時候，我能很有底
氣的告訴他們sql server 能承受百萬級別的處理能力，我也實踐證明了它能。
這時候面試官總是表現得思維很敏捷，問題又很快出來了，處理千萬級別的數
做。 我再次追問面試官給出的答案當然還是無情的否認了sql server。
。。。。。又兩年時間過去了。。。。。。
目前又有幸玩門戶的bbs，記錄是過億的。每天這過億記錄的表的查詢次
數過了千萬，我當然現在沒有去面試，但是我還是真心的在這里希望不要碰到
問我sql server 處理百億級，千億級的數據的性能問題，更不希望告訴我答案
是換oracle。
sql server 我真為它難過。在這里我要為sql server 平反也想在此也問問各
位，目前用sql server 處理數據的級別和對它的看法，當然也可以評論下其他
人對sql server 的看法。
Ⅳ SQL千萬級資料庫模糊查詢問題
%開頭的模糊查詢是沒有辦法使用索引的，怎麼優化都沒有用。
一個建議，就是分析欄位的含義，以及典型的查詢需求，把這個欄位拆分為多個獨立欄位，分別建立索引，這樣查詢才爽。例如你這個數據，看起來是『年月日時分秒』的格式，可以把這些信息分散到年、月、日這樣的欄位裡面，就可以模糊查詢所有年度的【月】或者類似的復雜組合——需要模糊的內容不寫在WHERE裡面即可。
Ⅵ 千萬級數據量 我的sql 效率很慢：請問以下sql 如何優化
select distinct s.id
from student s,student tj
where (tj.biao ='0' or tj.biao= '1') and tj.yuwen<> 0 and s.id is not null
and s.score >= '500' /*總分大於500*/
and s.id = tj.id
and s.updatedate =
to_char(to_date('2012-12-04', 'yyyy-mm-dd'), 'yyyymmdd')
//group by tj.id
Ⅶ 千萬級別以上的資料庫如何去優化
第一優化你的sql和索引；
第二加緩存，memcached,redis；
第三以上都做了後，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這里就不多說了；
第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；
第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；
mysql資料庫一般都是按照這個步驟去演化的，成本也是由低到高。