MySQL百萬級數(shù)據(jù)量分頁查詢方法及其優(yōu)化建議
這種方式的做法是先定位偏移位置的id，然后再往后查詢，適用于id遞增的情況。
應(yīng)盡量避免在 where 子句中使用！=或操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。 對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。
一個不正確的優(yōu)化是采用 SQL_CALC_FOUND_ROWS，SQL_CALC_FOUND_ROWS 可以在能夠在分頁查詢時事先準(zhǔn)備好符合條件的記錄數(shù)，隨后只要執(zhí)行一句 select FOUND_ROWS()； 就能獲得總記錄數(shù)。
首先，數(shù)據(jù)量大的時候，應(yīng)盡量避免全表掃描，應(yīng)考慮在 where 及 order by 涉及的列上建立索引，建索引可以大大加快數(shù)據(jù)的檢索速度。
另外，當(dāng)數(shù)據(jù)庫表更新大量數(shù)據(jù)后，刪除并重建索引可以提高查詢速度。2．避免或簡化排序 應(yīng)當(dāng)簡化或避免對大型表進(jìn)行重復(fù)的排序。當(dāng)能夠利用索引自動以適當(dāng)?shù)拇涡虍a(chǎn)生輸出時，優(yōu)化器就避免了排序的步驟。
mysql設(shè)置主鍵有什么用
主鍵主要是用于其他表的外鍵關(guān)聯(lián)，以及本記錄的修改與刪除。主鍵的作用主鍵是能確定一條記錄的唯一標(biāo)識，主鍵字段必須唯一，必須非空，一個表中只能有一個主鍵，主鍵可以包含一個或多個字段。
在Mysql表設(shè)計中，通常會使用一個與業(yè)務(wù)無關(guān)的自增列做為主鍵。這是因為Mysql默認(rèn)使用B-Tree索引，你可以簡單理解為“排好序的快速查找結(jié)構(gòu)”。
主要的作用主要確定該數(shù)據(jù)的唯一性。比如說ID=1，NAME=張三。我們要在數(shù)據(jù)庫中，找到這條數(shù)據(jù)可以使用select * from 表 where id=1 這樣就可以把張三查找出來了。而這個張三，也可以出現(xiàn)同名，所有用ID來做主鍵。
primary key主鍵，是一個標(biāo)志，標(biāo)志著這一行的內(nèi)容不能重復(fù)（唯一），而且必須是非空的（也就是不能出現(xiàn)null或空白的狀態(tài)）。
MySQL之所以要使用自增主鍵，是因為InnoDB表與它使用時十分方便，效率明顯提高。推薦課程：MySQL教程。
mysql創(chuàng)建數(shù)據(jù)庫時怎么將主鍵設(shè)置為UUID,建表語句怎么寫
1、update test set id = UUID()；MYSQL無法在默認(rèn)值中設(shè)置UUID函數(shù)，實際上其它函數(shù)除TIMESTAMP之外都不可以。 MYSQL的默認(rèn)值目前只能是常數(shù)或者CURRENTTIMESTAMP。
2、如果你連接的是MySQL數(shù)據(jù)庫的話，還可以進(jìn)行建表。點擊表按鈕，在下面表的空白處右擊選擇新建表就可以彈出這個界面。這時候可以看出讓你輸入名、類型、長度、小數(shù)點（看情況填寫小數(shù)點）、是否允許Null值，相當(dāng)全。
3、CREATE TABLE語句，用于在數(shù)據(jù)庫中創(chuàng)建新表。
4、打開navicat工具，連接上mysql服務(wù)器，選擇完數(shù)據(jù)庫之后，選擇一個表右擊選擇設(shè)計表（這里為了演示測試，隨便選擇一個表即可）。
5、為了方便大家理解，使用一個例子來幫助大家理解。意思大概就是通過引用表二中的字段完成對表一字段的約束。方法：這里一共兩個表，先創(chuàng)建外鍵表，因為先有外鍵，主鍵才能引用。首先創(chuàng)建數(shù)據(jù)庫，新建查詢。
6、uuid-hex 是自動生成的16位不可能重復(fù)。
UUID做主鍵,好還是不好
1、不能當(dāng)主鍵的原因：MySQL寫入數(shù)據(jù)時，會把數(shù)據(jù)存放到索引頁中。MySQL寫入數(shù)據(jù)時，會把數(shù)據(jù)存放到索引頁中。
2、因為uuid相對順序的自增id來說是毫無規(guī)律可言的，新行的值不一定要比之前的主鍵的值要大，所以innodb無法做到總是把新行插入到索引的最后，而是需要為新行尋找新的合適的位置從而來分配新的空間。
3、至于說使用UUID后，URL顯得不友好，我覺得這多少是你的INT情結(jié)造成的慣性思維，其實，和INT類型相比，UUID才是最自然的主鍵選擇，注意，我這里用的是自然這個形容詞，仔細(xì)體會一下你能理解我的意思。
4、這樣得到一個ObjectId僅僅之比自增ID多了一個時間戳的獲取。另外考慮到自增ID都要做主鍵唯一索引，而UUID可以只做索引，不做唯一索引（利用其特性，可以不考慮唯一性過濾），其性能可以說并不比自增ID差。
為什么不建議用uuid作為主鍵
因為uuid相對順序的自增id來說是毫無規(guī)律可言的，新行的值不一定要比之前的主鍵的值要大，所以innodb無法做到總是把新行插入到索引的最后，而是需要為新行尋找新的合適的位置從而來分配新的空間。
作為主鍵，UUID長度過長，主鍵索引KeyLength長度過大，而影響能夠基于內(nèi)存的索引記錄數(shù)量，進(jìn)而影響基于內(nèi)存的索引命中率，而基于硬盤進(jìn)行索引查詢性能很差。嚴(yán)重影響數(shù)據(jù)庫服務(wù)器整體的性能表現(xiàn)。
使用UUID后，URL顯得冗長，不夠友好。如果上面說的UUID的所謂缺點都不成立的話，那么是否使用UUID做主鍵，唯一的問題就是效率了。
