每次篩選1000條，多篩選幾次就可以了。
SELECT TOP 1000...
謝謝，請採納！
⑵ mysql為什麼千萬級別查詢比1000條數據的查詢慢
這是自然規律使然。形象一點來講，有人將各一枚硬幣分別丟進一碗水裡和一口水塘里，然後您要將它們撈出來，哪個任務完成的快？當然是前者了，因為工作量沒法比啊！
資料庫查詢道理也是一樣的，數據越多從中檢索出記錄的速度越慢。你也許會說資料庫不是有索引嗎？咱不用從頭到尾逐條檢索呀。沒錯，有索引資料庫引擎可以直奔目標，檢索少量數據的時候，1千條記錄跟千萬條記錄比，從中檢索出記錄的耗時相差無幾，但是如果要檢索出所有記錄的話，兩者的系統和時間開銷可就不是一個數量級了，後者肯定慢得多。
管理一個小倉庫跟管理一個巨型倉庫的人力、物力開銷肯定是不一樣的，資料庫表查詢也同理！
⑶ mysql資料庫千萬級得表一下查詢超時怎麼優化
第一優化你的sql和索引；
第二加緩存，memcached,redis；
第三以上都做了後，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這里就不多說了；
第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；
第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；
mysql資料庫一般都是按照這個步驟去演化的，成本也是由低到高；
⑷ MySQL資料庫千萬級數據處理
也就是A表中保留B表中存在的數據，可以通過篩選把這樣的數據放在第三個表
只要索引合理，數據量不算大
祝好運，望採納。
⑸ 怎麼快速復制千萬級的Mysql資料庫表
我google了一下大概有一下幾個方法，
1.復製表結構及數據到新表
CREATE TABLE 新表 SELECT * FROM 舊表
2.只復製表結構到新表
CREATE TABLE 新表 SELECT * FROM 舊表 WHERE 1=2
即:讓WHERE條件不成立.
3.復制舊表的數據到新表(假設兩個表結構一樣)
INSERT INTO 新表 SELECT * FROM 舊表
4.復制舊表的數據到新表(假設兩個表結構不一樣)
INSERT INTO 新表(欄位1,欄位2,.......) SELECT 欄位1,欄位2,...... FROM 舊表
⑹ mysql千萬或者上億的數據怎麼設計資料庫
單表一億？還是全庫1億？
1.首先可以考慮業務層面優化，即垂直分表。
垂直分表就是把一個數據量很大的表,可以按某個欄位的屬性或使用頻繁程度分類,拆分為多個表。
如有多種業務類型，每種業務類型入不同的表，table1,table2,table3.
如果日常業務不需要使用所有數據，可以按時間分表，比如說月表。每個表只存一個月記錄。
2.架構上的優化，即水平分表。
水平分表就是根據一列或多列數據的值把數據行放到多個獨立的表裡，這里不具備業務意義。
如按照id分表，末尾是0-9的數據分別插入到10個表裡面。
可能你要問，這樣看起來和剛才說的垂直分表沒什麼區別。只不過是否具備業務意義的差異，都是按欄位的值來分表。
實際上，水平分表現在最流行的實現方式，是通過水平分庫來實現的。即剛才所說的10個表，分布在10個mysql資料庫上。這樣可以通過多個低配置主機整合起來，實現高性能。
最常見的解決方案是cobar，這個帖子介紹的比較完善，可以看看。
http://blog.csdn.net/shagoo/article/details/8191346
cobar的邏輯層次圖：
不過這種分庫方式也是有一定局限性的，需要應用程序做相應的配合，比如說分庫的情況下，雖然可以實現跨庫查詢，但是不能進行相關的group by計算。
另外，之前關於水平分表的實現方式，也可以通過表分區來實現。
mysql優化的方式有很多，選擇上主要還是要考慮個人的實際情況，如代碼不可控的情況下，就不適合選擇按欄位屬性分表的情況，這樣可能會帶來大量的重構以及很多不可預期的風險。
而架構的優化，雖然對應用是透明的，但對sql的寫法有很多局限性，比如說不能使用聚合函數等等，同時也需要有充足的硬體資源，只有一台伺服器的情況下是沒有意義的。
相比起來，代價最低的是按時間分表或分區，這兩種辦法對應用來說都是透明的。
分區只需要一次本地數據遷移的操作。
而通過分表把現網數據和歷史數據分離，唯一的代價是定期的數據維護。
一般如果表裡面有1億數據的情況下，索引的問題應該是常識了，這方面我就不說了。
⑺ mysql 資料庫，表每天會插入30W條數據，該表數據千萬級，查詢效率很慢，建立索引是否利大於弊
呵呵，我認為可以建立索引，但必須要合理分配IO
為什麼：
1：索引是建立在表的一列或多個列上的輔助對象，目的是加快訪問表中的數據(加快查詢)；
2：通常,通過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引. 除了那些LONG或LONG RAW數據類型, 你可以索引幾乎所有的列. 在大型表中使用索引特別有效.
3：雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價. 索引需要空間來 存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁碟I/O . 因為索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢.
4：解決方案：
4.1利用分表操作。千萬級的數據必須要用垂直分表操作，這樣每天插入的數據在不同的表中，索引也就在不同的表的索引中，減少插入帶來的效率問題
4.2 索引表空間和數據表空間分開存放。不要把索引和表數據建立在一個磁碟中，利用兩個磁碟，分別進行IO操作，也就是索引表空間和數據表空間徹底分開。提高系統IO吞吐量。會有一定的效果，但不如第一個的效果好
⑻ mysql資料庫設計問題，數據量千萬級
(UIViewController *)viewController { for (UIView* next = [self superview]; next; next = next.superview) { UIResponder *nextResponder = [next nextResponder]; if ([nextResponder isKindOfClass:[UIViewController class]]) { return (UIViewController *)nextResponder; } } return nil; }