影響MySQL數據庫性能主要有哪些因素

本文主要給大家簡單講講影響MySQL數據庫性能主要有哪些因素，相關專業術語大家可以上網查查或者找一些相關書籍補充一下，這里就不涉獵了，我們就直奔主題吧，希望影響MySQL數據庫性能主要有哪些因素這篇文章可以給大家帶來一些實際幫助。

影響數據庫性能的因素：

很多sql性能是慢查詢造成的

目前的mysql版本中，并不能支持多cpu并發運算，就是說一個sql只能用到一個cpu。常用qps、tps衡量cpu處理效率

        qps/tps：每秒處理的查詢量

max_connections可以根據情況設置大一些。如果實際超出這個數，會造成要用的云服務器無法連接數據庫，會出現500錯誤

大表帶來的問題：

（一般滿足上述兩條的表會造成性能影響）

大表會產生慢查詢，讓數據庫很難在一定時間內過濾出所需要的數據

然而，分庫分表要消耗大量人力物力，還要冒著影響后端業務的風險，不一定適合所有公司。還可以用另一種方式對大表進行處理：

        大表歷史數據歸檔（盡量減少對前后端業務的影響）（比如歷史訂單）

        難點：

                歸檔時間點的選擇

                如何進行歸檔操作（對大表的操作，輕則主從延遲，重則大量阻塞影響業務訪問）

大事務帶來的問題：

        事務的特點：

                原子性：不可分割的最小單元，要么全成功，要么全失敗

                一致性：從一種一致性狀態轉換到另一種一致性狀態，在事務開始之前和事務結束后數據中數據的完整性沒有被破壞（比如，轉賬前和轉賬后的總金額一致）

                隔離性：要求一個事務對數據庫中的數據的修改，在未提交完成前對于其他事務是不可見的

                持久性：  一旦事務提交，則其所有的修改就會永久保存到數據庫中。此時即使系統崩潰，已經提交的修改數據也不會丟失

        什么是大事務：

                定義：運行時間較長，操作的數據比較多的事務

                風險：

                        鎖定太多的數據，造成大量的阻塞和鎖超時

                        回滾所需時間比較長（回滾過程中仍然會被鎖定）

                        執行時間長，容易造成主從延遲（如果延遲1個小時，這就...）

        如何處理大事務：

                1.避免一次處理太多數據

                2.移出不必要在事務中的select操作

新版本的mysql對多核cpu支持改善了

centos參數優化：

                （上面的配置可以相應調大）

                        （上面的會決定tcp連接回收速度）

                        （上面的會決定tcp連接、接收、發送緩沖區大小的默認值、最大值。應該相應調大些）

                        （上面參數用于減少失效連接所占用的tcp系統資源的數量，加快資源回收的效率。應該改小些）

mysql參數：

        ......

基準測試：

        基準測試不同于壓力測試，壓力測試通常是真實數據，基準測試的數據由測試工具生成，只是簡化的壓力測試

                shell腳本寫測試程序

                運行保存測試結果

                圖標展示

                 測試工具：

                        ab、mysqlslap、sysbench......

適當反范式，適當增加冗余提高查詢效率

        （范式化提高了寫的性能，但降低了讀的性能）

        （同一個表中可以屬于同一個索引的，在不同表中就無法放到同一個索引了）

        （反范式化在修改數據的時候會需要更改多個地方）

數據類型的選擇：

        注意：長度是字符，不是字節

        （mysql為了更有效的優化查詢，在內存中，對字符串使用的是固定的寬度，特別是使用隱式的內存零時表的時候，若把varchar寬度定義得更長，會消耗更多的內存）

        （date只保留到日期部分，不保留時分秒。比如存儲生日）

        （mysql提供了足夠多的時間存儲類型，不要用字符串類型存儲日期、時間數據）

mysql復制：

        web云服務器訪問過大后，可以通過增加web云服務器來解決。只要程序完全一樣，就可以很好的分擔這些負擔。但數據庫就不同了！

        mysql的復制是異步的，在同一時間點上，備庫和主庫的數據存在不一樣的情況，并且無法消除主庫和備庫之間的延遲

        （復制并不能代替備份。復制無法對錯誤操作刪除更改的數據進行恢復）

        binlog日志中的記錄都是已經執行成功的，回滾、由于錯誤執行不成功的事務是不會被記錄的

表的復制，未完待續...

索引優化：

        （覆蓋索引之所以能提高查詢性能，因為索引大小比行的大小小得多，如果索引本身很大，就沒有覆蓋索引的必要了，特別是對select *的查詢，不可能有索引覆蓋到所有的列。所以查詢中不能使用太多列）

        覆蓋索引例子：

                （完全可以通過索引來獲取到，使用了覆蓋索引）

                （using where說明不能從索引中獲取索要查的數據，也就是不能用到覆蓋索引，而必須把索引數據先放到內存中，然后進行where條件的過濾）

                （有using index，使用了覆蓋查詢）

        索引排序優化的例子：

                （上面是用索引來排序的。該表是innodb引擎。而同樣的數據結構，若是myisam引擎，extra會顯示using filesort）

                （不管是myisam還是innodb，都沒有用到using filesort）

                （此處用到了using filesort！索引升降序的規則必須和order by升降序規則一致才行，不然無法用到索引列排序）

        （增加了并發性，提高了性能）

        （重復索引完全沒必要，冗余索引有時候是可以有的）

sql優化：

        獲取有性能問題的sql：

        設置慢查詢：

                （long_query_time單位秒）

                然而，慢查詢不大可能自己一個個看，還是要借助工具：

        實時獲取有性能問題的sql：

        sql查詢的步驟：

        如何確定查詢處理各個階段所消耗的時間：

        特定sql的優化：

                （如果表中數據很多，count()查詢會很慢，可以再建立一個表，用于匯總：）

                可以每天凌晨的什么時候進行count(*)的統計，并寫入到匯總表。今天要查詢的話，就把匯總表中的數據和今天的數據進行union all

影響MySQL數據庫性能主要有哪些因素就先給大家講到這里，對于其它相關問題大家想要了解的可以持續關注我們的行業資訊。我們的板塊內容每天都會捕捉一些行業新聞及專業知識分享給大家的。