查詢速度慢的原因很多，常見如下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
可以通過如下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要.
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位
5、提高網速;
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍（虛擬內存大小設置的一半）。
7、增加伺服器CPU個戚鎮陵數;但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT，DELETE還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全旅手文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件'分區視圖'）
a、在實現分區視圖之前，必須先水平分區表
b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程高戚序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。 在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
12、Commit和rollback的區別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) commit trans 或者將動態SQL 寫成函數或者存儲過程。
13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
14、SQL的注釋申明對執行沒有任何影響
② 關於DB2資料庫的參數調優技巧
在開始前 請關閉IBM目錄伺服器 將上下文切換到IBM目錄伺服器DB 實例擁有者 一般是ldapdb 用戶 比如
在Unix系統里 輸入
su ldapdb
在Windows系統里 輸入
db cmdset DB INSTANCE=ldapdb
為了調節DB 參數 運行db tunings sh腳本 你可以在這里下載:// sofare ibm /ibmdl/pub/sofare/tivoli_support/misc/Security/AMeB/_am /tuning_guide_scripts tar
或者通過ftp地址
ftp://ftp sofare ibm /sofare/tivoli_support/misc/Security/AMeB/am /tuning_guide_scripts tar
Web頁面需要注冊用戶名和密碼
這個腳本的文件系統擁有者必須是DB 實例擁有者 一般就是ldapdb 用戶 文件系統組應該和實例擁有者相同(一般是dbsysadm) 腳本必須在DB 實例擁有者的上下文中使用
腳本中的ibmdefaultbp和ldapbp參數控制著DB 的緩沖池 db _turnings sh腳本 設置了DB 緩沖池的建議大小 其他一些可選的設置在腳本的注釋里寫明了 IBM目錄伺服器的性能隨著DB 緩沖池的增長而提高 然而在大多數情況下 通過這樣的參數調節方式 你可以預見不超過 %的性能提高
DB 緩沖池是DB 緩存數據表和索引的地方 DB 用戶使用索引來在查詢時迅速找到該獲取哪個錶行項 需要更多信息 請參考IBM Directory Server Tuning Guide
顯示和驗證當前設置
輸入如下命令來顯示當前的DB 參數調節設置的結果
db get database configuration for ldapdb |
egrep DBHEAP|SORTHEAP|MAXLOCKS|MINMIT|UTIL_HEAP_SZ|APPLHEAPSZ
db connect to ldapdb
db select bpname npages pagesize from syscat bufferpools
db terminate
如果某個堆配置參數過低 就將出現一些功能性的問題 輸入如下命令來顯示當前的堆參數設置
db get db cfg for ldapdb | grep HEAP
下面是一個使用了推薦值的多種堆參數的輸出例子顯示
Database heap ( KB) (DBHEAP) =
Utilities heap size ( KB) (UTIL_HEAP_SZ) =
Max appl control heap size ( KB) (APP_CTL_HEAP_SZ) =
Sort list heap ( KB) (SORTHEAP) =
SQL statement heap ( KB) (STMTHEAP) =
Default application heap ( KB) (APPLHEAPSZ) =
Statistics heap size ( KB ) (STAT_HEAP_SZ) =
如果一個堆參數小於最小值 輸入如下命令將其增大到最小值
db update db cfg for ldapdb using parm_name parm_value
這里parm_name是上文輸出中的第三欄的字樣(無括弧) parm_value是最後一欄的值
如果堆參數設置的過高或者過低 IBM的目錄伺服器都會以失效來提示出現了問題 在這種情況下 需要查看諸如IBM Directory Server V (IDS )的cli error文件或者IBM Tivoli Directory Server V (IDS v )的db cli log或者其他一些文件 在IDS v 系統中 該文件預設目錄在Solaris的/var/ldap/和AIX的/tmp中 在IDS v 和後來系統中 Solaris和AIX的預設目錄都是/var/ldap
注意db look能夠在一條命令下提供關於資料庫及其配置的足夠多的信息 例子如下
db look d ldapdb u ldapdb p o output_file
output_file是存儲結果的文件位置
關於IBM目錄伺服器運行的警告
DB 參數調節使用了db terminate 如果當該命令發出 IBM目錄伺服器slapd或ibmslapd進程在運行 它將阻止伺服器的部分功能 所有緩存的搜索看起來反應正常 其他的搜索將會簡單的變為無結果或者出現錯誤信息 恢復功能將會重啟IBM目錄伺服器 因此最好是在調節DB 參數時關閉IBM目錄伺服器
關於緩沖池內存使用的警告
如果任何的緩沖池被設置過高 DB 將會因為缺少足夠內存而無法啟動 如果出現該問題將會有一個核心轉儲的文件 但是通常沒有錯誤信息
在AIX系統里 系統錯誤日誌將會報告一個內存分配失敗 查看這個日誌請輸入
errpt a | more
使用太大的緩沖池大小來恢復一個被分在系統里的資料庫將會導致恢復失敗 查看//publib boulder ibm /infocenter/tivihelp/v r /topic/ ibm itame doc_ /am _perftune #idtrouble來解決這個問題
如果DB 因為緩沖池過大而無法啟動 請重新調節DB 參數
關於MINMIT的警告
lishixin/Article/program/DB2/201311/11229
③ 資料庫如何優化
body{
line-height:200%;
}
如何優化MySQL資料庫
當MySQL資料庫邂逅優化，它有好幾個意思，今天我們所指的是性能優化。
我們究竟該如何對MySQL資料庫進行優化呢？下面我就從MySQL對硬體的選擇、Mysql的安裝、my.cnf的優化、MySQL如何進行架構設計及數據切分等方面來說明這個問題。
1.伺服器物理硬體的優化
1)磁碟(I/O)，MySQL每一秒鍾都在進行大量、復雜的查詢操作，對磁碟的讀寫量可想而知，所以推薦使用RAID1+0磁碟陣列，如果資金允許，可以選擇固態硬碟做RAID1+0；
2)cpu對Mysql的影響也是不容忽視的，建議選擇運算能力強悍的CPU。
2.MySQL應該採用編譯安裝的方式
MySQL資料庫的線上環境安裝，我建議採取編譯安裝，這樣性能會較大的提升。
3.MySQL配置文件的優化
1)skip
-name
-resolve，禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間；
2)back_log
=
384，back_log指出在MySQL暫時停止響應新請求之前，短時間內的多少個請求可以被存在堆棧中，對於Linux系統而言，推薦設置小於512的整數。
3)如果key_reads太大，則應該把my.cnf中key_buffer_size變大，保持key_reads/key_read_requests至少在1/100以上，越小越好。
4.MySQL上線後根據status狀態進行適當優化
1)打開慢查詢日誌可能會對系統性能有一點點影響，如果你的MySQL是主-從結構，可以考慮打開其中一台從伺服器的慢查詢日誌，這樣既可以監控慢查詢，對系統性能影響也會很小。
2)MySQL伺服器過去的最大連接數是245，沒有達到伺服器連接數的上限256，應該不會出現1040錯誤。比較理想的設置是：Max_used_connections/max_connections
*
100%
=85%
5.MySQL資料庫的可擴展架構方案
1)MySQL
cluster，其特點為可用性非常高，性能非常好，但它的維護非常復雜，存在部分Bug;
2)DRBD磁碟網路鏡像方案，其特點為軟體功能強大，數據可在底層塊設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。
④ 資料庫性能優化有哪些措施
1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。
資料庫(Database)是按照數據結構來組織、存儲和管理數據的倉庫，它產生於距今六十多年前，隨著信息技術和市場的發展，特別是二十世紀九十年代以後，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。資料庫有很多種類型，從最簡單的存儲有各種數據的表格到能夠進行海量數據存儲的大型資料庫系統都在各個方面得到了廣泛的應用。
在信息化社會，充分有效地管理和利用各類信息資源，是進行科學研究和決策管理的前提條件。資料庫技術是管理信息系統、辦公自動化系統、決策支持系統等各類信息系統的核心部分，是進行科學研究和決策管理的重要技術手段。
在經濟管理的日常工作中，常常需要把某些相關的數據放進這樣的「倉庫」，並根據管理的需要進行相應的處理。
例如，企業或事業單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個資料庫。有了這個"數據倉庫"我們就可以根據需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內的職工人數等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。此外，在財務管理、倉庫管理、生產管理中也需要建立眾多的這種"資料庫"，使其可以利用計算機實現財務、倉庫、生產的自動化管理。
(4)資料庫伺服器配置文件性能調優擴展閱讀
資料庫，簡單來說是本身可視為電子化的文件櫃--存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。
資料庫指的是以一定方式儲存在一起、能為多個用戶共享、具有盡可能小的冗餘度的特點、是與應用程序彼此獨立的數據集合。
在經濟管理的日常工作中，常常需要把某些相關的數據放進這樣的"倉庫"，並根據管理的需要進行相應的處理。
例如，企業或事業單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個資料庫。有了這個"數據倉庫"我們就可以根據需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內的職工人數等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。此外，在財務管理、倉庫管理、生產管理中也需要建立眾多的這種"資料庫"，使其可以利用計算機實現財務、倉庫、生產的自動化管理。
⑤ oracle資料庫的性能優化有哪些方法
你最好買一本專門講ORACLE性能優化的書，好好看看\x0d\x0a1、調整資料庫伺服器的性能\x0d\x0aOracle資料庫伺服器是整個系統的核心，它的性能高低直接影響整個系統的性能，為了調整Oracle資料庫伺服器的性能，主要從以下幾個方面考慮： \x0d\x0a1.1、調整操作系統以適合Oracle資料庫伺服器運行\x0d\x0aOracle資料庫伺服器很大程度上依賴於運行伺服器的操作系統，如果操作系統不能提供最好性能，那麼無論如何調整，Oracle資料庫伺服器也無法發揮其應有的性能。 \x0d\x0a1.1.1、為Oracle資料庫伺服器規劃系統資源 \x0d\x0a據已有計算機可賀察裂用資源, 規劃分配給Oracle伺服器資源原則是：盡可能使Oracle伺服器使用資源最大化,特別在Client/Server中盡量讓伺服器上所有資源都來運行Oracle服務。 \x0d\x0a1.1.2、調整計算機系統中的內存配置 \x0d\x0a多數操作系統都用虛存來模擬計算機上更大的內存，它實際上是硬碟上的一定的磁碟空間。當實際的內存空間不能滿足應用軟體的要求時，操作系統就將用這部分的磁碟空間對內存中的信息進行頁面替換，這將引起大量的磁碟I/O操作，使整個伺服器的性能下降。為了避免過多地使用虛存，應加大計算機的內存。 \x0d\x0a1.1.3、為Oracle資料庫伺服器設置操作系統進程優先順序 \x0d\x0a不要在操作系統中調整Oracle進程的優先順序，因為在Oracle資料庫系統中，所有的後台和前台資料庫伺服器進程執行的是同等重要的工作，需要同等的優先順序。所以在安裝時，讓所有的資料庫伺服器進程都使用預設的優先順序運行。 \x0d\x0a1.2、調整內存分配\x0d\x0aOracle資料庫伺服器保留3個基本的內存高速緩存，分別對應3種不同類型的數據：庫高速緩存，字典高速緩存和緩沖區高速緩存。庫高速緩存和字典高速緩存一起構成共享池，共享池再加上緩沖區高速緩存便構成了系統全程區(SGA)。SGA是對資料庫數據進行快速訪問的一個系統全程區，若SGA本身需要頻繁地進行釋放、分配，則不能達到快速訪問數據的目的，因此應把SGA放在主存中，不要放在虛擬內存中。內存的調整主要是指調整組成SGA的內存結構沒斗的大小來提高系統性能，由於Oracle資料庫伺服器的內存結構需求與應用密切相關，所以內存結構的調整應在磁碟I/O調整之前進行。 \x0d\x0a1.2.1、庫緩沖區的調整 \x0d\x0a庫緩沖區中包含私用和共享SQL和PL/SQL區，通過比較庫緩沖區的命中率決定它的大小。要調整庫緩沖區，必須首先了解該庫緩沖區的活動情況，庫緩沖區的活動統計信息保留在動態性能表v$librarycache數據字典中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache; \x0d\x0a \x0d\x0aPins列給出SQL語句，PL/SQL塊及被訪問對象定義的總次數；Reloads列給出SQL 和PL/SQL塊的隱式分析或對象定義重裝載時在庫程序緩沖區中發生的錯誤。如果sum(pins)/sum(reloads) ≈0，則庫緩沖區的命中率合適；若sum(pins)/sum(reloads)>1, 則需調整初始化參數 shared_pool_size來重新調整分配給共享禪閉池的內存量。 \x0d\x0a1.2.2、數據字典緩沖區的調整 \x0d\x0a數據字典緩沖區包含了有關資料庫的結構、用戶、實體信息。數據字典的命中率，對系統性能影響極大。數據字典緩沖區的使用情況記錄在動態性能表v$librarycache中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache; \x0d\x0a \x0d\x0aGets列是對相應項請求次數的統計；Getmisses 列是引起緩沖區出錯的數據的請求次數。對於頻繁訪問的數據字典緩沖區，sum(getmisses)/sum(gets)<10%～15%。若大於此百分數，則應考慮增加數據字典緩沖區的容量，即需調整初始化參數shared_pool_size來重新調整分配給共享池的內存量。 \x0d\x0a1.2.3、緩沖區高速緩存的調整 \x0d\x0a用戶進程所存取的所有數據都是經過緩沖區高速緩存來存取，所以該部分的命中率，對性能至關重要。緩沖區高速緩存的使用情況記錄在動態性能表v$sysstat中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是請求數據緩沖區中讀的總次數。physical reads的值是請求數據時引起從盤中讀文件的次數。從緩沖區高速緩存中讀的可能性的高低稱為緩沖區的命中率，計算公式： \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\x0a \x0d\x0a如果Hit Ratio<60%～70%，則應增大db_block_buffers的參數值。db_block_buffers可以調整分配給緩沖區高速緩存的內存量，即db_block_buffers可設置分配緩沖區高速緩存的數據塊的個數。緩沖區高速緩存的總位元組數=db_block_buffers的值*db_block_size的值。db_block_size 的值表示數據塊大小的位元組數，可查詢 v$parameter 表： \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size'; \x0d\x0a \x0d\x0a在修改了上述資料庫的初始化參數以後，必須先關閉資料庫，在重新啟動資料庫後才能使新的設置起作用。
⑥ 如何對資料庫性能進行優化
1.資料庫I/O方面硬體性能
最有可能影響性能的是磁碟和網路吞吐量。解決辦法：
擴大虛擬內存，並保證有足夠可以擴充的空間
把資料庫伺服器上的不必要服務關閉掉
把SQL資料庫伺服器的吞吐量調為最大
若對該表的查詢頻率比較高，則建立索引。
分區（如MySQL，按時間分區）
盡量使用固定長度欄位和限制欄位長度（如 varchar(10)）優勢：
降低物理存儲空間
提高資料庫處理速度
附帶校驗資料庫是否合法功能優化sql語句，減少比較次數
限制返回條目數(mysql中使用limit)
盡可能的少創造對象
合理擺正系統設計的位置。大量數據操作，和少量數據操作一定是分開的。
合理利用內存，有的數據要緩存。讓數據流起來，而不是全部讀到內存再處理，而是邊讀取邊處理。
2.調整資料庫
3.使用存儲過程
應用程序的實現過程中，能夠採用存儲過程實現的對資料庫的操作盡量通過存儲過程來實現。
因為存儲過程是存放在資料庫伺服器上的一次性被設計、編碼、測試，並被再次使用，需要執行該任務的應用可以簡單地執行存儲過程，並且只返回結果集或者數值。
這樣不僅可以使程序模塊化，同時提高響應速度，減少網路流量，並且通過輸入參數接受輸入，使得在應用中完成邏輯的一致性實現。
4.SQL語句方面
建立查詢條件索引僅僅是提高速度的前提條件，響應速度的提高還依賴於對索引的使用。不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。
5.Java方面
⑦ 如何優化資料庫的性能
--資料庫性能調優
--1.聚集索引、主鍵
--2.盡量不要用臨時表
--3.多多使用事務
--4.表設計要規范
--5.不要使用游標
--6.避免死鎖
--7.不要打開大數據集
--8.最好不要select *
--9.不要使用text數據類型，用varchar
--10.不要給諸如「性別」列創建索引
--11.不要使用Insert插入大量的數據
--12.盡量用join代替where,因為where進行全表搜索
⑧ MySQL性能調優 – 你必須了解的15個重要變數
前言:
MYSQL 應該是最流行了 WEB 後端資料庫。雖然 NOSQL 最近越來越多的被提到，但是相信大部分架構師還是會選擇 MYSQL 來做數據存儲。本文作者總結梳理MySQL性能調優的15個重要變數，又不足需要補充的還望大佬指出。
1.DEFAULT_STORAGE_ENGINE
如果你已經在用MySQL 5.6或者5.7，並且你的數據表都是InnoDB，那麼表示你已經設置好了。如果沒有，確保把你的表轉換為InnoDB並且設置default_storage_engine為InnoDB。
為什麼？簡而言之，因為InnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲引擎 – 它支持事務，高並發，有著非常好的性能表現(當配置正確時)。這里有詳細的版本介紹為什麼
2.INNODB_BUFFER_POOL_SIZE
這個是InnoDB最重要變數。實際上，如果你的主要存儲引擎是InnoDB，那麼對於你，這個變數對於MySQL是最重要的。
基本上，innodb_buffer_pool_size指定了MySQL應該分配給InnoDB緩沖池多少內存，InnoDB緩沖池用來存儲緩存的數據，二級索引，臟數據(已經被更改但沒有刷新到硬碟的數據)以及各種內部結構如自適應哈希索引。
根據經驗，在一個獨立的MySQL伺服器應該分配給MySQL整個機器總內存的80%。如果你的MySQL運行在一個共享伺服器，或者你想知道InnoDB緩沖池大小是否正確設置，詳細請看這里。
3.INNODB_LOG_FILE_SIZE
InnoDB重做日誌文件的設置在MySQL社區也叫做事務日誌。直到MySQL 5.6.8事務日誌默認值innodb_log_file_size=5M是唯一最大的InnoDB性能殺手。從MySQL 5.6.8開始，默認值提升到48M,但對於許多稍繁忙的系統，還遠遠要低。
根據經驗，你應該設置的日誌大小能在你伺服器繁忙時能存儲1-2小時的寫入量。如果不想這么麻煩，那麼設置1-2G的大小會讓你的性能有一個不錯的表現。這個變數也相當重要，更詳細的介紹請看這里。
當然，如果你有大量的大事務更改，那麼，更改比默認innodb日誌緩沖大小更大的值會對你的性能有一定的提高，但是你使用的是autocommit，或者你的事務更改小於幾k，那還是保持默認的值吧。
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
默認下，innodb_flush_log_at_trx_commit設置為1表示InnoDB在每次事務提交後立即刷新同步數據到硬碟。如果你使用autocommit，那麼你的每一個INSERT, UPDATE或DELETE語句都是一個事務提交。
同步是一個昂貴的操作(特別是當你沒有寫回緩存時)，因為它涉及對硬碟的實際同步物理寫入。所以如果可能，並不建議使用默認值。
兩個可選的值是0和2:
* 0表示刷新到硬碟，但不同步(提交事務時沒有實際的IO操作)
* 2表示不刷新和不同步(也沒有實際的IO操作)
所以你如果設置它為0或2，則同步操作每秒執行一次。所以明顯的缺點是你可能會丟失上一秒的提交數據。具體來說，你的事務已經提交了，但伺服器馬上斷電了，那麼你的提交相當於沒有發生過。
顯示的，對於金融機構，如銀行，這是無法忍受的。不過對於大多數網站，可以設置為innodb_flush_log_at_trx_commit=0|2，即使伺服器最終崩潰也沒有什麼大問題。畢竟，僅僅在幾年前有許多網站還是用MyISAM，當崩潰時會丟失30s的數據(更不要提那令人抓狂的慢修復進程)。
那麼，0和2之間的實際區別是什麼？性能明顯的差異是可以忽略不計，因為刷新到操作系統緩存的操作是非常快的。所以很明顯應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數據，因為數據已經在OS緩存，最終還是會同步到硬碟的。
5.SYNC_BINLOG
已經有大量的文檔寫到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關系，下面我們來簡單的介紹下：
a) 如果你的伺服器沒有設置從伺服器，而且你不做備份，那麼設置sync_binlog=0將對性能有好處。
b) 如果你有從伺服器並且做備份，但你不介意當主伺服器崩潰時在二進制日誌丟失一些事件，那麼為了更好的性能還是設置為sync_binlog=0.
c) 如果你有從伺服器並且備份，你非常在意從伺服器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進制日誌將資料庫恢復到特定時間點的能力)，那麼你應該設置innodb_flush_log_at_trx_commit=1，並且需要認真考慮使用sync_binlog=1。
問題是sync_binlog=1代價比較高 – 現在每個事務也要同步一次到硬碟。你可能會想為什麼不把兩次同步合並成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經能合並提交，那麼在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會對性能有很大影響。
6.INNODB_FLUSH_METHOD
將innodb_flush_method設置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應該使用O_DIRECT是當你操作系統不支持時。但如果你運行的是Linux，使用O_DIRECT來激活直接IO。
不用直接IO，雙重緩沖將會發生，因為所有的資料庫更改首先會寫入到OS緩存然後才同步到硬碟 – 所以InnoDB緩沖池和OS緩存會同時持有一份相同的數據。特別是如果你的緩沖池限制為總內存的50%，那意味著在寫密集的環境中你可能會浪費高達50%的內存。如果沒有限制為50%，伺服器可能由於OS緩存的高壓力會使用到swap。
簡單地說，設置為innodb_flush_method=O_DIRECT。
7.INNODB_BUFFER_POOL_INSTANCES
MySQL 5.5引入了緩沖實例作為減小內部鎖爭用來提高MySQL吞吐量的手段。
在5.5版本這個對提升吞吐量幫助很小，然後在MySQL 5.6版本這個提升就非常大了，所以在MySQL5.5中你可能會保守地設置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設置為8-16個緩沖池實例。
你設置後觀察會覺得性能提高不大，但在大多數高負載情況下，它應該會有不錯的表現。
對了，不要指望這個設置能減少你單個查詢的響應時間。這個是在高並發負載的伺服器上才看得出區別。比如多個線程同時做許多事情。
8.INNODB_THREAD_CONCURRENCY
InnoDB有一種方法來控制並行執行的線程數 – 我們稱為並發控制機制。大部分是由innodb_thread_concurrency值來控制的。如果設置為0，並發控制就關閉了，因此InnoDB會立即處理所有進來的請求(盡可能多的)。
在你有32CPU核心且只有4個請求時會沒什麼問題。不過想像下你只有4CPU核心和32個請求時 – 如果你讓32個請求同時處理，你這個自找麻煩。因為這些32個請求只有4 CPU核心，顯然地會比平常慢至少8倍(實際上是大於8倍)，而然這些請求每個都有自己的外部和內部鎖，這有很大可能堆積請求。
下面介紹如何更改這個變數，在mysql命令行提示符執行：
對於大多數工作負載和伺服器，設置為8是一個好開端，然後你可以根據伺服器達到了這個限制而資源使用率利用不足時逐漸增加。可以通過show engine innodb statusG來查看目前查詢處理情況，查找類似如下行：
9.SKIP_NAME_RESOLVE
這一項不得不提及，因為仍然有很多人沒有添加這一項。你應該添加skip_name_resolve來避免連接時DNS解析。
大多數情況下你更改這個會沒有什麼感覺，因為大多數情況下DNS伺服器解析會非常快。不過當DNS伺服器失敗時，它會出現在你伺服器上出現「unauthenticated connections」 ，而就是為什麼所有的請求都突然開始慢下來了。
所以不要等到這種事情發生才更改。現在添加這個變數並且避免基於主機名的授權。
10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX
* innodb_io_capacity：用來當刷新臟數據時，控制MySQL每秒執行的寫IO量。
* innodb_io_capacity_max: 在壓力下，控制當刷新臟數據時MySQL每秒執行的寫IO量
首先，這與讀取無關 – SELECT查詢執行的操作。對於讀操作，MySQL會盡最大可能處理並返回結果。至於寫操作，MySQL在後台會循環刷新，在每一個循環會檢查有多少數據需要刷新，並且不會用超過innodb_io_capacity指定的數來做刷新操作。這也包括更改緩沖區合並（在它們刷新到磁碟之前，更改緩沖區是輔助臟頁存儲的關鍵）。
第二，我需要解釋一下什麼叫「在壓力下」，MySQL中稱為」緊急情況」，是當MySQL在後台刷新時，它需要刷新一些數據為了讓新的寫操作進來。然後，MySQL會用到innodb_io_capacity_max。
那麼，應該設置innodb_io_capacity和innodb_io_capacity_max為什麼呢？
最好的方法是測量你的存儲設置的隨機寫吞吐量，然後給innodb_io_capacity_max設置為你的設備能達到的最大IOPS。innodb_io_capacity就設置為它的50-75%，特別是你的系統主要是寫操作時。
通常你可以預測你的系統的IOPS是多少。例如由8 15k硬碟組成的RAID10能做大約每秒1000隨機寫操作，所以你可以設置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價企業SSD可以做4,000-10,000 IOPS等。
這個值設置得不完美問題不大。但是，要注意默認的200和400會限制你的寫吞吐量，因此你可能偶爾會捕捉到刷新進程。如果出現這種情況，可能是已經達到你硬碟的寫IO吞吐量，或者這個值設置得太小限制了吞吐量。
11.INNODB_STATS_ON_METADATA
如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認值，因為它已經設置正確了。
不過在MySQL 5.5或5.1，強烈建議關閉這個變數 – 如果是開啟，像命令show table status會立即查詢INFORMATION_SCHEMA而不是等幾秒再執行，這會使用到額外的IO操作。
從5.1.32版本開始，這個是動態變數，意味著你不需要重啟MySQL伺服器來關閉它。
12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN & INNODB_BUFFER_POOL_LOAD_AT_STARTUP
innodb_buffer_pool_mp_at_shutdown和innodb_buffer_pool_load_at_startup這兩個變數與性能無關，不過如果你偶爾重啟mysql伺服器(如生效配置)，那麼就有關。當兩個都激活時，MySQL緩沖池的內容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在後台啟動一個線程來載入緩沖池的內容以提高預熱速度到3-5倍。
兩件事：
第一，它實際上沒有在關閉時復制緩沖池內容到文件，僅僅是復製表空間ID和頁面ID – 足夠的信息來定位硬碟上的頁面了。然後它就能以大量的順序讀非常快速的載入那些頁面，而不是需要成千上萬的小隨機讀。
第二，啟動時是在後台載入內容，因為MySQL不需要等到緩沖池內容載入完成再開始接受請求(所以看起來不會有什麼影響)。
從MySQL 5.7.7開始，默認只有25%的緩沖池頁面在mysql關閉時存儲到文件，但是你可以控制這個值 – 使用innodb_buffer_pool_mp_pct，建議75-100。
這個特性從MySQL 5.6才開始支持。
13.INNODB_ADAPTIVE_HASH_INDEX_PARTS
如果你運行著一個大量SELECT查詢的MySQL伺服器(並且已經盡可能優化)，那麼自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內部維護的動態索引，可以提高最常用的查詢模式的性能。這個特性可以重啟伺服器關閉，不過默認下在mysql的所有版本開啟。
這個技術非常復雜，在大多數情況下它會對大多數類型的查詢直到加速的作用。不過，當你有太多的查詢往資料庫，在某一個點上它會花過多的時間等待AHI鎖和閂鎖。
如果你的是MySQL 5.7，沒有這個問題 – innodb_adaptive_hash_index_parts默認設置為8，所以自適應哈希索引被切割為8個分區，因為不存在全局互斥。
不過在mysql 5.7前的版本，沒有AHI分區數量的控制。換句話說，有一個全局互斥鎖來保護AHI，可能導致你的select查詢經常撞牆。
所以如果你運行的是5.1或5.6，並且有大量的select查詢，最簡單的方案就是切換成同一版本的Percona Server來激活AHI分區。
14.QUERY_CACHE_TYPE
如果人認為查詢緩存效果很好，肯定應該使用它。好吧，有時候是有用的。不過這個只在你在低負載時有用，特別是在低負載下大多數是讀取，小量寫或者沒有。
如果是那樣的情況，設置query_cache_type=ON和query_cache_size=256M就好了。不過記住不能把256M設置更高的值了，否則會由於查詢緩存失效時，導致引起嚴重的伺服器停頓。
如果你的MySQL伺服器高負載動作，建議設置query_cache_size=0和query_cache_type=OFF，並重啟伺服器生效。那樣Mysql就會停止在所有的查詢使用查詢緩存互斥鎖。
15.TABLE_OPEN_CACHE_INSTANCES
從MySQL 5.6.6開始，表緩存能分割到多個分區。
表緩存用來存放目前已打開表的列表，當每一個表打開或關閉互斥體就被鎖定 – 即使這是一個隱式臨時表。使用多個分區絕對減少了潛在的爭用。
從MySQL 5.7.8開始，table_open_cache_instances=16是默認的配置。
歡迎做Java的工程師朋友們私信我資料免費獲取免費的Java架構學習資料（裡面有高可用、高並發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）
其中覆蓋了互聯網的方方面面，期間碰到各種產品各種場景下的各種問題，很值得大家借鑒和學習，擴展自己的技術廣度和知識面。
⑨ 如何對mysql伺服器進行調優
1、選取最適用的欄位屬性
MySQL 可以很好的支持大數據量的存取，但是一般說來，資料庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中欄位的寬度設得盡可能小。例如，在定義郵政編碼這個欄位時，如果將其設置為CHAR(255),顯然給資料庫增加了不必要的空間，甚至使用VARCHAR這種類型也是多餘的，因為CHAR(6)就可以很好的完成任務了。同樣的，如果可以的話，我們應該使用MEDIUMINT而不是BIGIN來定義整型欄位。
另外一個提高效率的方法是在可能的情況下，應該盡量把欄位設置為NOT NULL，這樣在將來執行查詢的時候，資料庫不用去比較NULL值。
對於某些文本欄位，例如「省份」或者「性別」，我們可以將它們定義為ENUM類型。因為在MySQL中，ENUM類型被當作數值型數據來處理，而數值型數據被處理起來的速度要比文本類型快得多。這樣，我們又可以提高資料庫的性能。
2、使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL 從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。例如，我們要將客戶基本信息表中沒有任何訂單的客戶刪除掉，就可以利用子查詢先從銷售信息表中將所有發出訂單的客戶ID取出來，然後將結果傳遞給主查詢，如下所示：
DELETE FROM customerinfo
WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，並且寫起來也很容易。但是，有些情況下，子查詢可以被更有效率的連接（JOIN）.. 替代。例如，假設我們要將所有沒有訂單記錄的用戶取出來，可以用下面這個查詢完成：
SELECT * FROM customerinfo
WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
如果使用連接（JOIN）.. 來完成這個查詢工作，速度將會快很多。尤其是當salesinfo表中對CustomerID建有索引的話，性能將會更好，查詢如下：
SELECT * FROM customerinfo
LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo.
CustomerID
WHERE salesinfo.CustomerID IS NULL
連接（JOIN）.. 之所以更有效率一些，是因為 MySQL不需要在內存中創建臨時表來完成這個邏輯上的需要兩個步驟的查詢工作。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL 從 4.0 的版本開始支持 UNION 查詢，它可以把需要使用臨時表的兩條或更多的 SELECT 查詢合並的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證資料庫整齊、高效。使用 UNION 來創建查詢的時候，我們只需要用 UNION作為關鍵字把多個 SELECT 語句連接起來就可以了，要注意的是所有 SELECT 語句中的欄位數目要想同。下面的例子就演示了一個使用 UNION的查詢。
SELECT Name, Phone FROM client
UNION
SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM proct
4、事務
盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯合（UNION）來創建各種各樣的查詢，但不是所有的資料庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設想一下，要把某個數據同時插入兩個相關聯的表中，可能會出現這樣的情況：第一個表中成功更新後，資料庫突然出現意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數據的不完整，甚至會破壞資料庫中的數據。要避免這種情況，就應該使用事務，它的作用是：要麼語句塊中每條語句都操作成功，要麼都失敗。換句話說，就是可以保持資料庫中數據的一致性和完整性。事物以BEGIN 關鍵字開始，COMMIT關鍵字結束。在這之間的一條SQL操作失敗，那麼，ROLLBACK命令就可以把資料庫恢復到BEGIN開始之前的狀態。
BEGIN;
INSERT INTO salesinfo SET CustomerID=14;
UPDATE inventory SET Quantity=11
WHERE item='book';
COMMIT;
事務的另一個重要作用是當多個用戶同時使用相同的數據源時，它可以利用鎖定資料庫的方法來為用戶提供一種安全的訪問方式，這樣可以保證用戶的操作不被其它的用戶所干擾。
5、鎖定表
盡管事務是維護資料庫完整性的一個非常好的方法，但卻因為它的獨占性，有時會影響資料庫的性能，尤其是在很大的應用系統中。由於在事務執行的過程中，資料庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務結束。如果一個資料庫系統只有少數幾個用戶
來使用，事務造成的影響不會成為一個太大的問題；但假設有成千上萬的用戶同時訪問一個資料庫系統，例如訪問一個電子商務網站，就會產生比較嚴重的響應延遲。
其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。下面的例子就用鎖定表的方法來完成前面一個例子中事務的功能。
LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...
UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES
這里，我們用一個 SELECT 語句取出初始數據，通過一些計算，用 UPDATE 語句將新值更新到表中。包含有 WRITE 關鍵字的 LOCK TABLE 語句可以保證在 UNLOCK TABLES 命令被執行之前，不會有其它的訪問來對 inventory 進行插入、更新或者刪除的操作。
6、使用外鍵
鎖定表的方法可以維護數據的完整性，但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。例如，外鍵可以保證每一條銷售記錄都指向某一個存在的客戶。在這里，外鍵可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一條沒有合法CustomerID的記錄都不會被更新或插入到 salesinfo中。
CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;
注意例子中的參數「ON DELETE CASCADE」。該參數保證當 customerinfo 表中的一條客戶記錄被刪除的時候，salesinfo 表中所有與該客戶相關的記錄也會被自動刪除。如果要在 MySQL 中使用外鍵，一定要記住在創建表的時候將表的類型定義為事務安全表 InnoDB類型。該類型不是 MySQL 表的默認類型。定義的方法是在 CREATE TABLE 語句中加上 TYPE=INNODB。如例中所示。
7、使用索引
索引是提高資料庫性能的常用方法，它可以令資料庫伺服器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(), MIN()和ORDERBY這些命令的時候，性能提高更為明顯。那該對哪些欄位建立索引呢？一般說來，索引應建立在那些將用於JOIN, WHERE判斷和ORDER BY排序的欄位上。盡量不要對資料庫中某個含有大量重復的值的欄位建立索引。對於一個ENUM類型的欄位來說，出現大量重復值是很有可能的情況，例如 customerinfo中的「province」.. 欄位，在這樣的欄位上建立索引將不會有什麼幫助；相反，還有可能降低資料庫的性能。我們在創建表的時候可以同時創建合適的索引，也可以使用ALTER TABLE或CREATE INDEX在以後創建索引。此外，MySQL
從版本3.23.23開始支持全文索引和搜索。全文索引在 MySQL 中是一個FULLTEXT類型索引，但僅能用於MyISAM 類型的表。對於一個大的資料庫，將數據裝載到一個沒有FULLTEXT索引的表中，然後再使用ALTER TABLE或CREATE INDEX創建索引，將是非常快的。但如果將數據裝載到一個已經有FULLTEXT索引的表中，執行過程將會非常慢。
8、優化的查詢語句
絕大多數情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當的話，索引將無法發揮它應有的作用。下面是應該注意的幾個方面。首先，最好是在相同類型的欄位間進行比較的操作。在MySQL 3.23版之前，這甚至是一個必須的條件。例如不能將一個建有索引的INT欄位和BIGINT欄位進行比較；但是作為特殊的情況，在CHAR類型的欄位和 VARCHAR類型欄位的欄位大小相同的時候，可以將它們進行比較。其次，在建有索引的欄位上盡量不要使用函數進行操作。
例如，在一個DATE類型的欄位上使用YEAE()函數時，將會使索引不能發揮應有的作用。所以，下面的兩個查詢雖然返回的結果一樣，但後者要比前者快得多。
SELECT * FROM order WHERE YEAR(OrderDate)<2001;
SELECT * FROM order WHERE OrderDate<"2001-01-01";
同樣的情形也會發生在對數值型欄位進行計算的時候：
SELECT * FROM inventory WHERE Amount/7<24;
SELECT * FROM inventory WHERE Amount<24*7;
上面的兩個查詢也是返回相同的結果，但後面的查詢將比前面的一個快很多。第三，在搜索字元型欄位時，我們有時會使用 LIKE 關鍵字和通配符，這種做法雖然簡單，但卻也是以犧牲系統性能為代價的。例如下面的查詢將會比較表中的每一條記錄。
SELECT * FROM books
WHERE name like "MySQL%"
但是如果換用下面的查詢，返回的結果一樣，但速度就要快上很多：
SELECT * FROM books
WHERE name>="MySQL"and name<"MySQM"
最後，應該注意避免在查詢中讓MySQL進行自動類型轉換，因為轉換過程也會使索引變得不起作用。
⑩ 資料庫性能優化主要包括哪些方面
包括網路、硬體、操作系統、資料庫參數和應用程序。
資料庫的優化通常可以通過對網路、硬體、操作系統、資料庫參數和應用程序的優化來進行。最常見的優化手段就是對硬體的升級。
根據統計，對網路、硬體、操作系統、資料庫參數進行優化所獲得的性能提升，全部加起來只佔資料庫系統性能提升的40%左右，其餘的60%系統性能提升來自對應用程序的優化。許多優化專家認為，對應用程序的優化可以得到80%的系統性能的提升。
(10)資料庫伺服器配置文件性能調優擴展閱讀
資料庫性能優化法則歸納為5個層次：
1、減少數據訪問（減少磁碟訪問）
2、返回更少數據（減少網路傳輸或磁碟訪問）
3、減少交互次數（減少網路傳輸）
4、減少伺服器CPU開銷（減少CPU及內存開銷）
5、利用更多資源（增加資源）
由於每一層優化法則都是解決其對應硬體的性能問題，所以帶來的性能提升比例也不一樣。傳統資料庫系統設計是也是盡可能對低速設備提供優化方法，因此針對低速設備問題的可優化手段也更多，優化成本也更低。
任何一個SQL的性能優化都應該按這個規則由上到下來診斷問題並提出解決方案，而不應該首先想到的是增加資源解決問題。