資料庫語句優化
1、選取最適用的欄位屬性,盡可能減少定義欄位長度,盡量把欄位設置NOT NULL,例如'省份,性別',最好設置為ENUM
2、使用連接（JOIN）來代替子查詢:
a.刪除沒有任何訂單客戶:DELETE FROM customerinfo WHERE customerid NOT in(SELECT customerid FROM orderinfo)
b.提取所有沒有訂單客戶:SELECT FROM customerinfo WHERE customerid NOT in(SELECT customerid FROM orderinfo)
c.提高b的速度優化:SELECT FROM customerinfo LEFT JOIN orderid customerinfo.customerid=orderinfo.customerid
WHERE orderinfo.customerid IS NULL
3、使用聯合(UNION)來代替手動創建的臨時表
a.創建臨時表:SELECT name FROM `nametest` UNION SELECT username FROM `nametest2`
4、事務處理:
a.保證數據完整性,例如添加和修改同時,兩者成立則都執行,一者失敗都失敗
mysql_query("BEGIN");
mysql_query("INSERT INTO customerinfo (name) VALUES ('$name1')";
mysql_query("SELECT * FROM `orderinfo` where customerid=".$id");
mysql_query("COMMIT");
5、鎖定表,優化事務處理:
a.我們用一個 SELECT 語句取出初始數據，通過一些計算，用 UPDATE 語句將新值更新到表中。
包含有 WRITE 關鍵字的 LOCK TABLE 語句可以保證在 UNLOCK TABLES 命令被執行之前，
不會有其它的訪問來對 inventory 進行插入、更新或者刪除的操作
mysql_query("LOCK TABLE customerinfo READ, orderinfo WRITE");
mysql_query("SELECT customerid FROM `customerinfo` where id=".$id);
mysql_query("UPDATE `orderinfo` SET ordertitle='$title' where customerid=".$id);
mysql_query("UNLOCK TABLES");
6、使用外鍵,優化鎖定表
a.把customerinfo里的customerid映射到orderinfo里的customerid,
任何一條沒有合法的customerid的記錄不會寫到orderinfo里
CREATE TABLE customerinfo
(
customerid INT NOT NULL,
PRIMARY KEY(customerid)
)TYPE = INNODB;
CREATE TABLE orderinfo
(
orderid INT NOT NULL,
customerid INT NOT NULL,
PRIMARY KEY(customerid,orderid),
FOREIGN KEY (customerid) REFERENCES customerinfo
(customerid) ON DELETE CASCADE
)TYPE = INNODB;
注意:'ON DELETE CASCADE',該參數保證當customerinfo表中的一條記錄刪除的話同時也會刪除order
表中的該用戶的所有記錄,注意使用外鍵要定義事務安全類型為INNODB;
② 玉溪電腦培訓學校告訴你mysql資料庫的優化方法
我們都知道，伺服器資料庫的開發一般都是通過java或者是PHP語言來編程實現的，而為了提高我們資料庫的運行速度和效率，資料庫優化也成為了我們每日的工作重點，今天，玉溪IT培訓http://www.kmbdqn.cn/就一起來了解一下mysql伺服器資料庫的優化方法。
為什麼要了解索引
真實案例
案例一：大學有段時間學習爬蟲，爬取了知乎300w用戶答題數據，存儲到mysql數據中。那時不了解索引，一條簡單的「根據用戶名搜索全部回答的sql「需要執行半分鍾左右，完全滿足不了正常的使用。
案例二：近線上應用的資料庫頻頻出現多條慢sql風險提示，而工作以來，對資料庫優化方面所知甚少。例如一個用戶數據頁面需要執行很多次資料庫查詢，性能很慢，通過增加超時時間勉強可以訪問，但是性能上需要優化。
索引的優點
合適的索引，可以大大減小mysql伺服器掃描的數據量，避免內存排序和臨時表，提高應用程序的查詢性能。
索引的類型
mysql數據中有多種索引類型，primarykey，unique，normal，但底層存儲的數據結構都是BTREE;有些存儲引擎還提供hash索引，全文索引。
BTREE是常見的優化要面對的索引結構，都是基於BTREE的討論。
B-TREE
查詢數據簡單暴力的方式是遍歷所有記錄;如果數據不重復，就可以通過組織成一顆排序二叉樹，通過二分查找演算法來查詢，大大提高查詢性能。而BTREE是一種更強大的排序樹，支持多個分支，高度更低，數據的插入、刪除、更新更快。
現代資料庫的索引文件和文件系統的文件塊都被組織成BTREE。
btree的每個節點都包含有key，data和只想子節點指針。
btree有度的概念d>=1。假設btree的度為d，則每個內部節點可以有n=[d+1，2d+1)個key，n+1個子節點指針。樹的大高度為h=Logb[(N+1)/2]。
索引和文件系統中，B-TREE的節點常設計成接近一個內存頁大小(也是磁碟扇區大小)，且樹的度非常大。這樣磁碟I/O的次數，就等於樹的高度h。假設b=100，一百萬個節點的樹，h將只有3層。即，只有3次磁碟I/O就可以查找完畢，性能非常高。
索引查詢
建立索引後，合適的查詢語句才能大發揮索引的優勢。
另外，由於查詢優化器可以解析客戶端的sql語句，會調整sql的查詢語句的條件順序去匹配合適的索引。
③ 開發中，SQL語句優化有哪些方法
看你資料庫類型和框架是否支持。
一般開發中遇到慢SQL存在3個問題（索引健全的情況下）。
數據量多導致總行數慢，因為數據在不歸檔、遷移、轉總賬的情況下會不斷積壓。許可權越高看見的數據量就越大，數據量越大總行數就越高。一般框架是以分頁的SQL為基礎計算總行數的。這樣就會導致掃描行數高物理讀高查詢速度慢。優化方案就是總行數進行狀態歸檔，以歸檔+實時的方式展現出來
連表超過多，部分數據表是單獨的，但是不同部門的數據又有關聯性，領導要看全生命周期或者流程數據的情況下必須多表相連。這樣由於N個明細表導致笛卡兒積先不說，邏輯復雜連表多會消耗CPU，哪怕你查詢能500毫秒內顯示但是如果多人同時查就讓CPU超100%甚至做成鎖等待等堵塞。這個情況就是要用類似「雲計算」的分布式計算。通過觸發器、存儲過程等規定時間內吧業務表數據計算好並寫到展示表中，直接通過展示表進行關聯，這樣鎖表也於業務表無關，關聯表也能變少達到減少CPU消耗的目的。
iops與cpu佔比高導致資料庫癱瘓。第2點看出如果CPU高資料庫全SQL都會慢，IOPS也一樣。SQL慢會導致事務中的查詢慢，解放事務變慢了其他查詢就會鎖等待狀態變成堵塞。所以遇到大規模的查詢是否先查主鍵然後通過游標一個一個計算再進臨時表。這個是消耗時間和內存換CPU和IOPS的一個例子。反正伺服器資源最高怎樣開發應該是了解的，如何管制資源之間的平衡這個很重要。
舉個例子，部分MYSQL框架喜歡一次性把資料庫都導出來，然後減少子查詢，這個演算法針對有效的基礎數據這樣是可行的。針對業務數據應該沒人會用，但是基礎數據中也可能會存在海量的情況，比如坐標軌跡、省市區、電話號碼歸屬等。如果無腦應用這個框架會導致查詢起來很慢。
④ 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
⑤ 如何優化SQL語句
一、問題的提出
在應用系統開發初期，由於開發資料庫數據比較少，對於查詢SQL語句，復雜視圖的的編寫等體會不出SQL語句各種寫法的性能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中數據的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於海量數據，劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍，可見對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提高系統的可用性。
在多數情況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提高性能。但是，如果在SQL語句的where子句中寫的SQL代碼不合理，就會造成優化器刪去索引而使用全表掃描，一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清楚優化器根據何種原則來刪除索引，這有助於寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中，即使某些列存在索引，但是由於編寫了劣質的SQL，系統在運行該SQL語句時也不能使用該索引，而同樣使用全表掃描，這就造成了響應速度的極大降低。
1.
IS
NULL
與
IS
NOT
NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。
任何在where子句中使用is
null或is
not
null的語句優化器是不允許使用索引的。
2.
聯接列
對於有聯接的列，即使最後的聯接值為一個靜態值，優化器是不會使用索引的。我們一起來看一個例子，假定有一個職工表(employee)，對於一個職工的姓和名分成兩列存放(FIRST_NAME和LAST_NAME)，現在要查詢一個叫比爾.柯林頓(Bill
Cliton)的職工。
下面是一個採用聯接查詢的SQL語句，
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面這條語句完全可以查詢出是否有Bill
Cliton這個員工，但是這里需要注意，系統優化器對基於last_name創建的索引沒有使用。
當採用下面這種SQL語句的編寫，Oracle系統就可以採用基於last_name創建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的，要求在職工表中查詢名字中包含cliton的人。可以採用如下的查詢SQL語句:
select
*
from
employee
where
last_name
like
'%cliton%';
這里由於通配符(%)在搜尋詞首出現，所以Oracle系統不使用last_name的索引。在很多情況下可能無法避免這種情況，但是一定要心中有底，通配符如此使用會降低查詢速度。然而當通配符出現在字元串其他位置時，優化器就能利用索引。在下面的查詢中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by語句
ORDER
BY語句決定了Oracle如何將返回的查詢結果排序。Order
by語句對要排序的列沒有什麼特別的限制，也可以將函數加入列中(象聯接或者附加等)。任何在Order
by語句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order
by語句以找出非索引項或者表達式，它們會降低性能。解決這個問題的辦法就是重寫order
by語句以使用索引，也可以為所使用的列建立另外一個索引，同時應絕對避免在order
by子句中使用表達式。
5.
NOT
我們在查詢時經常在where子句使用一些邏輯表達式，如大於、小於、等於以及不等於等等，也可以使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取反。下面是一個NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT，則應在取反的短語前面加上括弧，並在短語前面加上NOT運算符。NOT運算符包含在另外一個邏輯運算符中，這就是不等於(<>)運算符。換句話說，即使不在查詢where子句中顯式地加入NOT詞，NOT仍在運算符中，見下例:
...
where
status
<>'INVALID';
對這個查詢，可以改寫為不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
⑥ SQL語句的幾種優化方法
1、盡可能建立索引，包括條件列，連接列，外鍵列等。
2、盡可能讓where中的列順序與復合索引的列順序一致。
3、盡可能不要select *，而只列出自己需要的欄位列表。
4、盡可能減少子查詢的層數。
5、盡可能在子查詢中進行數據篩選 。
⑦ 資料庫如何優化
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磁碟網路鏡像方案，其特點為軟體功能強大，數據可在底層塊設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。
⑧ 資料庫sql語句優化
select ...
from prpsauditmain this_
where 1=1
and auditNo > ''
and exists (
select 1
from PrpDcompany a
where 1=1
and this_.comCode = a.comCode
and a.upperPath like '00000000,65000000%'
)
and this_.auditflag<>?
order by this_.inserttimeforhis desc
⑨ 請問SQL語句優化的策略都有哪些
●
創建表的時候。應盡量建立主鍵,根據主鍵查詢數據；
●
大數據表刪除，用truncate
table代替delete。
●
合理使用索引，在OLTP應用中一張表的索引不要太多。組合索引的列順序盡量與查詢條件列順序保持一致；對於數據操作頻繁的表，索引需要定期重建，以減少失效的索引和碎片。
●
查詢盡量用確定的列名，少用*號。
盡量少嵌套子查詢，這種查詢會消耗大量的CPU資源；對於有比較多
or運算的查詢，建議分成多個查詢，用union
all聯結起來；多表查詢
的查詢語句中，選擇最有效率的表名順序(基於規則的優化器中有效)。Oracle解析器對表解析從右到左，所以記錄少的表放在右邊。
●
盡量多用commit語句提交事務，可以及時釋放資源、解
鎖、釋放日誌空間、減少管理花費；在頻繁的、性能要求比較高的
數據操作中，盡量避免遠程訪問，如資料庫鏈等，訪問頻繁的表可以常駐內存：alter
table．．．cache；
⑩ 2020-10-11：一條sql語句執行時間過長，應該如何優化從哪些方面進行優化
改進資料庫sql語句進行優化的理由 應用程序之優化通常可分為兩個方面：源代碼之優化和sql語句之優化。源代碼之優化在時間成本和風險上代價很高；另一方面，源代碼之優化對資料庫系統性能之提升收效有限。 優化之理由 1)sql語句是對資料庫(數據)進行操作之惟一途徑； 2)sql語句消耗了70%~90%之資料庫資源； 3)sql語句獨立於程序設計邏輯，相對於對程序源代碼之優化，對sql語句之優化在時間成本和風險上之代價都很低； 4)sql語句可以有不同之寫法； 5)sql語句易學，難精通。 優化技術之發展 第一代之sql優化工具是執行計劃分析工具。這類之工具對輸入之sql語句從資料庫提取執行計劃，並解釋執行計劃中關鍵字之含義；第二代之sql優化工具只能提供增加索引之建議，它通過對輸入之sql語句之執行計劃之分析來產生是否要增加索引之建議。該類工具存在著致命之缺點——只分析了一條sql語句就得出增加某個索引之結論，根本不理會(實際上也無法評估到)增加之索引對整體資料庫系統性能之影響。其破壞性在於： 1、不理會增加之索引對其他增、刪、改sql語句之負面影響； 2、沒有考慮增加之索引可能導致資料庫判斷失誤； 3、對由於增加索引引起之資料庫系統負擔忽略不計。 同時，這些工具由於技術水平之限制存在著以下缺點： 1、無法保證建議或改寫之正確性； 2、無法進行重寫，僅僅提供了建議或有限程度之改寫，重寫工作還是需要人工完成，優化工作所需之時間和工作量同人工進行優化差不多； 3、改寫之規則和hints有限，難以處理復雜之sql語句； 4、必須人手逐條進行測試。 這類工具曾經盛極一時，直到人工智慧自動sql優化之出現。