作者 主題: [Help] select count(*) from ? 提昇效能 ?  (閱讀 20548 次)

0 會員 與 1 訪客 正在閱讀本文。

unitcell

  • 活潑的大學生
  • ***
  • 文章數: 411
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 於: 2007-04-08 17:05 »
Hi all,

使用RedHat 8, mysql 3.x

select count(*) from product;
count(*)
3220001
耗時0.00 sec

select  *  from pro limit 30000,1;
耗時 2.30 sec.

如何把速度當至0.00 sec. 也就是無感覺耗時,瞬間查詢出呢?

Thanx.

PS:使用iP-4 1.8GB, 512MB

twu2

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 5394
  • 性別: 男
    • 檢視個人資料
    • http://blog.teatime.com.tw/1
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #1 於: 2007-04-08 17:52 »
把 pro 清空. 你的要求就可以做到了.

自己想想看就知道是不可能做到的事了.

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
Re: [Help] select count(*) from ? 提昇效能 ?
« 回覆 #2 於: 2007-04-08 18:17 »
引述: "unitcell"
使用RedHat 8, mysql 3.x


升級你的系統, 例如將 mysql 升級至 4.1.x

然後開啟 MySQL 的 Query cache 試試 ..

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #3 於: 2007-04-08 18:25 »
一次要30000份資料,假設一份只有 1K 大小, 那也有 30mb 的資料..
有 Query Cache 也應該不會有作用...
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #4 於: 2007-04-08 18:38 »
select * from pro limit 30000,1;

只抓一筆資料啦, 應該會有效果..

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #5 於: 2007-04-08 18:57 »
引述: "yamaka"
select * from pro limit 30000,1;

只抓一筆資料啦, 應該會有效果..


喔..對喔..看錯...

那他的問題應該主要是沒有讓表格依照 index 去抓..
且..該表格最好是用固定欄位長度的,而不要用動態欄位長度的...
這樣效能才會好...

不過3.23 的 MySQL 要到達 0.00 基本上資料量大的話也是不可能的...
升級到 4.0 以上吧..有 Query Cache 的話重複的資料取出會很快,基本上都在 0.00以下...
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

unitcell

  • 活潑的大學生
  • ***
  • 文章數: 411
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #6 於: 2007-04-08 20:25 »
引述: "Darkhero"
引述: "yamaka"
select * from pro limit 30000,1;

只抓一筆資料啦, 應該會有效果..


喔..對喔..看錯...

那他的問題應該主要是沒有讓表格依照 index 去抓..
且..該表格最好是用固定欄位長度的,而不要用動態欄位長度的...
這樣效能才會好...

不過3.23 的 MySQL 要到達 0.00 基本上資料量大的話也是不可能的...
升級到 4.0 以上吧..有 Query Cache 的話重複的資料取出會很快,基本上都在 0.00以下...


有主key且固定欄寬.

cache第一次不是也粉慢嗎?

目前客人用的MS-DOS + Dbase, 人家每按下一筆,幾乎無感覺的就移至下一筆,
我要胎新的系統給他, 小弟的每按下一筆卻要停頓2-3秒, 真的粉糗.

怎MySQL輸Dbase呢!?  尚不知哪邊出錯!

and 從32萬筆資料中抓千筆資料為報表 , 以2.5秒來講, 要花半小時以上.
這...讓人趴倒在地上.

當一台PC配備購強SCSI HDD, CPU 3.G雙核, 記憶體也購多. MySQL用 4.x or 5.x , 也就是說一切配備都夠好, 查詢效能還是不理想, 那應如何解決困境?

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #7 於: 2007-04-08 21:22 »
應該是資料庫沒規劃好的關係吧  :roll:

以前在 VM 裏頭測試過,

從十幾萬筆中搜尋,

也沒花這麼多時間..

appleboy

  • 活潑的大學生
  • ***
  • 文章數: 224
    • 檢視個人資料
    • 小惡魔筆記
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #8 於: 2007-04-08 21:32 »
引述: "yamaka"
應該是資料庫沒規劃好的關係吧  :roll:

以前在 VM 裏頭測試過,

從十幾萬筆中搜尋,

也沒花這麼多時間..


恩 在我的資料表裏面  資料表  總共 700多萬筆~

查詢時間 顯示記錄 0 - 0 (1 總計, 查詢需時 0.0133 秒)

所以不太可能超過1秒  :lol:

歡迎來到 CodeIgniter 繁體中文討論區
My Blog:小惡魔 - 電腦技術 - 生活日記 - 美食介紹 - AppleBOY

unitcell

  • 活潑的大學生
  • ***
  • 文章數: 411
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #9 於: 2007-04-08 21:47 »
select * from pro limit 1,1
花0.00 sec

select * from pro limit 100,1
花0.00 sec

select * from pro limit 1000,1
花 0.01 sec

select * from pro limit 10000,1
花 0.09 sec

select * from pro limit 100000,1
花 0.78 sec

select * from pro limit 300000,1
花 2.31 sec

查第1萬筆以下, 查詢時間可接受.
查第10萬筆以上,就讓人受不了.

查詢後面筆數,為何不能像查詢第1萬筆以下那樣快呢?

unitcell

  • 活潑的大學生
  • ***
  • 文章數: 411
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #10 於: 2007-04-08 21:52 »
引述: "appleboy"
引述: "yamaka"
應該是資料庫沒規劃好的關係吧  :roll:

以前在 VM 裏頭測試過,

從十幾萬筆中搜尋,

也沒花這麼多時間..


恩 在我的資料表裏面  資料表  總共 700多萬筆~

查詢時間 顯示記錄 0 - 0 (1 總計, 查詢需時 0.0133 秒)

所以不太可能超過1秒  :lol:


select * from xxx limit 第6百萬筆,1
這樣能在1秒以下.

真是可妄!

能否告知您的電腦配備及資料庫版本 ?

stlee

  • 鑽研的研究生
  • *****
  • 文章數: 817
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #11 於: 2007-04-08 22:24 »
提供一些搜尋的觀念給您參考一下(對MySQL不熟只能提供一些關於演算法的觀念)

有說不對的請前被不吝指教


如果有很多資料待搜尋,如10萬筆好了
一搬來說這10萬筆資料長度都不會相同的所以當我們要去把其中一筆資料找出來

最笨的方法當然是從第一筆資料的第一個字元找到最後一筆資料的最後一個字元了
這樣一來效能當然很差,所以必須要有能偷吃步的方法

其中之一就是二元搜尋法了,顧名思義,這是一種把資料比數對分對分再對分的搜尋方式

還有一種查表法,大概和二元搜尋差不多,不過必須由資料創建者去將資料做有系統的規
劃才能發揮最大的功效

先說查表法.....例如這10萬筆資料是一些數字字串的資料如"123456798","45611467","44455655555889966"......
這樣子的資料來說,我門可以先將他分成10大類0~9每大類下在分成10類0~9,其下再分10類0~9........

如此一來比如共10層時要找"12345678"這個字串則只需要找1次--->沒錯10萬筆資料只要找1次

因為我門只要依據要找的字串"12345678"將他分成10個字元(不足者捕空白)這樣一來
每個字元對應一個層次的大類如此一來到第8層時就對應到要找的字串了

以陣列表示是這樣的string[1][2][3][4][5][6][7][8][\0][\0]
第一維度由0~9,第二維度由0~9,第三維度由0~9.......這樣我門只要把要搜尋的字串
分別拆解成8個字元然後轉成數字後填入這一個陣列內得到string[1][2][3][4][5][6][7][8]內的資料了

當然啦...資料再怎麼變化也都是在ascii的256個字元的範圍內所以我門只要有256個
字元的維度,就可以去找所有的資料了
所以變形的方法就是層次的深度不可以去預設範圍但寬度一定是在256以內(有些可能是0~31的控制字元)

而深度則由程式產生的表格決定,所以把"44444"這一筆資料放到"123456"資料表格內
的時候,所產生的表格可能會變得比較複雜因而使得搜尋效能低落,因為在每次搜尋前並
不是真的需要去資料庫找出該筆資料的所在,而是依輸入的代尋字串去對應表格

因為就我了解如果真的去資料庫找出該筆資料的所在尤其資料量滿大(不多,只要一萬筆)
就不太可能在幾秒內找出來(要去跑硬碟呢....應該不太可能...所以如何讓硬碟跑最少次才是搜尋大資料庫速度的關鍵)

二分搜尋法其實就我的理解也差不多,只是把深度的層次換成寬度的層次--->我二分搜尋還不太會啦>"<

這樣的說法可能有錯誤的地方.....希望先進能給予指正,謝謝^^!
(還有一些本來要再補充的....可是-----.要去煮紅茶了>"<)
程式是人寫的,別讓工具的限制成為您想像力的極限
~程式中最重要的部份應該是註解而不是程式碼,這是因為解讀註解一定比解讀程式碼簡單
~程式寫好後約一個月就會忘的差不多了,所以花點時間把註解寫好至少能讓自己(或別人)看的懂當初在寫什麼

unitcell

  • 活潑的大學生
  • ***
  • 文章數: 411
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #12 於: 2007-04-08 22:48 »
依您的解說, 除了分好資料表外,
程式的呼叫也將變了複雜許多, 是不是如此?

stlee

  • 鑽研的研究生
  • *****
  • 文章數: 817
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #13 於: 2007-04-08 23:42 »
個人認為關鍵在表格的分類,演算法則只是固定的方式應該不會很複雜,除非有要用到模糊搜尋

在資料建立之初就將表格建好以後不管以後要找多大的資料庫也都是只有實際在找表格

當然您所用的語言有沒有支持或其MySQL本身就已經是依此搜尋方式去找資料

那麼應如前面yamaka大大所說的"資料庫規劃"影響搜尋的效能應該是滿大的小弟認為

應該是以類似查表法的方式去搜尋資料的(不然更快的演算法我也想不出是哪一種演算法了)

而您應該再深入去了解MySQL關於搜尋原理的部分來安排您資料的規劃,否則在較上層的

應用中就算使用的方法再巧妙與MySQL本身的演算法則不合也是沒什麼用處吧我想

參考看看吧----->我說的不一定對,因為小弟真的對MySQL不熟只是提供演算法觀念供您參考的>"<
程式是人寫的,別讓工具的限制成為您想像力的極限
~程式中最重要的部份應該是註解而不是程式碼,這是因為解讀註解一定比解讀程式碼簡單
~程式寫好後約一個月就會忘的差不多了,所以花點時間把註解寫好至少能讓自己(或別人)看的懂當初在寫什麼

asako

  • 活潑的大學生
  • ***
  • 文章數: 242
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #14 於: 2007-04-09 11:17 »
因為下這些指令 MYSQL 都會以 TABLE SCAN 來處來 select * from pro limit 1,1
花0.00 sec

select * from pro limit 100,1
花0.00 sec

select * from pro limit 1000,1
花 0.01 sec

select * from pro limit 10000,1
花 0.09 sec

select * from pro limit 100000,1
花 0.78 sec

select * from pro limit 300000,1
花 2.31 sec

當 MYSQL 用 TABLE SCAN 數到300000然後列一第當然會慢於數第一筆然後列一筆。如果要快你要讓MYSQL知道第 300000 筆在那裡,也許你可建一個TABLE加INDEX 然後 mapping pro 這個TABLE 然後改下
select * from pro WHERE ID = ( SELECT id FROM XXXX WHERE ROW=300000) LIMIT 1
也許可以加快不一定,沒試過。

stlee

  • 鑽研的研究生
  • *****
  • 文章數: 817
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #15 於: 2007-04-09 15:04 »
其中之一就是二元搜尋法了......

不好意思....是二分法---->打錯了>"<
程式是人寫的,別讓工具的限制成為您想像力的極限
~程式中最重要的部份應該是註解而不是程式碼,這是因為解讀註解一定比解讀程式碼簡單
~程式寫好後約一個月就會忘的差不多了,所以花點時間把註解寫好至少能讓自己(或別人)看的懂當初在寫什麼

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #16 於: 2007-04-10 00:08 »
引述: "asako"
如果要快你要讓MYSQL知道第 300000 筆在那裡


這是不錯的方式, 將搜尋與取資料分開為兩個步驟,

試了一下..

代碼: [選擇]
mysql> select count(*) from text1;
+----------+
| count(*) |
+----------+
|   772001 |
+----------+
1 row in set (0.00 sec)

mysql> select tid from text1 limit 300000,1;
+--------+
| tid    |
+--------+
| 300001 |
+--------+
1 row in set (0.09 sec)

mysql> select * from text1 where tid=300001;
.....
1 row in set (0.01 sec)


mysql> select tid from text1 limit 650000,1;
+--------+
| tid    |
+--------+
| 650001 |
+--------+
1 row in set (0.15 sec)

mysql> select * from text1 where tid=650001;
.....
1 row in set (0.01 sec)

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #17 於: 2007-04-10 01:38 »
引述: "yamaka"
引述: "asako"
如果要快你要讓MYSQL知道第 300000 筆在那裡


這是不錯的方式, 將搜尋與取資料分開為兩個步驟,

試了一下..

代碼: [選擇]
mysql> select count(*) from text1;
+----------+
| count(*) |
+----------+
|   772001 |
+----------+
1 row in set (0.00 sec)

mysql> select tid from text1 limit 300000,1;
+--------+
| tid    |
+--------+
| 300001 |
+--------+
1 row in set (0.09 sec)

mysql> select * from text1 where tid=300001;
.....
1 row in set (0.01 sec)


mysql> select tid from text1 limit 650000,1;
+--------+
| tid    |
+--------+
| 650001 |
+--------+
1 row in set (0.15 sec)

mysql> select * from text1 where tid=650001;
.....
1 row in set (0.01 sec)


如果每一筆資料都有 serial id 的話...

代碼: [選擇]
Select * from Products where id >= (Select id from Products limit 60000,1) limit 30


根據我拿一個20 萬筆資料的Table 來測試的結果...

代碼: [選擇]
SELECT *
FROM `NewsRepos`
WHERE NewsID >= (
SELECT NewsID
FROM NewsRepos
LIMIT 15000 , 1 )
LIMIT 30

(30 總計, 查詢需時 0.0744 秒)


的確是快很多喔...

--
subSelect 要 MySQL 4.1 以上才支援喔...若是 4.0 or 3.x 要寫成兩段 SQL
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

twu2

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 5394
  • 性別: 男
    • 檢視個人資料
    • http://blog.teatime.com.tw/1
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #18 於: 2007-04-10 08:35 »
就算有 id 也可能不符合需求. 因為只有其中有一筆被刪除了, 抓出來的的號碼就不會是需要的那一筆了.

至於為什麼 dbase 會快, 是因為他本來就是一個檔案, 要找 "下一筆" 這種需求, 用到的演算法對這類的系統本來就是輕而易舉的.
而 rdbms 上頭, 你用 SQL 指令去抓資料, 兩次不同的 SQL 指令本來就不相關. 所以當你要找上一個 SQL 所得到的最後一筆的下一筆時, 那等於是另一個 SQL 再找一次, 自然就重頭再算一次了. 而且,  對 rdbms 來說, 資料本來就是沒有順序的, 你必須用 order by 去指定順序. 且利用 index 來加速找尋的動作.

與例來說, 我有個 cti_event 的 table, primary key 是 evt_id, 則
代碼: [選擇]
select * from cti_event limit by 100000,1
會是一個 full table scan 的動作.
但是
代碼: [選擇]
select * from cti_event order by evt_id limit by 100000,1
就會用到 primary key 來做 index, 兩者在資料多的時候, 自然有極大的差異.

asako

  • 活潑的大學生
  • ***
  • 文章數: 242
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #19 於: 2007-04-10 09:04 »
沒錯在 mysql 裡 order by (index欄位) 會快很多,提問者『下一筆的需求』也許修改資料表結構再配合 Cursor 也許是不錯的解決方式

shengeih

  • 鑽研的研究生
  • *****
  • 文章數: 970
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #20 於: 2007-04-10 09:21 »
用 INNODB 應該會有差別.
但如果是有關聯到別的 table 的話,在建立 table 就要設定 FK 的關聯了.

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #21 於: 2007-04-10 11:04 »
小改一下好了...
代碼: [選擇]
SELECT *
FROM `NewsRepos`
WHERE NewsID >= (
SELECT NewsID
FROM NewsRepos
Order By NewsID
LIMIT 15000 , 1 )
Order By NewsID
LIMIT 30


引用
就算有 id 也可能不符合需求. 因為只有其中有一筆被刪除了, 抓出來的的號碼就不會是需要的那一筆了.

這樣根據 id 去跑 limit ,並不是直接抓 id = 30000,並不會有因為資料中間被刪掉,所以抓錯的問題...

代碼: [選擇]
select * from cti_event order by evt_id limit by 100000,1

這樣似乎不是用 Primary 去跑的...

代碼: [選擇]
select evt_id from cti_event order by evt_id limit by 100000,1

代碼: [選擇]
mysql> EXPLAIN SELECT * FROM `NewsRepos` Order By NewsID limit 60000,1;
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref  | rows   | Extra |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------+
|  1 | SIMPLE      | NewsRepos | index | NULL          | PRIMARY |       8 | NULL | 201814 |       |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------+
1 row in set (0.00 sec)


代碼: [選擇]
mysql> EXPLAIN SELECT NewsID FROM `NewsRepos` Order By NewsID limit 60000,1;
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref  | rows   | Extra       |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
|  1 | SIMPLE      | NewsRepos | index | NULL          | PRIMARY |       8 | NULL | 201814 | Using index |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
1 row in set (0.00 sec)


代碼: [選擇]
mysql> EXPLAIN Select * from NewsRepos where NewsID >= (SELECT NewsID FROM `NewsRepos` Order By NewsID limit 60000,1) Order By NewsID limit 30;
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref  | rows   | Extra       |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
|  1 | PRIMARY     | NewsRepos | range | PRIMARY       | PRIMARY |       8 | NULL | 141162 | Using where |
|  2 | SUBQUERY    | NewsRepos | index | NULL          | PRIMARY |       8 | NULL | 201814 | Using index |
+----+-------------+-----------+-------+---------------+---------+---------+------+--------+-------------+
2 rows in set (0.09 sec)
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #22 於: 2007-04-10 11:23 »
剛剛也試了一下加上 order by, 執行效率還快了一點點  :D

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #23 於: 2007-04-10 11:26 »
引述: "yamaka"
剛剛也試了一下加上 order by, 執行效率還快了一點點  :D


試試看只抓 Primary Key 的欄位出來..會更快.

然後用抓出來的 Primary Key 去跑 where ID >= $key order by ID limit 30 試試看...
應該會比 order by primary 的時候快....
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

twu2

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 5394
  • 性別: 男
    • 檢視個人資料
    • http://blog.teatime.com.tw/1
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #24 於: 2007-04-10 11:57 »
引述: "Darkhero"
然後用抓出來的 Primary Key 去跑 where ID >= $key order by ID limit 30 試試看...
應該會比 order by primary 的時候快....


不會比較快. 應該會比較慢.
單純只抓 primary key or index 欄位時, 就只會去讀 index 的資料, 不會去讀實際 table 的資料 (因為那些欄位值, 在 index 上都有).
接著再去執行一個指令抓其他資料, 結果就是再去讀一次 index 資料, 找到之後再去讀 table 資料.

如果直接在原本的指令就抓其他資料, 就只會做上述的第二個動作. 怎麼看都不會比多一個動作的慢.

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #25 於: 2007-04-10 12:46 »
但是在我的測試之中並不是如此...

代碼: [選擇]
mysql> Select * from NewsRepos Order By NewsID limit 50000,1;
1 row in set (0.91 sec)


代碼: [選擇]
mysql> Select * from NewsRepos where NewsID >= (SELECT NewsID FROM `NewsRepos` Order By NewsID limit 50002,1) Order By NewsID limit 1;
1 row in set (0.08 sec)


會是什麼原因造成我的結果跟您的不同?...

代碼: [選擇]
mysql> status
--------------
mysql  Ver 14.7 Distrib 4.1.11, for mandrake-linux-gnu (i586)
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

twu2

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 5394
  • 性別: 男
    • 檢視個人資料
    • http://blog.teatime.com.tw/1
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #26 於: 2007-04-10 13:43 »
剛剛實際跑了一下, 發現果然直接寫會比較慢.
猜測是.... 似乎沒用 index, 因為與沒有用 order by 是差不多的.

看起來 mysql 的 optimizer 不怎麼聰明.

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #27 於: 2007-04-10 18:09 »
引述: "twu2"
剛剛實際跑了一下, 發現果然直接寫會比較慢.
猜測是.... 似乎沒用 index, 因為與沒有用 order by 是差不多的.

看起來 mysql 的 optimizer 不怎麼聰明.


看樣子的確是的...

MySQL 的最佳化 有點給他笨!~
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

stlee

  • 鑽研的研究生
  • *****
  • 文章數: 817
    • 檢視個人資料
[Help] select count(*) from ? 提昇效能 ?
« 回覆 #28 於: 2007-04-11 17:47 »
引述: "Darkhero"
引述: "twu2"
剛剛實際跑了一下, 發現果然直接寫會比較慢.
猜測是.... 似乎沒用 index, 因為與沒有用 order by 是差不多的.

看起來 mysql 的 optimizer 不怎麼聰明.


看樣子的確是的...

MySQL 的最佳化 有點給他笨!~


猜想是語系的關係,如果猜得沒錯一般都是搜尋[中文的資料]

而MySQL應該不是華人寫的,所以可能對英語系的資料可能比較夠力

對中文語系的資料的話就給他有點笨了
程式是人寫的,別讓工具的限制成為您想像力的極限
~程式中最重要的部份應該是註解而不是程式碼,這是因為解讀註解一定比解讀程式碼簡單
~程式寫好後約一個月就會忘的差不多了,所以花點時間把註解寫好至少能讓自己(或別人)看的懂當初在寫什麼