自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

MySQL數(shù)據(jù)庫下limit與join的優(yōu)化方案

數(shù)據(jù)庫 MySQL
我們今天主要和大家討論的是MySQL數(shù)據(jù)庫下limit與join的實(shí)際優(yōu)化方案,如果你對其具體的實(shí)際操作感興趣的話,你就可以點(diǎn)擊以下的文章了。

以下的文章主要描述的是MySQL數(shù)據(jù)庫下limit與join的實(shí)際優(yōu)化方案,我們大家都知道其在實(shí)際中的應(yīng)用比例還是占為多數(shù)的,如果你對這一技術(shù),心存好奇的話,以下的文章將會揭開它的神秘面紗。

PHP中分頁肯定會使用到MySQL的limit,大部分對類似”select * from title where uid =** order by id desc limit m,n”很熟悉,也不是全部都能看出里面有什么不對,可是當(dāng)是在大數(shù)據(jù)量下操作呢,比如百萬類似”select * from title where uid =177 order by id desc limit 1234567,20″就會發(fā)現(xiàn)sql執(zhí)行的時間明顯變得很長,為什么呢?

先從MySQL數(shù)據(jù)庫的limit原理說起,使用limit m,n是時候,MySQL先掃描(m+n)條記錄,然后從m行開始取n行.比如上面的例子就是先掃描1234587條數(shù)據(jù),這樣的話sql能快嗎?這就要 求我們盡可能的減少m的值,甚至沒有m直接limit n這樣是sql.

看個例子:

 

  1. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 limit 888888,10;  
  2. +———-+—————————–+———————+——+———————-+  
  3. | id | substr(mobile from 1 for 7) | time | cpid | linkid |  
  4. +———-+—————————–+———————+——+———————-+  
  5. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |  
  6. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |  
  7. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |  
  8. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |  
  9. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |  
  10. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |  
  11. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |  
  12. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |  
  13. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |  
  14. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |  
  15. +———-+—————————–+———————+——+———————-+  
  16. 10 rows in set (3.84 sec)  
  17.  
  18. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 and id>=11535090 limit 10;  
  19. +———-+—————————–+———————+——+———————-+  
  20. | id | substr(mobile from 1 for 7) | time | cpid | linkid |  
  21. +———-+—————————–+———————+——+———————-+  
  22. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |  
  23. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |  
  24. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |  
  25. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |  
  26. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |  
  27. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |  
  28. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |  
  29. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |  
  30. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |  
  31. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |  
  32. +———-+—————————–+———————+——+———————-+  
  33. 10 rows in set (0.00 sec)  
  34.  
  35. mysql> select id,substr(mobile from 1 for 7),time,cpid,linkid from cp_mo100227 where cpid=769 and time>=’2010-02-24 21:07:48′ limit 10;  
  36. +———-+—————————–+———————+——+———————-+  
  37. | id | substr(mobile from 1 for 7) | time | cpid | linkid |  
  38. +———-+—————————–+———————+——+———————-+  
  39. | 11535090 | 1353554 | 2010-02-24 21:07:48 | 769 | 21064905903309587933 |  
  40. | 11535091 | 1353750 | 2010-02-24 21:07:48 | 769 | 21064912943389480033 |  
  41. | 11535093 | 1353394 | 2010-02-24 21:07:48 | 769 | 21064912945389480075 |  
  42. | 11535098 | 1343073 | 2010-02-24 21:07:50 | 769 | 21064905865309587977 |  
  43. | 11535100 | 1369270 | 2010-02-24 21:07:51 | 769 | 21064926770369210194 |  
  44. | 11535103 | 1355683 | 2010-02-24 21:07:51 | 769 | 21064912944389480113 |  
  45. | 11535104 | 1368959 | 2010-02-24 21:07:51 | 769 | 21064902508384448468 |  
  46. | 11535105 | 1365243 | 2010-02-24 21:07:51 | 769 | 21064905907309403124 |  
  47. | 11535106 | 1362145 | 2010-02-24 21:07:52 | 769 | 21065002511384448497 |  
  48. | 11535107 | 1369228 | 2010-02-24 21:07:52 | 769 | 21064902514384448437 |  
  49. +———-+—————————–+———————+——+———————-+  
  50. 10 rows in set (0.01 sec) 

 

例中數(shù)據(jù)表id是主鍵,time也建了索引,表中總數(shù)據(jù)約為240w行,其中cpid為769的數(shù)據(jù)量大約為90w條.這里面的id和時間可能會是不連續(xù)的.故不能直接得獲取id>m這樣操作

所以可以顯示 “1,2,3,4,5,末頁” 或是 “首頁,<<100,101,102,103 >>末頁”這樣,這樣可以極大的減少m值!

MySQL里面的join順便說一句就是,通常有點(diǎn)講究的是用小表去驅(qū)動大表,而由于MySQL join實(shí)現(xiàn)的原理就是做循環(huán)比如left join就是對左邊的數(shù)據(jù)進(jìn)行循環(huán)去驅(qū)動右邊的表,比如左邊是可能會有m條記錄匹配,右邊有n條記錄那么就是做m次循環(huán),每次掃描n行數(shù)據(jù),總掃面行數(shù)是 m*n行數(shù)據(jù).左邊返回的結(jié)果集的大小就決定了循環(huán)的次數(shù),故單純的用小表去驅(qū)動大表不一定的正確的。

小表的結(jié)果集可能也大于大表的結(jié)果集,所以寫 join的時候盡可能的先估計(jì)兩張表的可能結(jié)果集,用小結(jié)果集去驅(qū)動大結(jié)果集.值得注意的是在使用left/right join的時候,從表的條件應(yīng)寫在on之后,主表應(yīng)寫在where之后.否則MySQL數(shù)據(jù)庫會當(dāng)作普通的連表查詢!

【編輯推薦】

  1. 從MySQL數(shù)據(jù)庫表中來檢索數(shù)據(jù)并不難
  2. MySQL數(shù)據(jù)庫訪問妙招在Linux之下
  3. MySQL 修改密碼的6個好用方案
  4. 配置MySQL與卸載MySQL實(shí)操
  5. 備份MySQL數(shù)據(jù)庫腳本的實(shí)際應(yīng)用
責(zé)任編輯:佚名 來源: 互聯(lián)網(wǎng)
相關(guān)推薦

2011-07-06 10:49:50

MySQL優(yōu)化

2011-07-06 14:12:20

MySQLPercona

2011-03-09 08:53:02

MySQL優(yōu)化集群

2010-06-04 11:28:05

MySQL數(shù)據(jù)庫

2011-03-08 08:49:55

MySQL優(yōu)化單機(jī)

2010-02-01 10:10:41

Oracle數(shù)據(jù)庫優(yōu)化

2010-05-21 13:48:36

MySQL數(shù)據(jù)庫

2010-05-31 16:17:56

MySQL數(shù)據(jù)庫性能

2010-06-02 13:58:30

MySQL數(shù)據(jù)庫性能

2010-05-13 10:47:44

MySQL數(shù)據(jù)庫查詢

2010-06-10 10:15:50

MySQL數(shù)據(jù)庫查詢

2011-03-03 17:56:52

MySQL數(shù)據(jù)庫優(yōu)化

2010-05-20 18:12:37

MySQL數(shù)據(jù)庫查詢

2018-07-30 15:00:05

數(shù)據(jù)庫MySQLJOIN

2010-06-11 12:32:57

MySQL數(shù)據(jù)庫查詢

2010-06-17 09:15:02

MySQL數(shù)據(jù)庫查詢

2010-05-28 09:15:50

配置MySQL

2014-07-18 09:33:53

數(shù)據(jù)庫數(shù)據(jù)庫優(yōu)化

2013-01-04 10:00:12

MySQL數(shù)據(jù)庫數(shù)據(jù)庫查詢優(yōu)化

2010-06-01 14:42:55

連接MySQL數(shù)據(jù)庫
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號