mysql之優化篇(二)

二 優化數據庫對象

優化表的數據類型

procedure analyse() 進行優化

select * from zip procedure analyse()\G;
*************************** 1. row ***************************
Field_name: huasheng.zip.id
Min_value: 1
Max_value: 1148
Min_length: 1
Max_length: 4
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 574.5000
Std: 331.3989
Optimal_fieldtype: SMALLINT(4) UNSIGNED NOT NULL
*************************** 2. row ***************************
Field_name: huasheng.zip.album_id
Min_value: 28
Max_value: 19360
Min_length: 2
Max_length: 5
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 10434.2822
Std: 6283.5977
Optimal_fieldtype: SMALLINT(5) UNSIGNED NOT NULL
*************************** 3. row ***************************
Field_name: huasheng.zip.path
Min_value: /data1/hs/code/run/htdocs/image/uploadimg/book/10010.zip
Max_value: /data1/hs/code/run/htdocs/image/uploadimg/book/9997.zip
Min_length: 53
Max_length: 56
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 55.4294
Std: NULL
Optimal_fieldtype: CHAR(56) NOT NULL
*************************** 4. row ***************************
Field_name: huasheng.zip.url
Min_value: http://cdnimage.vread.com/uploadimg/book/10010.zip
Max_value: http://cdnimage.vread.com/uploadimg/book/9997.zip
Min_length: 47
Max_length: 50
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 49.4294
Std: NULL
Optimal_fieldtype: CHAR(50) NOT NULL
*************************** 5. row ***************************
Field_name: huasheng.zip.book_update_time
Min_value: 1462801256
Max_value: 1521532379
Min_length: 10
Max_length: 10
Empties_or_zeros: 203
Nulls: 0
Avg_value_or_avg_length: 1228442654.0549
Std: 42226563.4963
Optimal_fieldtype: INT(10) UNSIGNED NOT NULL
*************************** 6. row ***************************
Field_name: huasheng.zip.create_time
Min_value: 1505807792
Max_value: 1521510073
Min_length: 10
Max_length: 10
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 1512561864.5113
Std: 78254463.1419
Optimal_fieldtype: INT(10) UNSIGNED NOT NULL
*************************** 7. row ***************************
Field_name: huasheng.zip.update_time
Min_value: 1505811423
Max_value: 1521594999
Min_length: 10
Max_length: 10
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 1513347832.1777
Std: 0.0000

Optimal_fieldtype: INT(10) UNSIGNED NOT NULL



通過拆分提高表的訪問效率

垂直拆分 story / story_extra
        1 基本信息
  2 附加信息
水平拆分 分表
        1 表很大
2 表數據獨立性
3 需要把數據放到不同的介質上

三 鎖問題

mysql鎖分類

1 表鎖(myisam,適合讀多),開銷小,加鎖快,不易出現死鎖,鎖粒度大
2 行鎖(innodb,適合寫多和併發高的程序),開銷大,加鎖慢,會出現死鎖,鎖粒度小

行鎖優點:
1 在許多線程中訪問不同的行時,只存在少量鎖定衝突
2 回滾時只需要少量的更改
3 可以長時間鎖定單一的行
行鎖缺點:
1 比頁面鎖或者表鎖佔用更多的內存
2 大量使用/經常使用group by 操作/掃全表操作,速度慢


查看鎖狀態

show status like 'table%'



事務的ACID屬性

原子性。要麼全部執行,要麼全部不執行。
一致性。事務開始和完成時數據保持一致性。
隔離性。事務不受外部併發操作影響。
持久性。當事務完成後,數據的修改是永久性的

查看innodb事務狀態

show status like '%innodb%';

innodb 鎖注意事項

1 不通過索引條件查詢,innodb確實用的是表鎖,不是行鎖。
2 mysql的行鎖是針對索引加的鎖,而不是針對記錄,使用相同的索引鍵可能出現衝突。
3 當表有多個索引的時候,不同的事務可以使用不同的索引鎖定不同的行,不論是使用主鍵索引,唯一索引,普通索引,innodb都是採用行鎖來對數據加鎖
4 即使創建了索引,能偶否使用索引還是由mysql判斷,如果代價高,innodb可能採用表鎖

mysql 儘量減少死鎖

1 儘量使用較低級別的隔離級別
2 精心設計索引並儘量使用索引反問數據,使加鎖更加精確
3 合理選擇事務大小
4 申請合適的事務級別
5 如果不同的程序會併發存取多個表,應儘量約定以相同的順序來訪問表。
6 批量處理數據時,先對數據排序,保證每個線程以固定的順序來訪問記錄
7 更新記錄直接使用排它鎖
8 更新同一條記錄可以採用READ COMMITED級別
四 優化Mysql Server

查看mysql 信息和狀態

show variables;
show status;

影響mysql性能的重要參數

適用於myisam:

key_buffer_size 設置索引塊緩存的大小

table_cache 數據庫打開表的緩存的數量
show status like '%open_tables%'

適用於 innodb

innodb_buffer_pool_size 緩存innodb表數據和索引數據的內存緩存區的大小
innodb_flush_log_at_trx_commit
控制緩衝區中的數據寫入到日誌文件以及日誌文件數據刷新到磁盤的操作時機。
0 每秒一次,並且刷新到磁盤
1 事務提交時,刷新到磁盤
2 提交事務時,日誌緩衝寫到日誌文件,但是不會刷新到磁盤。對日誌文件到磁盤的刷新每秒一次

innodb_addition_mem_pool_size
用來存儲數據庫結構和其他內部數據結構的內存池的大小,默認是1M,不夠會自動分配
innodb_lock_wait_timeout
自動監控行鎖導致的死鎖並進行相應的處理,表鎖不自動處理,默認50秒
innodb_support_xa 是否支持分佈式事務
innodb_log_buffer_size 日誌緩存的大小一般8-16M
innodb_log_file_size 日誌組中每個日誌文件的大小,默認5M, 負載越高,大點好
五 磁盤I/O問題

咱們介紹了優化sql,數據庫對象優化,數據庫參數優化,其實他們的目的就是優化和減少磁盤讀寫,因爲磁盤速度實在是太慢了(相對cpu和內存)
選擇合適的磁盤陣列 raid0/raid 1/raid 10/raid4/raid5
讀寫都很頻繁,可靠性很高 raid10
讀頻繁,寫相對較少,可靠性有一定要求 raid5
讀寫都很頻繁,可靠性不高 raid0


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章