101個MySQL的設置裝備擺設和優化的提醒。本站提示廣大學習愛好者:(101個MySQL的設置裝備擺設和優化的提醒)文章只能為提供參考,不一定能成為您想要的結果。以下是101個MySQL的設置裝備擺設和優化的提醒正文
MySQL是一個功效壯大的開源數據庫。跟著愈來愈多的數據庫驅動的運用法式,人們一向在推進MySQL成長到它的極限。這裡是101條調理和優化 MySQL裝置的技能。一些技能是針對特定的裝置情況的,但這些思緒是通用的。我曾經把他們分紅幾類,來贊助你控制更多MySQL的調理和優化技能。
MySQL 辦事器硬件和操作體系調理:
1. 具有足夠的物理內存來把全部InnoDB文件加載到內存中——在內存中拜訪文件時的速度要比在硬盤中拜訪時快的多。
2. 不吝一切價值防止應用Swap交流分區 – 交流時是從硬盤讀取的,它的速度很慢。
3. 應用電池供電的RAM(注:RAM即隨機存儲器)。
4. 應用高等的RAID(注:Redundant Arrays of Inexpensive Disks,即磁盤陣列) – 最好是RAID10或更高。
5. 防止RAID5(注:一種存儲機能、數據平安和存儲本錢統籌的存儲處理計劃) – 確保數據庫完全性的校驗是要支付價值的。
6. 將操作體系和數據分辨別開,不只僅是邏輯上,還包含物理上 – 操作體系的讀寫操作會影響數據庫的機能。
7. 把MySQL暫時空間和復制日記與數據放到分歧的分區 – 當數據庫後台從磁盤停止讀寫操作時會影響數據庫的機能。
8. 更多的磁盤空間等於更快的速度。
17. 應用 XFS 文件體系 – 一種比ext3更快、更小的文件體系,而且有很多日記選項, 並且ext3 已被證明與MySQL有雙緩沖成績。
18. 調劑 XFS 文件體系日記懈弛沖變量 – 為了最高機能尺度。
19. 在 Linux 體系中, 應用 NOOP 或許 DEADLINE IO 准時調劑法式 – 同 NOOP 和 DEADLINE准時調劑法式比擬,這個 CFQ 和 ANTICIPATORY 准時調劑法式 顯得異常慢。
20. 應用64位的操作體系 – 關於MySQL,會有更年夜的內存支撐和應用。
21. 刪除辦事器上未應用的裝置包和守護過程 – 更少的資本占用。
22. 把應用MySQL的host和你的MySQL host放到一個hosts文件中 – 沒有DNS查找。
23. 切勿強迫殺逝世一個MySQL過程 – 你會破壞數據庫和正在運轉備份的法式。
24. 把辦事器進獻給MySQL – 後台過程和其他辦事可以或許延長數據庫占用CPU的時光。
MySQL 設置裝備擺設:
25. 當寫入時,應用 innodb_flush_method=O_DIRECT 來防止雙緩沖。
26. 防止應用 O_DIRECT 和 EXT3 文件體系 – 你將序列化一切要寫入的。
27. 分派足夠的 innodb_buffer_pool_size 來加載全部 InnoDB 文件到內存中– 少從磁盤中讀取。
28. 不要將 innodb_log_file_size 參數設置太年夜, 如許可以更快同時有更多的磁盤空間 – 丟失落多的日記平日是好的,在數據庫瓦解後可以下降恢單數據庫的時光。
29. 不要混用 innodb_thread_concurrency 和 thread_concurrency 參數– 這2個值是不兼容的。
30. 分派一個極小的數目給 max_connections 參數 – 太多的銜接會用盡RAM並鎖定MySQL辦事。
31. 堅持 thread_cache 在一個絕對較高的數字,年夜約 16 – 避免翻開銜接時遲緩。
32. 應用skip-name-resolve參數 – 去失落 DNS 查找。
33.假如你的查詢都是反復的,而且數據不經常產生變更,那末可使用查詢緩存。然則假如你的數據常常產生變更,那末應用查詢緩存會讓你覺得掉望。
34.增年夜temp_table_size值,以避免寫入磁盤
35.增年夜max_heap_table_size值,以避免寫入磁盤
36.不要把sort_buffer_size值設置的太高,不然的話你的內存將會很快耗盡
37.依據key_read_requests和key_reads值來決議key_buffer的年夜小,普通情形下key_read_requests應當比key_reads值高,不然你不克不及高效的應用key_buffer
38.將innodb_flush_log_at_trx_commit設置為0將會進步機能,然則假如你要堅持默許值(1)的話,那末你就要確保數據的完全性,同時你也要確保復制不會滯後。
39.你要有一個測試情況,來測試你的設置裝備擺設,而且在不影響正常臨盆的情形下,可以經常停止重啟。
MySQL形式優化:
40. 堅持你的數據庫整頓性。
41. 舊數據歸檔 - 刪除過剩的行前往或搜刮查詢。
42. 將您的數據加上索引.
43. 不要過度應用索引,比擬與查詢.
44. 緊縮文字和BLOB數據類型 - 以節儉空間和削減磁盤讀取次數.
45. UTF 8和UTF16都低於latin1履行效力.
46. 有控制地應用觸發器.
47. 冗余數據堅持到最低限制 - 不反復不用要的數據.
48. 應用鏈接表,而不是擴大行.
49. 留意數據類型,在您的真實數據中,盡量應用最小的一個.
50. 假如其他數據常常被用於查詢時,而BLOB / TEXT數據不是,就把BLOB / TEXT數據從其他數據分別出來.
51.檢討和常常優化表.
52. 常常重寫InnoDB表優化.
53. 有時,當添加列時刪除索引,然後在添加回來索引,如許就會更快.
54. 針對分歧的需求,應用分歧的存儲引擎.
55. 應用歸檔存儲引擎日記表或審計表-這是更有用地寫道.
56. 會話數據存儲在緩存(memcache)的而不是MySQL中 - 緩存許可主動主動填值的,並阻攔您創立難以讀取和寫入到MySQL的時空數據.
57.存儲可變長度的字符串時應用VARCHAR而不是CHAR - 節儉空間,由於固定長度的CHAR,而VARCHAR長度不固定(UTF8不受此影響).
58. 慢慢停止形式的變更 - 一個小的變更,可以有偉大的影響.
59.在開辟情況中測試一切形式,反應臨盆變更.
60. 不要隨便更改你的設置裝備擺設文件中的值,它可以發生災害性的影響.
61. 有時刻,在MySQL的configs少等於多.
62.有疑問時應用一個通用的MySQL設置裝備擺設文件.
查詢優化:
63. 應用慢查詢日記去發明慢查詢。
64. 應用履行籌劃去斷定查詢能否正常運轉。
65. 老是去測試你的查詢看看能否他們運轉在最好狀況下 –一朝一夕機能總會變更。
66. 防止在全部表上應用count(*),它能夠鎖住整張表。
67. 使查詢堅持分歧以便後續類似的查詢可使用查詢緩存。
68. 在恰當的情況下應用GROUP BY而不是DISTINCT。
69. 在WHERE, GROUP BY和ORDER BY子句中應用有索引的列。
70. 堅持索引簡略,不在多個索引中包括統一個列。
71. 有時刻MySQL會應用毛病的索引,關於這類情形應用USE INDEX。
72. 檢討應用SQL_MODE=STRICT的成績。
73. 關於記載數小於5的索引字段,在UNION的時刻應用LIMIT不是是用OR.
74. 為了 防止在更新前SELECT,應用INSERT ON DUPLICATE KEY或許INSERT IGNORE ,不要用UPDATE去完成。
75. 不要應用 MAX,應用索引字段和ORDER BY子句。
76. 防止應用ORDER BY RAND().
77。LIMIT M,N現實上可以減緩查詢在某些情形下,有控制地應用。
78。在WHERE子句中應用UNION取代子查詢。
79。關於UPDATES(更新),應用 SHARE MODE(同享形式),以避免獨有鎖。
80。在從新啟動的MySQL,記得來暖和你的數據庫,以確保您的數據在內存和查詢速度快。
81。應用DROP TABLE,CREATE TABLE DELETE FROM從表中刪除一切數據。
82。最小化的數據在查詢你須要的數據,應用*消費年夜量的時光。
83。斟酌耐久銜接,而不是多個銜接,以削減開支。
84。基准查詢,包含應用辦事器上的負載,有時一個簡略的查詢可以影響其他查詢。
85。當負載增長您的辦事器上,應用SHOW PROCESSLIST檢查慢的和有成績的查詢。
86。在開辟情況中發生的鏡像數據中 測試的一切可疑的查詢。
MySQL 備份進程:
87. 從二級復禮服務器長進行備份。
88. 在停止備份時代停滯復制,以免在數據依附和外鍵束縛上湧現紛歧致。
89. 完全停滯MySQL,從數據庫文件停止備份。
90. 假如應用 MySQL dump停止備份,請同時備份二進制日記文件 – 確保復制沒有中止。
91. 不要信賴LVM 快照 – 這極可能發生數據紛歧致,未來會給你帶來費事。
92. 為了更輕易停止單表恢復,以表為單元導出數據 – 假如數據是與其他表隔離的。
93. 當應用mysqldump時請應用 –opt。
94. 在備份之前檢討和優化表。
95. 為了更快的停止導入,在導入時暫時禁用外鍵束縛。
96. 為了更快的停止導入,在導入時暫時禁用獨一性檢測。
97. 在每次備份後盤算數據庫,表和索引的尺寸,以便更夠監控數據尺寸的增加。
98. 經由過程主動調劑劇本監控復制實例的毛病和延遲。
99. 按期履行備份。
100. 按期測試你的備份。
最初 101: 履行MySQL 監控: Monitis Unveils The World's First Free On-demand MySQL Monitoring.
原文鏈接:http://blog.monitis.com/index.php/2011/07/12/101-tips-to-mysql-tuning-and-optimization/
譯文鏈接:http://www.oschina.net/translate/101-tips-to-mysql-tuning-and-optimization