網站訪問量資料庫設計
網站訪問量大，優化mysql資料庫的方法：
1、創建索引
對於查詢佔主要的應用來說，索引顯得尤為重要。很多時候性能問題很簡單的就是因為我們忘了添加索引而造成的，或者說沒有添加更為有效的索引導致。如果不加索引的話，那麼查找任何哪怕只是一條特定的數據都會進行一次全表掃描，如果一張表的數據量很大而符合條件的結果又很少，那麼不加索引會引起致命的性能下降。但是也不是什麼情況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什麼優勢，還會影響到更新速度，這被稱為過度索引。
2、復合索引
比如有一條語句是這樣的：select * from users where area='beijing' and age=22;
如果我們是在area和age上分別創建單個索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果在area、age兩列上創建復合索引的話將帶來更高的效率。如果我們創建了(area, age, salary)的復合索引，那麼其實相當於創建了(area,age,salary)、(area,age)、(area)三個索引，這被稱為最佳左前綴特性。因此我們在創建復合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
3、索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那麼這一列對於此復合索引就是無效的。所以我們在資料庫設計時不要讓欄位的默認值為NULL。
4、使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的 列，如果在前10 個或20 個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。
5、排序的索引問題
mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
6、like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可以使用索引。
7、不要在列上進行運算
select * from users where YEAR(adddate)<2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成
select * from users where adddate<『2007-01-01';
8、不使用NOT IN和<>操作
NOT IN和<>操作都不會使用索引將進行全表掃描。NOT IN可以NOT EXISTS代替，id<>3則可使用id>3 or id<3來代替。
㈡ 如果有一個特別大的訪問量，到資料庫上，怎麼做優化
DB設計：
永遠為每張表設置一個ID ，並作為主鍵
創建索引，必要時用聯合索引，並設計索引時避免有默認NULL值的列
DBIO
資料庫做讀寫分離和主從同步,主庫負責寫入和更新操作,從庫負責查詢
SQL優化：
不鼓勵使用like操作，不要在列上進行運算，不使用NOT IN和<>操，當只要一行數據時使用 LIMIT 1，在Join表的時候使用相當類型的例，並將其索引 ，避免 SELECT * 這種查詢方法，用什麼數據取什麼數據
Java優化：
加緩存
㈢ 大數據量高並發訪問資料庫結構的設計
大數據量高並發訪問資料庫結構的設計
如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成，資料庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。
原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
6、若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
7、主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8、主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9、中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
10、防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
11、在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用編程語言計算處理完成之後，最後才入庫追加到表中去。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個欄位做主鍵，單個表還可以，但是關聯關系就會有問題，主鍵自增是高性能的。
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作為聯合住建，另建一個欄位作為主鍵。除非這條記錄沒有邏輯刪除標志，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。
㈣ ASP.net怎麼實現網站訪問量統計數據得保存到資料庫裡面
無論你什麼程序
其實訪問統計不要自己存到資料庫
首先對資料庫壓力很大而且很麻煩
你可以藉助第三方統計
比如網路統計都可以
希望能幫助到你
㈤ 如果有一個特別大的訪問量，到資料庫上，怎麼做優化
1、使用緩存技術如redis
2、數據表經常檢查，更新，修復
3、優化sql語句，而別是查詢語句
4、當只要一行數據時使用 LIMIT 1
5、為搜索欄位建立索引，這樣查詢速度更快
6、在Join表的時候使用相當類型的例，並將其索引
7、避免 SELECT * 這種查詢方法，用什麼數據取什麼數據，這屬於sql優化
8、永遠為每張表設置一個ID ，並作為主鍵
9、使用 ENUM 而不是 VARCHAR
10、從 PROCEDURE ANALYSE() 取得建議，PROCEDURE ANALYSE() 會讓 MySQL 幫你去分析你的欄位和其實際的數據，並會給你一些有用的建議
11、盡可能的使用 NOT NULL
㈥ 網站訪問量大 怎樣優化mysql資料庫
I 硬體配置優化
CPU選擇：多核的CPU，主頻高的CPU
內存：更大的內存
磁碟選擇：更快的轉速、RAID、陣列卡，
網路環境選擇：盡量部署在區域網、SCI、光纜、千兆網、雙網線提供冗餘、0.0.0.0多埠綁定監聽
II 操作系統級優化
使用64位的操作系統，更好的使用大內存。
設置noatime,nodiratime
[zhangxy@dowload_server1 ~]$ cat /etc/fstab
LABEL=/ / ext3 defaults,noatime,nodiratime 1 1
/dev/sda5 /data xfs defaults,noatime,nodiratime 1 2
優化內核參數
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_max_syn_backlog=1024
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.neigh.default.gc_thresh3 = 2048
net.ipv4.neigh.default.gc_thresh2 = 1024
net.ipv4.neigh.default.gc_thresh1 = 256
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.tcp_syncookies = 1
net.core.netdev_max_backlog = 2048
net.core.dev_weight = 64
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_sack = 0
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_max_orphans = 32768
net.core.optmem_max = 20480
net.core.rmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_default = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 500
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_max_tw_buckets = 18000
net.ipv4.ip_forward = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.ip_local_port_range = 5000 65000
kernel.shmmax = 167108864
vm.swappiness=0
加大文件描述符限制
Vim /etc/security/limits.conf
加上
* soft nofile 65535
* hard nofile 65535
文件系統選擇 xfs
/dev/sda5 /data xfs defaults,noatime,nodiratime 1 2
III Mysql設計優化
III.1存儲引擎的選擇
Myisam：資料庫並發不大，讀多寫少,而且都能很好的用到索引，sql語句比較簡單的應用，TB數據倉庫
Innodb：並發訪問大，寫操作比較多，有外鍵、事務等需求的應用，系統內存較大。
III.2命名規則
多數開發語言命名規則：比如MyAdress
多數開源思想命名規則：my_address
避免隨便命名
III.3欄位類型選擇
欄位類型的選擇的一般原則：
根據需求選擇合適的欄位類型，在滿足需求的情況下欄位類型盡可能小。
只分配滿足需求的最小字元數，不要太慷慨。
原因：更小的欄位類型更小的字元數佔用更少的內存，佔用更少的磁碟空間，佔用更少的磁碟IO，以及佔用更少的帶寬。
III.3.1 整型：
見如下圖:
類型
位元組
最小值
最大值
(帶符號的/無符號的)
(帶符號的/無符號的)
TINYINT
1
-128
127
0
255
SMALLINT
2
-32768
32767
0
65535
MEDIUMINT
3
-8388608
8388607
0
16777215
INT
4
-2147483648
2147483647
0
4294967295
BIGINT
8
-9223372036854775808
9223372036854775807
0
18446744073709551615
根據滿足需求的最小整數為選擇原則，能用INT的就不要用BIGINT。
用無符號INT存儲IP，而非CHAR(15)。
III.3.2 浮點型：
類型
位元組
精度類型
使用場景
FLOAT(M,D)
4
單精度
精度要求不高，數值比較小
DOUBLE(M,D)（REAL）
8
雙精度
精度要求不高，數值比較大
DECIMAL(M,D)(NUMERIC）
M+2
自定義精度
精度要求很高的場景
III.3.3 時間類型
類型
取值范圍
存儲空間
零值表示法
DATE
1000-01-01~9999-12-31
3位元組
0000-00-00
TIME
-838:59:59~838:59:59
3位元組
00:00:00
DATETIME
1000-01-01 00:00:00~9999-12-31 23:59:59
8位元組
0000-00-00 00:00:00
TIMESTAMP
19700101000000~2037年的某個時刻
4位元組
00000000000000
YEAR
YEAR(4):1901~2155 YEAR(2)：1970~2069
1位元組
0000
III.3.4 字元類型
類型
最大長度
佔用存儲空間
CHAR[(M)]
M位元組
M位元組
VARCHAR[(M)]
M位元組
M+1位元組
TINYBLOD，TINYTEXT
2^8-1位元組
L+1位元組
BLOB，TEXT
2^16-1位元組
L+2
MEDIUMBLOB，MEDIUMTEXT
2^24-1位元組
L+3
LONGBLOB，LONGTEXT
2^32-1位元組
L+4
ENUM('value1','value2',...)
65535個成員
1或2位元組
SET('value1','value2',...)
64個成員
1,2,3,4或8位元組
註：L表示可變長度的意思
對於varchar和char的選擇要根據引擎和具體情況的不同來選擇，主要依據如下原則:
1. 如果列數據項的大小一致或者相差不大，則使用char。
2. 如果列數據項的大小差異相當大，則使用varchar。
3. 對於MyISAM表，盡量使用Char，對於那些經常需要修改而容易形成碎片的myisam和isam數據表就更是如此，它的缺點就是佔用磁碟空間。
4. 對於InnoDB表，因為它的數據行內部存儲格式對固定長度的數據行和可變長度的數據行不加區分（所有數據行共用一個表頭部分，這個標頭部分存放著指向各有關數據列的指針），所以使用char類型不見得會比使用varchar類型好。事實上，因為char類型通常要比varchar類型佔用更多的空 間，所以從減少空間佔用量和減少磁碟i/o的角度，使用varchar類型反而更有利。
5. 表中只要存在一個varchar類型的欄位，那麼所有的char欄位都會自動變成varchar類型，因此建議定長和變長的數據分開。
III.4編碼選擇
單位元組 latin1
多位元組 utf8(漢字佔3個位元組，英文字母佔用一個位元組)
如果含有中文字元的話最好都統一採用utf8類型，避免亂碼的情況發生。
III.5主鍵選擇原則
註：這里說的主鍵設計主要是針對INNODB引擎
1. 能唯一的表示行。
2. 顯式的定義一個數值類型自增欄位的主鍵，這個欄位可以僅用於做主鍵，不做其他用途。
3. MySQL主鍵應該是單列的，以便提高連接和篩選操作的效率。
4. 主鍵欄位類型盡可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT。
5. 盡量保證不對主鍵欄位進行更新修改，防止主鍵欄位發生變化，引發數據存儲碎片，降低IO性能。
6. MySQL主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等。
7. MySQL主鍵應當有計算機自動生成。
8. 主鍵欄位放在數據表的第一順序。
推薦採用數值類型做主鍵並採用auto_increment屬性讓其自動增長。
III.6其他需要注意的地方
NULL OR NOT NULL
盡可能設置每個欄位為NOT NULL，除非有特殊的需求，原因如下：
1. 使用含有NULL列做索引的話會佔用更多的磁碟空間，因為索引NULL列需要而外的空間來保存。
2. 進行比較的時候，程序會更復雜。
3. 含有NULL的列比較特殊，SQL難優化，如果是一個組合索引，那麼這個NULL 類型的欄位會極大影響整個索引的效率。
索引
索引的缺點：極大地加速了查詢，減少掃描和鎖定的數據行數。
索引的缺點：佔用磁碟空間，減慢了數據更新速度，增加了磁碟IO。
添加索引有如下原則：
1. 選擇唯一性索引。
2. 為經常需要排序、分組和聯合操作的欄位建立索引。
3. 為常作為查詢條件的欄位建立索引。
4. 限制索引的數據，索引不是越多越好。
5. 盡量使用數據量少的索引，對於大欄位可以考慮前綴索引。
6. 刪除不再使用或者很少使用的索引。
7. 結合核心SQL優先考慮覆蓋索引。
8. 忌用字元串做主鍵。
反範式設計
適當的使用冗餘的反範式設計，以空間換時間有的時候會很高效。
IV Mysql軟體優化
開啟mysql復制，實現讀寫分離、負載均衡，將讀的負載分攤到多個從伺服器上，提高伺服器的處理能力。
使用推薦的GA版本，提升性能
利用分區新功能進行大數據的數據拆分
V Mysql配置優化
注意：全局參數一經設置，隨伺服器啟動預佔用資源。
key_buffer_size參數
mysql索引緩沖，如果是採用myisam的話要重點設置這個參數，根據（key_reads/key_read_requests）判斷
innodb_buffer_pool_size參數
INNODB 數據、索引、日誌緩沖最重要的引擎參數，根據（hit riatos和FILE I/O）判斷
wait_time_out參數
線程連接的超時時間，盡量不要設置很大，推薦10s
max_connections參數
伺服器允許的最大連接數，盡量不要設置太大，因為設置太大的話容易導致內存溢出，需要通過如下公式來確定：
SET @k_bytes = 1024;
SET @m_bytes = @k_bytes * 1024;
SET @g_bytes = @m_bytes * 1024;
SELECT
(
@@key_buffer_size + @@query_cache_size + @@tmp_table_size+
@@innodb_buffer_pool_size + @@innodb_additional_mem_pool_size+
@@innodb_log_buffer_size+
@@max_connections *
( @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size+
@@join_buffer_size + @@binlog_cache_size + @@thread_stack
) )
/ @g_bytes AS MAX_MEMORY_USED_GB;
thread_concurrency參數
線程並發利用數量，(cpu+disk)*2,根據(os中顯示的請求隊列和tickets)判斷
sort_buffer_size參數
獲得更快的--ORDER BY,GROUP BY,SELECT DISTINCT,UNION DISTINCT
read_rnd_buffer_size參數
當根據鍵進行分類操作時獲得更快的--ORDER BY
join_buffer_size參數
join連接使用全表掃描連接的緩沖大小，根據select_full_join判斷
read_buffer_size參數
全表掃描時為查詢預留的緩沖大小，根據select_scan判斷
tmp_table_size參數
臨時內存表的設置，如果超過設置就會轉化成磁碟表，根據參數(created_tmp_disk_tables)判斷
innodb_log_file_size參數(默認5M)
記錄INNODB引擎的redo log文件，設置較大的值意味著較長的恢復時間。
Ø innodb_flush_method參數(默認fdatasync)
Linux系統可以使用O_DIRECT處理數據文件，避免OS級別的cache，O_DIRECT模式提高數據文件和日誌文件的IO提交性能
innodb_flush_log_at_trx_commit(默認1)
表示每秒進行一次log寫入cache，並flush log到磁碟。
表示在每次事務提交後執行log寫入cache，並flush log到磁碟。
表示在每次事務提交後，執行log數據寫入到cache，每秒執行一次flush log到磁碟。
VI Mysql語句級優化
1. 性能查的讀語句，在innodb中統計行數,建議另外弄一張統計表，採用myisam，定期做統計.一般的對統計的數據不會要求太精準的情況下適用。
2. 盡量不要在資料庫中做運算。
3. 避免負向查詢和%前綴模糊查詢。
4. 不在索引列做運算或者使用函數。
5. 不要在生產環境程序中使用select * from 的形式查詢數據。只查詢需要使用的列。
6. 查詢盡可能使用limit減少返回的行數，減少數據傳輸時間和帶寬浪費。
7. where子句盡可能對查詢列使用函數，因為對查詢列使用函數用不到索引。
8. 避免隱式類型轉換，例如字元型一定要用』』，數字型一定不要使用』』。
9. 所有的SQL關鍵詞用大寫，養成良好的習慣，避免SQL語句重復編譯造成系統資源的浪費。
10. 聯表查詢的時候，記得把小結果集放在前面，遵循小結果集驅動大結果集的原則。
11. 開啟慢查詢，定期用explain優化慢查詢中的SQL語句。