renhao 2011/11/30
red hat enterprise linux server release 5.4 (tikanga)
elf 32-bit lsb executable, intel 80386, version 1 (sysv), for gnu/linux 2.6.9, dynamically linked (uses shared libs), for gnu/linux 2.
6.9, stripped
32位linux伺服器，單獨作為mysql伺服器使用。
系統使用的是mysql5.1，最新的mysql5.5較之老版本有了大幅改進。主要體現在以下幾個方面：
1） 預設儲存引擎更改為innodb
innodb作為成熟、高效的事務引擎，目前已經廣泛使用，但mysql5.1之前的版本預設引擎均為myisam，此次mysql5.5終於將預設資料庫儲存引擎改為innodb，並且引進了innodb plugin 1.
0.7。此次更新對資料庫的好處是顯而易見的：
innodb的資料恢復時間從過去的乙個甚至幾個小時，縮短到幾分鐘(innodb plugin 1.0.7，innodb plugin 1.
1， 恢復時採用紅-黑樹)。innodb plugin 支援資料壓縮儲存，節約儲存，提高記憶體命中率，並且支援adaptive flush checkpoint, 可以在某些場合避免資料庫出現突發性能瓶頸。
multi rollback segments： 原來innodb只有乙個segment，同時只支援1023的併發。現已擴充到128個segments，從而解決了高併發的限制。
2） 多核效能提公升
metadata locking (mdl) framework替換lock_open mutex (lock)，使得mysql5.1及過去版本在多核心處理器上的效能瓶頸得到解決。
3） 制功能(replication)加強
過去的非同步複製方式意味著極端情況下的資料風險，mysql5.5將首次支援半同步(semi-sync replication)在mysql的高可用方案中將產生更多更加可靠的方案。
4） 增強表分割槽功能
mysql 5.5的分割槽更易於使用的增強功能，以及truncate partition命令都可以為管理和維護資料庫節省大量的時間，並且具有更加靈活高效的分割槽方式。
系統所用cpu是單個4核cpu。對於cpu密集的負載，mysql通常從更快的cpu中獲益，而不是更多cpu。mysql5.
1的架構對多cpu的擴充套件性不好，並且mysql不能在多個cpu上並行地執行某個查詢，因此在對於單個cpu進行密集的查詢時，cpu速度限制了響應時間。為了實現低延遲，即快速響應時間，需要快速的cpu，因為單個查詢只能使用乙個cpu。值得注意的是，mysql5.
5在多核心處理器上的效能有了很大的提公升。另外，mysql在64位架構上工作得更好，比32位架構更能有效地使用大量記憶體。
儘管本系統使用的是32位作業系統，cpu執行在32位模式下，但它仍支援64位計算。（cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l）
系統的磁碟空間目前沒有壓力。
記憶體總大小為4g，只供作業系統和資料庫使用。
資料庫addb共有339張表：其中innodb表303張，myisam表34張，memory表2張。
innodb資料檔案ibdata1大小為30138mb，一周後ibdata1大小為30234mb，
myisam資料檔案（包括表結構、索引及資料）總大小約為1642mb，一周後約為1639mb。可以看出，資料庫的資料量較穩定，innodb資料檔案增加了約106mb，總大小一周內沒有大的變化。myisam表中，值得注意的是表terminalalarm_bak，該錶總大小約為1623mb，佔整個myisam表總大小比重近99%。
二進位制日誌單個檔案大小為1gb，二進位制日誌檔案總大小接近20gb。
伺服器某時間點非精確值：
觀察系統中資料量很大且未進行表分割槽的innodb表
● adrotateresultdetail_fail的資料量達到4千萬，createtime列是datatime型別，且有索引，意味著存在以該列為查詢條件或關聯條件查詢的需求，因此可以在該列上以自然月份進行表分割槽。
● terminalalarm的資料量也突破千萬，alarmtime列是datatime型別，且有索引，意味著存在以該列為查詢條件或關聯條件查詢的需求，因此可以在該列上以自然月份進行表分割槽。在事件ev_terminalalarm中會查詢該錶，若進行表分割槽，也能一定程度上提高事件的執行效率。
● terminalalarminfo表僅自增列有索引，主要用於儲存資料，可不用分割槽。
● terminallogin表的logintime列是datatime型別，且有索引，意味著存在以該列為查詢條件或關聯條件查詢的需求，因此可以在該列上以自然月份進行表分割槽。
● adplayinfo_bak表存在多個以int型別為索引的列，根據實際業務情況選擇查詢頻率高且能以範圍值來分割槽的整型列對該錶進行分割槽。
● adrotateresultdetail的createtime列是datatime型別，且有索引，意味著存在以該列為查詢條件或關聯條件查詢的需求，因此可以在該列上以自然月份進行表分割槽。
● upfile_bak表僅自增列有索引，若存在查詢或者統計業務則可以createtime列進行分割槽，若該錶沒有查詢方面業務可不必進行分割槽。
除去配置引數等屬性表，對於資料量大且不斷遞增的業務資料表，最直接的辦法可以按照時間字段進行分割槽，或是根據查詢業務來選擇合適的列進行表分割槽和建立索引，這樣能夠有效提高儲存和查詢效率。
記錄查詢：普通日誌log、慢速日誌log_slow_queries
mysql有兩種查詢日誌：普通日誌和慢速日誌，它們都會記錄查詢。普通日誌記錄了伺服器接收到的每乙個查詢，也包含了沒有被執行的查詢，比如因為錯誤而未被執行的查詢，還有一些非查詢事件，比如連線和斷開連線，普通日誌不包含執行時間或其他只有在查詢結束之後才能得到的資訊。
相反，慢速日誌只包含了已經執行過的查詢，如果是啟動狀態，它記錄了執行時間超過了特定長度的查詢。兩種日誌都有助於分析，但是慢速日誌更有利找到效能較慢的查詢。
乙個相關配置是log_queries_not_using_indexes，它使伺服器把沒有使用索引的查詢記錄到慢速查詢日誌中，無論它們執行速度有多快。儘管開啟慢速日誌相對於執行慢速查詢來說，通常只增加了很少的時間，但是如果沒有使用索引的查詢非常快，例如從小資料量表中查詢，這樣就會記錄它們可能導致伺服器變慢，甚至還會使用大量的磁碟空間，慢速日誌也許就會被那些快速高效的查詢塞滿。
慢查詢日誌可以用來找到執行時間長的查詢，可以用於優化。慢日誌開啟後，通過設定long_query_time來配置記錄查詢超過的指定時間，預設值為10秒，根據系統的負載和效能要求進行設定(set global long_query_time = …)。
檢查又長又慢的查詢日誌會很麻煩，可以使用mysqldumpslow命令獲得日誌中顯示的查詢摘要來處理慢查詢日誌。系統兩種日誌都沒有開啟，可以在需要的時候開啟慢速日誌來幫助分析效能較慢的查詢。具體實施參考mysql手冊。
需要注意的是查詢在日誌中只出現一次並不意味著它是乙個不好的查詢，也不意味將來也會慢，查詢時快是慢有多種原因：
1） 表也許被鎖定，導致查詢處於等待狀態；
2） 資料或索引也許沒有被快取在記憶體中；
3） 或者正在進行批處理大量的資料，使得磁碟i/o變慢；
4） 伺服器可能同時在執行其他的查詢，影響了當前查詢的效率。
因此，只能把慢速查詢日誌看成調優工作的一部分，可以用它來找到可疑的查詢，但需要對它們進行仔細地排查和分析。
◆ 啟用系統慢速日誌，分析查詢效能慢的時候可以觀察該日誌資訊。
qcache_hits
com_select
qcache_inserts
檢查是否從查詢快取中受益的最直接辦法就是檢查快取命中率。它是提供快取提供的查詢結果的數量，而不是伺服器執行的數量。當伺服器收到select語句的時候，qcache_hits和com_select這兩個變數會根據查詢快取的情況進行遞增。
查詢快取命中率的計算公式：qcache_hits/(qcache_hits+com_select)，根據公式計算得出查詢快取命中率為7%。初看上去該命中率很低，但注意到com_select等於qcache_inserts + qcache_not_cache + 許可權檢查錯誤的總和，即這個比率中包含了快取失效的因素，而對於資料變更頻繁的系統來說，快取是及其容易失效的，表的任何時刻的資料插入或更新都會使該錶的快取失效，所以本系統快取的插入率很低，拋開失效的快取因素，用如下公式計算快取命中率：
qcache_hits/(qcache_hits+qcache_inserts)= 84.87%，該比值要好得多，意味著大部分的查詢都命中了快取，換一種說法就是仍有一小部分查詢沒有被快取。沒被快取和快取失效是兩個概念，分別計數，但都會引起com_select的值增加。
命中率要多少才好，這視情況而定，因為對於每乙個查詢，不執行它所節約的資源遠大於快取中儲存結果以及讓查詢失效的開銷，如果快取命中代表了開銷最大的查詢，那麼即使很低的命中率也是有好處的。快取可能會因為碎片、記憶體不足或資料改變而失效。如果已經給快取分配了足夠的記憶體，並且把query_cache_min_res_unit調整到了合適的值，那麼大部分快取失效都應該是由資料改變而引起的。
com_update, com_delete等的值知道有多少查詢修改了資料，也可以通過檢查qcache_lowmen_prunes的值了解有多少查詢因為記憶體不足而失效。
資料庫效能優化解決方案
資料庫能優化方案是對使用者提出的k3系統在使用過程中遇到的效能問題，從sql server調整，硬體調整這兩方面提出了效能優化解決方案。1 sql server調整 當使用者使用k3系統一段時間以後，發現系統的響應時間越來越長。這種情形往往是由於賬套資料庫缺乏維護引起的。缺乏維護的資料庫會存在過多地...
Mysql中文亂碼解決方案
用odi從oracle資料庫向mysql資料庫進行資料整合時，只要字段內容為中文均無法正確整合，顯示為亂碼 英文和數字可以正確整合。1.檢查伺服器上oracle資料庫的字符集，sql語句為select from nls database parameters，其 於props 是表示資料庫的字符集,...
匯入mysql出現亂碼解決方案
方法一 通過增加引數 default character set utf8 解決亂碼問題 mysql u root p password path to import file default character set utf8 方法二 在命令列匯入亂碼解決 1.use database name...