㈠ sqlserver批量查詢指定A欄位的幾萬條數據(沒有規則,有具體的數據信息)並且給這些查出的行B欄位批量插入指
.......每個條件都是不是樣的。要是我就：
在exel中批量的把語句連起來。再一次性丟進SQL中去UPDATE
UPDATE XXX SET B='23534543' WHERE A=' XXXXX'
UPDATE XXX SET B='23534543' WHERE A=' XXXXX'
UPDATE XXX SET B='23534543' WHERE A=' XXXXX'
..........
最多讓SQL多運行一會。估計十分鍾完成。簡單方便，高手新手都適用。
其它方法，如：加個表進去執行一條語句也行，不過執行的時間區別不太大。
不常做這個事的話隨你怎麼弄都不復雜[除開一條一條的手寫啊=.=!]
如果常做這個事，SQL不太會的，可以把 上面提及的EXCEL連SQL語句的做成個模板，每次要用把條件數據丟進去，再把生成的名句拿出來執行就完了。
㈡ 求優化sqlserver語句，使它查詢效率提高。（要求：分組查詢每組最新的一條數據，數據量非常大，幾十萬）
關於題主的SQL語句提高效率的問題，請留意一下幾點
1) 輸出的欄位列表裡只有來自表「dbo.tunnel_online_monitoring 」里的欄位信息，沒有任何來欄位取自表「dbo.Threshold_ElectronicPool」，而且語句也沒為這兩張表指定連接條件，因此將表「dbo.Threshold_ElectronicPool」引入語句中就沒有任何必要，加入該表只會大大增加系統開銷，而無得益，應予以剔除；
2）row_number()函數的系統開銷是比較大的，能不用盡量別用它。
如果dbo.tunnel_online_monitoring.Id是唯一的,可以不使用row_number()函數，建議語句修改如下：
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(a.id)fromdbo.tunnel_online_monitoringa,
(selecttunnel_name,max(CreationDate)asCreationDatefrom
dbo.tunnel_online_monitoringgroupbytunnel_name)b
wherea.tunnel_name=b.tunnel_nameanda.CreationDate
=b.CreationDategroupbyb.tunnel_name);
如果dbo.tunnel_online_monitoring.Id是自增ID，那麼可以根據ID的大小來判定那條記錄是最新的，這樣就不需要比對時間欄位的先後了，語句可簡化如下：
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(id)fromdbo.tunnel_online_monitoring
groupbytunnel_name);
如果dbo.tunnel_online_monitoring.Id不是唯一的，那就還是得利用回row_number()函數了。
㈢ 請問sqlserver如果要能處理千萬級的數據，機器硬體要求是什麼
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 的看法。
㈣ sqlserver資料庫能不能支持千萬級別數據
可以的，我每天都在用
SQLSERVER
查大批量數據，其中千萬的也有，只不過相比ORACLE在性能上會有些低。
㈤ SQLSERVER 即將存儲大量的數據，怎麼設計表好點
1、升級硬體，使用高性能的存儲設備
2、這數據量級，SQL的資料庫使用分區表是個非常好的選擇。若是分區表+多台存儲服務設備，效果肯定杠杠的
3、主要矛盾是集中在IO吞吐上，所以解決了IO吞吐速度，就相當於解決了一半問題
4、在設計表的時候，每一列都要謹慎設置列長度和列類型，既要滿足存儲內容的需要，又要盡可能的短一些。
只能幫到這個地步了
㈥ sqlserver資料庫操作近千萬數據,會對伺服器比如對內存,線程,句柄數,CPU等造成哪些影響
當然是操作數據越多對伺服器各種的影響越大。這當然看是什麼操作（查詢、編輯等）
㈦ 數據量過大時如何使用SQL Server快速讀取
頂~ 流香羽 。
但是10000W的數據量，欄位數量不多的話，索引還是起一定效果的，如果你的表很復雜多欄位PK的話，SQLserver真的提高不了多少效果的，建議還是用Oracle，DB2這樣的大型企業級資料庫，
目前的SqlServer2008的定點吞吐數據量也不過是千萬級的。
㈧ 如何做SqlServer 數據查詢優化！
一、建立索引
二、建立存儲過程
三、只查詢您所需要的數據，不要把所有數據都查詢出來，防止數據冗餘。
四、對於大量及海量數據一般還要建立分區
㈨ mysql 如何更好的給一個千萬級數據量的表增
例子：
數據表 collect ( id, title ,info ,vtype) 就這4個欄位，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往裡面填充數據，填充10萬篇新聞。
最後collect 為 10萬條記錄，資料庫表佔用硬碟1.6G。OK ,看下面這條sql語句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 從9萬條開始分頁，結果？
8-9秒完成，my god 哪出問題了？？？？其實要優化這條數據，網上找得到答案。看下面一條語句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。為什麼？因為用了id主鍵做索引當然快。網上的改法是：
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;
這就是用了id做索引的結果。可是問題復雜那麼一點點，就完了。看下面的語句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了這里我相信很多人會和我一樣，有崩潰感覺！vtype 做了索引了啊？怎麼會慢呢？vtype做了索引是不錯，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，從9萬開始，那就是0.05*90=4.5秒的速度了。和測試結果8-9秒到了一個數量級。從這里開始有人提出了分表的思路，這個和discuz 論壇是一樣的思路。思路如下：
建一個索引表： t (id,title,vtype) 並設置成定長，然後做分頁，分頁出結果再到 collect 裡面去找info 。 是否可行呢？實驗下就知道了。
10萬條記錄到 t(id,title,vtype) 里，數據表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。為什麼會這樣呢？我猜想是因為collect 數據太多，所以分頁要跑很長的路。limit 完全和數據表的大小有關的。其實這樣做還是全表掃描，只是因為數據量小，只有10萬才快。OK，來個瘋狂的實驗，加到100萬條，測試性能。
加了10倍的數據，馬上t表就到了200多M，而且是定長。還是剛才的查詢語句，時間是0.1-0.2秒完成！分表性能沒問題？錯！因為我們的limit還是9萬，所以快。給個大的，90萬開始
select id from t where vtype=1 order by id limit 900000,10; 看看結果，時間是1-2秒！
why 分表了時間還是這么長，非常之郁悶！有人說定長會提高limit的性能，開始我也以為，因為一條記錄的長度是固定的，mysql 應該可以算出90萬的位置才對啊？ 可是我們高估了mysql 的智能，他不是商務資料庫，事實證明定長和非定長對limit影響不大？怪不得有人說 discuz到了100萬條記錄就會很慢，我相信這是真的，這個和資料庫設計有關！
難道MySQL 無法突破100萬的限制嗎？？？到了100萬的分頁就真的到了極限？？？
答案是： NO !!!! 為什麼突破不了100萬是因為不會設計mysql造成的。下面介紹非分表法，來個瘋狂的測試！一張表搞定100萬記錄，並且10G 資料庫，如何快速分頁！
好了，我們的測試又回到 collect表，開始測試結論是： 30萬數據，用分表法可行，超過30萬他的速度會慢道你無法忍受！當然如果用分表+我這種方法，那是絕對完美的。但是用了我這種方法後，不用分表也可以完美解決！
答案就是：復合索引！有一次設計mysql索引的時候，無意中發現索引名字可以任取，可以選擇幾個欄位進來，這有什麼用呢？開始的select id from collect order by id limit 90000,10; 這么快就是因為走了索引，可是如果加了where 就不走索引了。抱著試試看的想法加了 search(vtype,id) 這樣的索引。然後測試
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再測試: select id ,title from collect where vtype=1 limit 90000,10; 非常遺憾，8-9秒，沒走search索引！
再測試：search(id,vtype)，還是select id 這個語句，也非常遺憾，0.5秒。
綜上：如果對於有where 條件，又想走索引用limit的，必須設計一個索引，將where 放第一位，limit用到的主鍵放第2位，而且只能select 主鍵！
完美解決了分頁問題了。可以快速返回id就有希望優化limit ， 按這樣的邏輯，百萬級的limit 應該在0.0x秒就可以分完。看來mysql 語句的優化和索引時非常重要的！
好了，回到原題，如何將上面的研究成功快速應用於開發呢？如果用復合查詢，我的輕量級框架就沒的用了。分頁字元串還得自己寫，那多麻煩？這里再看一個例子，思路就出來了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然對於in語句同樣有效！看來網上說in無法用索引是錯誤的！
有了這個結論，就可以很簡單的應用於輕量級框架了：
代碼如下：
$db=dblink();
$db->pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db->execute($sql);
$strpage=$db->strpage(); //將分頁字元串保存在臨時變數，方便輸出
while($rs=$db->fetch_array()){
$strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //構造出id字元串
$db->pagesize=0; //很關鍵，在不注銷類的情況下，將分頁清空，這樣只需要用一次資料庫連接，不需要再開；
$db->execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
< php while($rs=$db->fetch_array()): >
<tr>
<td$amp;>amp;$amp;nbsp;< php echo $rs['id']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['url']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['sTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['gTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['vtype']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;<a act=show&id=< php echo $rs['id']; $amp;>quot;$ target="_blank"$amp;>amp;$lt; php echo $rs['title']; $amp;>amp;$lt;/a$amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['tag']; $amp;>amp;$lt;/td>
</tr>
< php endwhile; >
</table>
< php
echo $strpage;
通過簡單的變換，其實思路很簡單：1）通過優化索引，找出id，並拼成 "123,90000,12000" 這樣的字元串。2）第2次查詢找出結果。
小小的索引+一點點的改動就使mysql 可以支持百萬甚至千萬級的高效分頁！
通過這里的例子，我反思了一點：對於大型系統，PHP千萬不能用框架，尤其是那種連sql語句都看不到的框架！因為開始對於我的輕量級框架都差點崩潰！只適合小型應用的快速開發，對於ERP,OA，大型網站，數據層包括邏輯層的東西都不能用框架。如果程序員失去了對sql語句的把控，那項目的風險將會成幾何級數增加！尤其是用mysql 的時候，mysql 一定需要專業的dba 才可以發揮他的最佳性能。一個索引所造成的性能差別可能是上千倍！
PS: 經過實際測試，到了100萬的數據，160萬數據，15G表，190M索引，就算走索引，limit都得0.49秒。所以分頁最好別讓別人看到10萬條以後的數據，要不然會很慢！就算用索引。經過這樣的優化，mysql到了百萬級分頁是個極限！但有這樣的成績已經很不錯，如果你是用sqlserver肯定卡死！而 160萬的數據用 id in (str) 很快，基本還是0秒。如果這樣，千萬級的數據，mysql應該也很容易應付。
㈩ sqlserver 如何解決上億數據的查詢與插入
查詢及插入操作上億的數據和查詢及插入一條數據是一樣的啊~
你的問題應該是數據量大還想查詢的快，這就像想讓馬兒跑，還不想讓它吃草，那不可能~
當然也有辦法優化一下，但再優化時間也不能實現秒出結果。
所以，如果要速度，請分表。
如果要空間，那就多點耐心~