MySQL优化大全
1. 優化SQL
??1）通過show status了解各種sql的執行頻率
??????? show status like 'Com_%'
? ? ? ? 了解 Com_select,Com_insert 的執行次數
?? 2)? 通過Explain分析低效的sql語句
?? 3)?? 建立合適的索引
?? 4)?? 通過show status like 'Handler_%'查看索引的使用情況
???????? handler_read_key：根據索引讀取行的請求數。如果該值很大，說明你的查詢和表都建立了很好的索引，表明索引效率的很高
??? ? ?? Handler_read_rnd_key：根據固定位置讀取行的請求數。如果你執行很多需要排序的查詢，該值會很高。你可能有很多需要完整表掃描的查詢，或者你使用了不正確的索引用來多表查詢。
? ? ? ? ?Handler read rnd next：從數據文件中讀取行的請求數。如果你在掃描很多表，該值會很大。通常情況下這意味著你的表沒有做好索引，或者你的查詢語句沒有使用好索引字段。
?? 5)?? 定期分析表和檢查表
???????? analyze table test_table和check table test_table
???????? 然后查看Msg_text字段的值是否是ok
?? 6）定期優化表 optimize table test_table
???????? 如果對表的可變字段varchar blob，text等進行了很多更改， 則應用OPTIMIZE優化。
? ? ? ? ?在多數的設置中，您根本不需要運行OPTIMIZE TABLE。即使您對可變長度的行進行了大量的更新，您也不需要經常運行，每周一次或每月一次即可，只對特定的表運行。
? ? ? ?OPTIMIZE TABLE只對MyISAM, BDB和InnoDB表起作用。
? ? ? ?對于MyISAM表，OPTIMIZE TABLE按如下方式操作：
? ? ? ?如果表已經刪除或分解了行，則修復表。
? ? ? ?如果未對索引頁進行分類，則進行分類。
? ? ? ?如果表的統計數據沒有更新（并且通過對索引進行分類不能實現修復），則進行更新。
? ?7)? 優化 order by orgroup by等
? ? 詳細內容：SQL優化大全
2. 優化數據庫對象
1）選擇表合適存儲引擎：
????????????MyISAM:? 應用時以讀和插入操作為主，只有少量的更新和刪除，并且對事務的完整性，并發性要求不是很高的.
????????????Innodb：?事務處理，以及并發條件下要求數據的一致性。除了插入和查詢外，包括很多的更新和刪除。（Innodb有效地降低刪除和更新導致的鎖定）。對于支持事務的InnoDB類型的表來說，影響速度的主要原因是AUTOCOMMIT默認設置是打開的，而且程序沒有顯式調用BEGIN 開始事務，導致每插入一條都自動提交，嚴重影響了速度?？梢栽趫绦衧ql前調用begin，多條sql形成一個事物（即使autocommit打開也可以），將大大提高性能。
????????????Memory：數據保存在RAM,快速訪問數據。要求表不能太大或者對MySQL異常終止后不用恢復數據的
? ? ? ? ? ??Merge:??????
2）優化表的數據類型,選擇合適的數據類型：
?????????? 原則：更小通常更好，簡單就好，所有字段都得有默認值,盡量避免null：
?????????? 例如：數據庫表設計時候更小的占磁盤空間盡可能使用更小的整數類型.(mediumint就比int更合適)
? ? ? ? ? ?比如時間字段：datetime和timestamp,?datetime占用8個字節，而timestamp占用4個字節，只用了一半，而timestamp表示的范圍是1970—2037適合做更新時間
MySQL可以很好的支持大數據量的存取，但是一般說來，數據庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中字段的寬度設得盡可能小。例如，在定義郵政編碼這個字段時，如果將其設置為CHAR(255),顯然給數據庫增加了不必要的空間，甚至使用VARCHAR這種類型也是多余的，因為CHAR(6)就可以很好的完成任務了。同樣的，如果可以的話，我們應該使用MEDIUMINT而不是BIGIN來定義整型字段。
另外一個提高效率的方法是在可能的情況下，應該盡量把字段設置為NOT NULL，這樣在將來執行查詢的時候，數據庫不用去比較NULL值。
對于某些文本字段，例如“省份”或者“性別”，我們可以將它們定義為ENUM類型。因為在MySQL中，ENUM類型被當作數值型數據來處理，而數值型數據被處理起來的速度要比文本類型快得多。這樣，我們又可以提高數據庫的性能。
3) 字符串數據類型：char，varchar，text選擇區別
? ? ? ?(1)長度的區別，char范圍是0～255，varchar最長是64k，但是注意這里的64k是整個row的長度，要考慮到其它的column，還有如果存在not null的時候也會占用一位，對不同的字符集，有效長度還不一樣，比如utf8的，最多21845，還要除去別的column，但是varchar在一般情況下存儲都夠用了。如果遇到了大文本，考慮使用text，最大能到4G。?
? ? ??(2) 效率來說基本是char>varchar>text，但是如果使用的是Innodb引擎的話，推薦使用varchar代替
? ???(3)默認值??charchar和varchar可以有默認值，text不能指定默認值
4）MySQL中float數據類型的問題
? ? ? (1) .FLOAT或DOUBLE列與具有數值類型的數值進行比較，不能使用等式(=)比較.這個是因為浮點數精度的問題,會產生誤差。
? (2)對貨幣等對精度敏感的數據，應該用定點數表示或存儲
? ? ? 數據庫選擇合適的數據類型存儲還是很有必要的，對性能有一定影響。這里在零碎記錄兩筆，對于int類型的，如果不需要存取負值，最好加上unsigned；對于經常出現在where語句中的字段，考慮加索引，整型的尤其適合加索引。
?5）在InnoDB數據表設計中，我們需要注意幾點：
? ? 1.?顯式的定義一個?INT?類型自增字段的主鍵，這個字段可以僅用于做主鍵，不做其他用途
? ? 2.?如果不顯式定義主鍵的話，可能會導致InnoDB每次都需要對新數據行進行排序，嚴重損害性能
? ? 3.?盡量保證不對主鍵字段進行更新修改，防止主鍵字段發生變化，引發數據存儲碎片，降低IO性能
? ? 4.?如果需要對主鍵字段進行更新，請將該字段轉變成一個唯一索引約束字段，另外創建一個沒有其他業務意義的自增字段做主鍵
? ? 5.?主鍵字段類型盡可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT
? ? 6.?主鍵字段放在數據表的第一順序
3. 優化索引
索引是提高數據庫性能的常用方法，它可以令數據庫服務器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(), MIN()和ORDERBY這些命令的時候，性能提高更為明顯.
? ??那該對哪些字段建立索引呢？一般說來，索引應建立在那些將用于JOIN, WHERE判斷和ORDER BY排序的字段上。盡量不要對數據庫中某個含有大量重復的值的字段建立索引。對于一個ENUM類型的字段來說，出現大量重復值是很有可能的情況，例如customerinfo中的“province”..字段，在這樣的字段上建立索引將不會有什么幫助；相反，還有可能降低數據庫的性能。我們在創建表的時候可以同時創建合適的索引，也可以使用ALTER TABLE或CREATE INDEX在以后創建索引
1）. 普通索引
? ? ? ? 普通索引(由關鍵字KEY或INDEX定義的索引)的唯一任務是加快對數據的訪問速度。因此，應該只為那些最經常出現在查詢條件(WHERE column = …)或排序條件(ORDER BY column)中的數據列創建索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的數據列(如一個整數類型的數據列)來創建索引。
2）. 唯一索引
? ? ? ? 普通索引允許被索引的數據列包含重復的值。比如說，因為人有可能同名，所以同一個姓名在同一個”員工個人資料”數據表里可能出現兩次或更多次。
如果能確定某個數據列將只包含彼此各不相同的值，在為這個數據列創建索引的時候就應該用關鍵字UNIQUE把它定義為一個唯一索引。這么做的好處：一是簡化了MySQL對這個索引的管理工作，這個索引也因此而變得更有效率；二是MySQL會在有新記錄插入數據表時，自動檢查新記錄的這個字段的值是否已經在某個記錄的這個字段里出現過了；如果是，MySQL將拒絕插入那條新記錄。也就是說，唯一索引可以保證數據記錄的唯一性。事實上，在許多場合，人們創建唯一索引的目的往往不是為了提高訪問速度，而只是為了避免數據出現重復。
3）. 主索引
? ? ? ? 在前面已經反復多次強調過：必須為主鍵字段創建一個索引，這個索引就是所謂的”主索引”。主索引與唯一索引的唯一區別是：前者在定義時使用的關鍵字是PRIMARY而不是UNIQUE。
?4）. 外鍵索引
? ? ? ? ?如果為某個外鍵字段定義了一個外鍵約束條件，MySQL就會定義一個內部索引來幫助自己以最有效率的方式去管理和使用外鍵約束條件。
?5）. 復合索引
? ? ? ? 索引可以覆蓋多個數據列，如像INDEX(columnA, columnB)索引。這種索引的特點是MySQL可以有選擇地使用一個這樣的索引。如果查詢操作只需要用到columnA數據列上的一個索引，就可以使用復合索引INDEX(columnA, columnB)。不過，這種用法僅適用于在復合索引中排列在前的數據列組合。比如說，INDEX(A, B, C)可以當做A或(A, B)的索引來使用，但不能當做B、C或(B, C)的索引來使用。
4. 表鎖的問題
? ? ?跟性能相關的最重要的區別就是 MyISAM 和 InnoDB 實現的鎖機制不一樣！?MyISAM 使用的是表鎖， 而 InnoDB實現的是行鎖。
1) MyISAM為表級鎖
??????? 由于MyISAM寫進程優先獲得鎖，使得讀鎖請求靠后等待隊列。不僅如此， 即使讀請求先到鎖等待隊列，寫請求后 到，寫鎖也會插到讀鎖請求之前！這是因為MySQL認為寫請求一般比讀請求要重要。? ? ? ? 如果在大量更新操作的情況下，使得很難獲得讀鎖。從而造成阻塞。
??????? 所以MyIsam不適合做大量更新操作的原因
2 )INNODB的行鎖是基于索引實現，如果不通過索引訪問數據，Innodb會使用表鎖
?
表級鎖更適合以查詢為主，只有少量按索引條件更新數據的應用。
行級鎖更適合于有大量按索引條件并發更新少量不同數據，同時又并發查詢。因為只鎖定要操作的行， 所以可以多個線程同時操作不同的行（只要不操作其他線程已經鎖定的行）。
5. MySQL server服務器配置優化
?? 1）使用show variables 了解服務器參數?? 2）show status 了解服務器運行狀態，如鎖等待情況，當前連接數等
?? 3）影響mysql性能的重要參數：
???? ? ? key_buffer_size設置索引塊的緩存大小：key_buffer_size是對MyISAM表性能影響最大的一個參數
? ? ? ? 通過：
? ??mysql> show global status like 'key_read%';
+-------------------+------------+
| Variable_name ? ? | Value ? ? ?|
+-------------------+------------+
| Key_read_requests | 3465117712 |
| Key_reads ? ? ? ? | 624 ? ? ? ?|
+-------------------+------------+
? ?Key_read_requests：從緩存讀取索引的請求次數。
? ?Key_reads：從磁盤讀取索引的請求次數。
? ?通常人們認為Key_read_requests / Key_reads越大越好
? ? 需要適當加大key_buffer_size?
???? ? ? table_cache和max_connections有關， 例如 對于200個并行運行的連接，應該讓表的緩存至少是200 *N
???? ??? N 是可以執行查詢的一個連接中的表的最大數
??? 4)? 還有innodb_buffer_pool_size等innodb參數的設置
6. 磁盤IO優化
對于我們數據庫調優來說，磁盤I/O優化是首屈一指的調優重點，我們都知道木桶原理，短板絕對整體的好壞，而數據庫系統中這個短板正是由于我們使用的硬件設備里最弱的磁盤所導致。很多時候，我們會發現系統中I/O累得要死，而CPU卻在那里空閑等待，主要是由于I/O執行響應時間太長，處理讀寫 的速度遠遠趕落后于CPU的處理速度，這時我們會盡可能的讓操作放到內存中進行，由磁盤與CPU的關系，轉變成內存與CPU的關系。但是，我們始終不能回 避磁盤I/O的弱點，優化是必須的。
? ? ? ??磁盤搜索是巨大的性能瓶頸。當數據量變得非常大以致于緩存性能變得不可能有效時，該問題變得更加明顯。對于大數據庫，其中你或多或少地隨機訪問數據，你可以確 信對讀取操作需要至少一次硬盤搜索，寫操作需要多次硬盤搜索。要想使該問題最小化， 應使用搜索次數較少的磁盤。
1）使用磁盤陣列? RAID (廉價磁盤冗余陣列)
???????? RAID就是按照一定的策略將數據分布到若干物理磁盤上，這樣不僅增強了數據存儲的可靠性，而且提高數 據讀寫的性能 （RAID有不能的級別）???????? 1) 讀寫很頻繁的，可靠性要求也很高的，最好RAID 10
???????? 2) 數據讀很頻繁，寫相對較少的，對可靠性一定要求的，選擇RAID 5
???????? 3) 數據讀寫都很頻繁，但是可靠性要求不高的可以選擇RAID 0
? ?2) 使用符號鏈接 分布I/O
? ? ? ? ? MYSQL在默認的情況下，數據庫和數據表都存放在參數datadir定義的目錄下，這樣如果不使用RAID或者邏輯卷，所有的數據都存放在一個磁盤設備上，無法發揮多磁盤并 行讀寫的優勢。
? ? ? ? ?可以將表和數據庫從數據庫目錄移動到其它的位置并且用指向新位置的符號鏈接進行替換。推薦的方法只需要將數據庫通過符號鏈接指到不同的磁盤。符號鏈接表僅作為是 最后的辦法。
? ? ? ??符號鏈接一個數據庫的方法是，首先在一些有空閑空間的硬盤上創建一個目錄，然后從 MySQL 數據目錄中創建它的一個符號鏈接。
? ? ? 例如：
? ? ? 注意：只有 MyISAM 表完全支持符號鏈接。對于其它表類型，如果試圖在操作系統?中的文件上用前面的任何語句使用符號鏈接，可能會出現奇怪的問題。
對于 MyISAM 表的符號鏈接的處理如下：
? ? ?1. 在數據目錄指，一定會有表定義文件、數據文件和索引文件。數據文件和索引文件可 以移到別處和在數據目錄中符號鏈接替代。表定義文件不能進行符號鏈接替換。
? ? ?2. 可以分別通過符號鏈接將數據文件和索引文件指到不同的目錄。
? ? ?3. 如果 mysqld 沒有運行，符號鏈接可以從服務器命令行使用 ln -s 手動完成。同樣，通過使用 DATA DIRECTORY 和 INDEX DIRECTORY 選項創建表，你可以指示運行的 MySQL 服務器執行符號鏈接。
? ? ?4. myisamchk 不用數據文件或索引文件替換符號鏈接。它直接工作在符號鏈接指向的文件。任何臨時文件創建在數據文件或索引文件所處的目錄中。
? ? ?5. 注釋：當你刪掉一個表時，如果該表使用了符號鏈接，符號鏈接和該符號鏈接指向的 文件都被刪除掉。這就是你不應以系統 root 用戶運行 mysqld 或允許系統用戶對 MySQL數據庫目錄有寫訪問權限的原因。
? ? ?6. 如果你用 ALTER TABLE ... RENAME 重命名一個表并且不將表移到另一個數據庫，數據庫目錄中的符號鏈接被重新命名為一個新名字并且數據文件和索引文件也相應地重新命名。
? ? ?7. 如果你用 ALTER TABLE ... RENAME 移動一個表到另一個數據庫，表移動到另一個數據庫目錄。舊的符號鏈接和其所指向的文件被刪除。換句話說，新表不再被鏈接。
? ? ?8. 如果不使用符號鏈接，你應對 mysqld 使用 --skip-symbolic-links 選項以確保沒有人能夠使用 mysqld 來刪除或重新命名數據目錄之外的文件。
????表符號鏈接還不支持以下操作：
? ? 1. ALTER TABLE 忽略 DATA DIRECTORY 和 INDEX DIRECTORY 表選項。
? ? 2. BACKUP TABLE 和 RESTORE TABLE 不考慮符號鏈接。
? ? 3. .frm 文件必須絕不能是一個符號鏈接（如前面所述，只有數據和索引文件可以是符鏈接）。如果試圖這樣做（例如，生成符號鏈接）會產生不正確的結果。
3) 禁止操作系統更新文件的atime屬性
7. 應用優化
1 )使用連接池
對于訪問數據庫來說，建立連接的代價比較昂貴，因此，我們有必要建立 " 連接池 " 以提高訪問的性能。我們可以把連接當作對象或者設備，池中又有許多已經建立的連接，訪 問本來需要與數據庫的連接的地方，都改為和池相連，池臨時分配連接供訪問使用，結果返 回后，訪問將連接交還。
2)減少對mysql的訪問，使用mem緩存等
3)負載均衡，復制分流查詢操作?????????? 利用mysql的主從復制，分流更新操作和查詢操作
????????? 1), 創建復制賬號：Gran replication slave on *.* to 'rel'@'10.0.1.2' identified by '123456'
????????? 2), 修改主服務器的配置my.conf 開啟binlog和設置server-id
???? ? ?? 3), 將主服務器的數據一致性恢復到從服務器，保證將要復制的數據時一只的，否則出問題
????????? 4), 在從服務器上修改配置my.conf
?????????????? server-id=2
?????????????? master-host=10.0.1.3
?????????????? master-user='rel'
???????????? ? master-password='123456'
???????????? ? master-port='3306'
????????? 5), 從服務器啟動slave線程： start slave
????????? show processlist 查看。
4) 分布式cluster 數據庫架構
8. 分庫分表
1）水平劃分
? ? 如果某個表的數據太多，預期有上千條甚至上億以上，我們可以化整為0：拆表。
? ? 這里就涉及到拆表的算法：
? ? 記錄日志的表，也可以按周或者按月來拆。
? ? 記錄用戶信息的表，按用戶id的hash算法來拆。
2）垂直拆分
如果表記錄數并不多，可能也就2、3萬條，但是字段卻很長，表占用空間很大，檢索表時需要執行大量I/O，嚴重降低了性能。這個時候需要把大的字段拆分到另一個表，并且該表與原表是一對一的關系。 ?
分庫解決方案原則：
n安全性拆分：
將高安全性數據與低安全性數據分庫，這樣的好處第一是便于維護，第二是高安全性數據的數據庫參數配置可以以安全優先，而低安全性數據的參數配置以性能優先。參見運維優化相關部分。
n基于業務邏輯拆分
1）根據數據表的內容構成，業務邏輯拆分，便于日常維護和前端調用。
2）基于業務邏輯拆分，可以減少前端應用請求發送到不同數據庫服務器的頻次，從而減少鏈接開銷。
3）基于業務邏輯拆分，可保留部分數據關聯，前端web工程師可在限度范圍內執行關聯查詢。
n基于負載壓力拆分
? ? ? ? ? ?1）基于負載壓力對數據結構拆分，便于直接將負載分擔給不同的服務器。
2）基于負載壓力拆分，可能拆分后的數據庫包含不同業務類型的數據表，日常維護會有一定的煩惱。
n混合拆分組合
1）基于安全與業務拆分為數據庫實例，但是可以使用不同端口放在同一個服務器上。
2）基于負載可以拆分為更多數據庫實例分布在不同數據庫上
如：
基于安全拆分出A數據庫實例，
基于業務拆分出B,C數據庫實例，
數據庫存在較高負載，基于負載拆分為C1,C2,C3,C4等實例。
數據庫服務器完全可以做到 A+B+C1 為一臺，C2,C3,C4各單獨一臺。
分表方案解決原則
1、一般數據量過大或者訪問壓力過大的數據表需要切分
? ? ? ? ? 2、表的字段不宜過多。
n縱向分表
? ?單數據表字段過多，可將頻繁更新的整數數據與非頻繁更新的字符串數據切分
范例user表 ，個人簡介，地址，QQ號，聯系方式，頭像 這些字段為字符串類型，更新請求少； 最后登錄時間，在線時常，訪問次數，信件數這些字段為整數型字段，更新頻繁，可以將后面這些更新頻繁的字段獨立拆出一張數據表，表內容變少，索引結構變少，讀寫請求變快。
n橫向切表
1）等分切表，如哈希切表或其他基于對某數字取余的切表。等分切表的優點是負載很方便的分布到不同服務器；缺點是當容量繼續增加時無法方便的擴容，需要重新進行數據的切分或轉表。而且一些關鍵主鍵不易處理。
2）遞增切表，比如每1kw用戶開一個新表，優點是可以適應數據的自增趨勢；缺點是往往新數據負載高，壓力分配不平均。
3）日期切表，適用于日志記錄式數據，優缺點等同于遞增切表。
4）個人傾向于遞增切表，具體根據應用場景決定。
n熱點數據分表
1）將數據量較大的數據表中將讀寫頻繁的數據抽取出來，形成熱點數據表。通常一個龐大數據表經常被讀寫的內容往往具有一定的集中性，如果這些集中數據單獨處理，就會極大減少整體系統的負載。
2）熱點數據表與舊有數據關系
可以是一張冗余表，即該表數據丟失不會妨礙使用，因源數據仍存在于舊有結構中。優點是安全性高，維護方便，缺點是寫壓力不能分擔，仍需要同步寫回原系統。
可以是非冗余表，即熱點數據的內容原有結構不再保存，優點是讀寫效率全部優化；缺點是當熱點數據發生變化時，維護量較大。
具體方案選擇需要根據讀寫比例決定，在讀頻率遠高于寫頻率情況下，優先考慮冗余表方案。
3）熱點數據表可以用單獨的優化的硬件存儲，比如昂貴的閃存卡或大內存系統。
4）熱點數據表的重要指標
熱點數據的定義需要根據業務模式自行制定策略，常見策略為，按照最新的操作時間；按照內容豐富度等等。
數據規模，比如從1000萬條數據，抽取出100萬條熱點數據。
熱點命中率，比如查詢10次，多少次命中在熱點數據內。
理論上，數據規模越小，熱點命中率越高，說明效果越好。需要根據業務自行評估。
5）熱點數據表的動態維護
加載熱點數據方案選擇
定時從舊有數據結構中按照新的策略獲取
在從舊有數據結構讀取時動態加載到熱點數據
剔除熱點數據方案選擇
基于特定策略，定時將熱點數據中訪問頻次較少的數據剔除
如熱點數據是冗余表，則直接刪除即可，如不是冗余表，需要回寫給舊有數據結構。
6）通常，熱點數據往往是基于緩存或者key-value方案冗余存儲，所以這里提到的熱點數據表，其實更多是理解思路，用到的場合可能并不多….
9. 反范式設計（冗余結構設計）
反范式設計的概念
無外鍵，無連表查詢。
便于分布式設計，允許適度冗余，為了容量擴展允許適度開銷。
基于業務自由優化，基于i/o 或查詢設計，無須遵循范式結構設計。
冗余結構設計所面臨的典型場景
原有展現程序涉及多個表的查詢，希望精簡查詢程序
數據表拆分往往基于主鍵，而原有數據表往往存在非基于主鍵的關鍵查詢，無法在分表結構中完成。
存在較多數據統計需求（count, sum等），效率低下。
冗余設計方案
1）基于展現的冗余設計
為了簡化展現程序，在一些數據表中往往存在冗余字段：
舉例，信息表message，存在字段fromuid,touid,msg,sendtime四個字段，其中touid+sendtime是復合索引。存在查詢為select * from message where touid=$uid order by sendtime desc limit 0,30;
展示程序需要顯示發送者姓名，此時通常會在message表中增加字段fromusername，甚至有的會增加fromusersex，從而無需連表查詢直接輸出信息的發送者姓名和性別。這就是一種簡單的，為了避免連表查詢而使用的冗余字段設計。
2）基于展現的冗余設計
涉及分表操作后，一些常見的索引查詢可能需要跨表，帶來不必要的麻煩。確認查詢請求遠大于寫入請求時，應設置便于查詢項的冗余表。
冗余表要點：
數據一致性，簡單說，同增，同刪，同更新。
可以做全冗余，或者只做主鍵關聯的冗余，比如通過用戶名查詢uid，再基于uid查詢源表。
實戰范例1
用戶分表，將用戶庫分成若干數據表
基于用戶名的查詢和基于uid的查詢都是高并發請求。
用戶分表基于uid分成數據表，同時基于用戶名做對應冗余表。
如果允許多方式登陸，可以有如下設計方法
nuid,passwd,用戶信息等等，主數據表，基于uid分表
nukey,ukeytype,uid基于ukey分表，便于用戶登陸的查詢。分解成如下兩個SQL。
uselect uid from ulist_key_13 where ukey=’$username’ and ukeytype=‘login’;
uselect * from ulist_uid_23 where uid=$uid and passwd=’$passwd’;
nukeytype定義用戶的登陸依據，比如用戶名，手機號，郵件地址，網站昵稱等。Ukey+ukeytype 必須唯一。
n此種方式需要登陸密碼統一，對于第三方connect接入模式，可以通過引申額外字段完成。
實戰范例2：用戶游戲積分排名
表結構uid,gameid,score參見前文實時積分排行。表內容巨大，需要拆表。
需求1：基于游戲id查詢積分排行
需求2：基于用戶id查詢游戲積分記錄
解決方案：建立完全相同的兩套表結構，其一以uid為拆表主鍵，其二以gameid為拆表主鍵，用戶提交積分時，向兩個數據結構同時提交。
實戰范例3：全冗余查詢結構
主信息表僅包括 主鍵及備注memo字段（text類型），只支持主鍵查詢，可以基于主鍵拆表。所以需要展現和存儲的內容均在memo字段重體現。
對每一個查詢條件，建立查詢冗余表，以查詢條件字段為主鍵，以主信息表主鍵id為內容。
日常查詢只基于查詢冗余表，然后通過in的方式從主信息表獲得內容。
優點是結構擴展非常方便，只需要擴展新的查詢信息表即可，核心思路是，只有查詢才需要獨立的索引結構，展現無需獨立字段。
缺點是只適合于相對固定的查詢架構，對于更加靈活的組合查詢束手無策。
3）基于統計的冗余結構
為了減少會涉及大規模影響結果集的表數據操作，比如count，sum操作。應將一些統計類數據通過冗余數據結構保存。
冗余數據結構可能以字段方式存在，也可能以獨立數據表結構存在，但是都應能通過源數據表恢復。
實戰范例：
論壇板塊的發帖量，回帖量，每日新增數據等。
網站每日新增用戶數等。
參見Discuz論壇系統數據結構，有較多相關結構。
參見前文分段積分結構，是典型用于統計的冗余結構。
后臺可以通過源數據表更新該數字。
Redis的Zset類型可以理解為存在一種冗余統計結構。
4）歷史數據表
歷史數據表對應于熱點數據表，將需求較少又不能丟棄的數據存入，僅在少數情況下被訪問。
from: http://blog.csdn.net/hguisu/article/details/5713180
總結
- 上一篇： SQL优化大全
- 下一篇： Mysql 多表联合查询效率分析及优化