看板 [ Database ]
討論串[SQL ] select 似乎不適合用在多筆數的查詢
共 5 篇文章
內容預覽： 開啟 | 關閉 | 只限未讀
首頁
上一頁
1
下一頁
尾頁
#5
Re: [SQL ] select 似乎不適合用在多筆數的查詢
推噓1(1推 0噓 0→)留言1則，0人參與, 最新作者CHSI (金屬製品)時間16年前 (2009/04/29 16:52), 編輯資訊
0
0
0
內容預覽:
除了網友提的一些問題與方法之外，我想補充提問一個問題：. 像這樣超大量的查詢動作會「經常」做嗎？. 如果不會，而這樣的查詢動作又無可避免的話(雖然我想不到可能的原因)，那.... 就讓它跑吧，只是可能要挑一下適當的時間就是了。. 如果這樣的查詢動作非得要經常的執行，而該做的最佳化也做了，那麼唯一的方
#4
Re: [SQL ] select 似乎不適合用在多筆數的查詢
推噓0(0推 0噓 0→)留言0則，0人參與, 最新作者regionbbs (小朱)時間17年前 (2009/04/27 12:14), 編輯資訊
0
0
0
內容預覽:
之前本來想要用推文回應，但推一次要等 2xx 秒.... 會影響 select 的因素很多，除了 WHERE, JOIN, Constraint, 這些可以控制. 的軟限制以外，還有像是索引的設計，硬體 (CPU, RAM, Disk I/O 與網路) 等. 硬限制，這些都有可能會影響到 selec
(還有53個字)
#3
Re: [SQL ] select 似乎不適合用在多筆數的查詢
推噓0(0推 0噓 0→)留言0則，0人參與, 最新作者bobju (寶貝豬)時間17年前 (2009/04/27 11:29), 編輯資訊
0
0
0
內容預覽:
mysql:. select * from xxx where ... limit 0,10;. 就算有數千萬筆, 也只會撈出從頭算起的10筆資料.. 其它資料庫也有類似的機制.. 而且, 真正會影響資料庫運作時間的, 是join, where, order by,. 這些constraint..
#2
Re: [SQL ] select 似乎不適合用在多筆數的查詢
推噓0(0推 0噓 0→)留言0則，0人參與, 最新作者adrianshum (Alien)時間17年前 (2009/04/27 11:10), 編輯資訊
0
0
0
內容預覽:
要是你的確是需要那麼多 record,. 你能期望有方法可以只拿很少資料但又能. 給你那幾千萬筆的結果? 不可能吧.. 我倒覺得你要自己問一句:. 為什麼我需要幾千萬筆 record?. 幾千萬筆已經是超過人能處理的極限了.. 一般要這麼多資料, 都是用來做歷史數據. 的分析, 而不是真的需要那數千
#1
[SQL ] select 似乎不適合用在多筆數的查詢
推噓7(7推 0噓 1→)留言8則，0人參與, 最新作者abschihok (大帥哥)時間17年前 (2009/04/26 23:13), 編輯資訊
0
0
0
內容預覽:
select * from xxx where ...... 如果select出來的筆數有數千萬筆，. 那光一開始的select時間，不就要等上一段很長的時間了，. 甚至整個cpu資源都被吃掉了. select 似乎不適合用在大筆數的查詢，. 那請問有什麼好辦法可以適用在多筆數的查詢嗎？. --.
首頁
上一頁
1
下一頁
尾頁