mysql優化
給你一臺服務器讓你去優化，第一，先要去觀察問題，只有觀察到了問題，才能知道如何去優化。
先做基準測試，看看我們的服務器潛力到底有多大。
1.打開Mysql服務
2.查看我們Mysql的版本和安裝了哪些相關的東西
3.登錄Mysql
4.執行show status;
5.返回200多行數據，著重關註這3行
當前已經發生了多少次查詢
有幾個線程過來連接了（有多少個連接）
有幾個進程正在工作（連接中有多少個是活動的）
AWK：按行讀取文件，把當前行賦給變量$0,把當前行的第一列賦給$1,第二行賦給$2,以此類推。
下面這幾條命令執行的就是
- 把score.txt中的內容原樣打印出來。
- 把每一行的第一列的值打印出來
- 把每一行的第二列的值打印出來
AWK還可以使用正則匹配。如下這條命令，就是把l開頭的行，打印出來。
show status;命令，也可以用mysqladmin -uroot ext替換。
所以如下這條命令就是，把mysqladmin –uroot ext命令的結果，傳給awk，然後把Queries開頭的行的第四列的值打印出來
如下的命令是，把Queries，Threads_Connected，Threads_running開頭的行的第四列的值打印出來。
在AWK中，我們還可以設置變量，下面的名師是，把Queries，Threads_Connected，Threads_running開頭的行的第四列的值分別賦給變量q，c，r，然後再通過變量，把這些值打印出來，得到的結果是一樣的。
AWK的執行過程是會，把正則匹配及處理方式帶入到每一行。循環過程中的每一行，先通過正則對這一行進行匹配，如果匹配成功，則用處理方式進行處理，否則，跳過。就像上述命令，就是正則先匹配Queries，Threads_Connected，Threads_running，匹配成功之後，用處理方式進行處理，處理方式就是打印，也就是printf函數
試驗
1.啟動memcached，給他512M內存
2.啟動Nginx
3.由於我們的nginx是fastcgi的方式，所以需要把php也起來
表的優化與列類型選擇
列選取原則
- 字段類型優先級，整型>data,time>enum>char,varchar>blob
原因：整型，time運算塊，節省空間
char varchar要考慮字符集的轉換與排序時的校對集，速度慢
Blob無法使用內存臨時表
- 夠用就行，不要慷慨(如smallint，varchar(N))
原因：大的字段浪費內存，影響速度
以varchar(10),varchar(300)存儲的內容相同，但是在表聯查時，varchar(300)需要花更多的內存
- 進來避免用NULL
原因：NULL不利於索引，要用特殊的字符來標註
在磁盤上占據的空間其實更大
試驗
可以建立2張字段相同的表，一個允許為null，一個不允許為null，各加入1W條數據，查看索引文件的大小。可以發現null的索引要大些
Enum類說明
- enum列在內部用整型來存儲
2.enum列月enum列想關聯速度最快（意思是如果一張表的字段使用了enum，那麽另外一張表也盡量使用enum）
3.enum列比char,varchar的弱勢—---在碰到與char關聯時，要轉化，要花時間
4.有時在於，當char非常長時，enum依然是整型固定長度。當查詢的數據量越大時，enum的有時越明顯
5.enum與char，varchar關聯，因為要轉化，速度要比enum->enum,char->char要慢
但有時候也這樣用----就是在暑假了特別大時，可以節省IO
Mysql事務
我們首先開啟兩個Mysql客戶端，分別用黑色和綠色表示。
在黑色客戶端總，創建一張賬戶表(用戶名，錢數)
並且插入兩條數據，zhang:5000塊錢 li:3000塊錢
此時，我們可以在綠色客戶端中看到我們插入的數據
現在我們在黑色客戶端中，開啟事務，並且模擬給li用戶匯款10000。
這時，我們在綠色的客戶端中，再次查詢賬戶，可以看到，li的賬戶的錢並沒有增加。
因為，我沒有提交事務。也就是說這個事務還沒有完。如果此時能查到li的賬戶的錢多了。那麽就違背了原子性了。原子是最小的，我們不可能看到原子的一半。提交事務之前，我們的操作是被寫到事務日誌中，而沒有被寫到磁盤中。
我們在黑色客戶端中執行commit，來提交事務
現在我們在綠色客戶端中在查詢就可以查到li的賬戶多了10000塊錢
read uncommitted
現在我們做測試，修改一下隔離級別改為(read uncommitted,臟讀)
現在黑色客戶端中，修改事務隔離級別，並模擬匯款操作，但不提交事務
同時修改綠色客戶端的事務級別，並且進行賬戶查詢。(這裏有個疑問，如果綠色客戶端不修改事務隔離級別，結果會是什麽呢？)
read committed
現在我們做測試，修改一下隔離級別改為(read committed)
我們在黑色的客戶端中，修改事務隔離級別，並開始事務，模擬匯款操作。但不提交事務
我們在綠色客戶端中，也同樣修改事務隔離級別，並且開啟一個事務，然後查詢賬戶。按照臟讀的級別來講，雖然黑色客戶端並沒有提交事務，但綠色客戶端現在我們應該能看到賬戶的錢在增加。但是對於read committed級別，黑色客戶端不提交事務，綠色客戶端是看不到錢在增加的。也就是說黑色客戶端事務沒有結束，綠色客戶端是讀不到數據的變化。
現在，我們讓黑色客戶端提交事務。
此時，再在綠色客戶端查詢賬戶信息，可以查詢到前增長了，變成33000了。其實此時還是不應該被讀到的。為什麽說還是不應該被讀到呢？在黑色客戶端事務沒有結束的時候，綠色客戶端讀不到數據的變化。但是在黑色客戶端事務結束了，我們讀到數據的變化不是正常的嗎。原因是這，因為我們在綠色客戶端中也開啟了一個事務。並且這個事務也沒有結束。他應該也收不到外界的影響才對。也就是說在他開啟事務的那一瞬間，外面的世界是什麽樣，在他結束事務之前，他眼中外面的世界，應該始終都是一個樣。或者說，在事務過程中，外界的變化怎麽變化都影響不到我，外界的變化應該不被該事務內部所看到。
一個沒結束的事務，他的內部數據變化不能被外面所看到。反之，一個事務沒結束，他也不能看到外面的變化
repeated able 就是我們最終想要的一個事務級別。
黑色客戶端，修改事務隔離級別，開啟事務，update數據模擬匯款操作，但並不提交事務
此時在綠色客戶端修改隔離級別，並開啟事務，此時查詢的數據仍然是33000，沒有變化。也就是在黑色客戶端沒有提交事務的時候，綠色客戶端是看不到的。
此時在讓黑色客戶端提交事務
此時我們再在綠色客戶端中查詢賬戶信息。依然看不到變化。仍然是33000
最後我們讓綠色客戶端也提交事務。提交事務之後，再來查看賬戶信息。此時就可以看到賬戶信息變化為43000了。
serialize
把所有操作都串行化，所有 操作都一句一句的執行，有先後之分，這樣互相操作之間就肯定沒有影響了。這個級別非常高，但是效率就比較低了。
一般項目中的事務隔離級別都設為默認的repeatable
mysql優化