㈠ 怎麼寫高效的sql語句
優化SQL查詢：如何寫出高性能SQL語句
1、首先要搞明白什麼叫執行計劃？
執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用 「全表掃描」方式。
可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：優化SQL查詢：如何寫出高性能SQL語句
1、首先要搞明白什麼叫執行計劃？
執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用 「全表掃描」方式。
可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：
㈡ 優化SQL 查詢：如何寫出高性能SQL語句
1、深入理解資料庫的工作原理和數據存儲的方式，不同的資料庫的工作原理是不同的，mysql oracle db2等等都是不同的，更不要說一些nosql資料庫和newsql資料庫了。
2、理解sql語句檢索數據的方式。
3、理解索引，知道怎樣的欄位建立怎樣的索引，索引能做什麼，不能做什麼，合理的建立欄位。
4、合理的拆分和合並表，數據放在一張表裡面查詢肯定比放在多張表裡面級聯查詢要快。
5、會查看執行任務，任何資料庫都有查看執行任務的方法，包括nosql資料庫和newsql資料庫已經一些大數據資料庫；同時還要會分析執行任務，分析主要是所以的使用效率和欄位數據的檢索方式。
6、sql語句只是性能優化的簡單方面，性能優化是從整體應用架構開始體現的，優化sql並不能夠解決根本問題，當數據量達到一定級別以後，數據就不能使用關系型資料庫，而要使用大數據資料庫，這樣sql就無用了。
7、不要刻意專注sql本身，sql只是一種查詢語言，它本身與性能無關，性能優化的本質在於對存儲方式和查詢檢索過程的深入理解。
8、任何系統功能業務的准確性至上，首先保證功能的正確性再考慮性能優化，如果功能就是數據量大，業務復雜，必須要用到低性能sql的檢索方式，那麼你只能妥協，否則就要棄用sql和關系型資料庫另尋它路。
㈢ 《高性能MySQL第3版》pdf下載在線閱讀，求百度網盤雲資源
《高性能MySQL(第3版)》（施瓦茨 (Baron Schwartz)）電子書網盤下載免費在線閱讀
資源鏈接：
鏈接：
書名：高性能MySQL(第3版)
作者：施瓦茨 (Baron Schwartz)
譯者：寧海元
豆瓣評分：9.3
出版社：電子工業出版社
出版年份：2013-5-1
頁數：764
內容簡介：
《高性能mysql(第3版)》是mysql 領域的經典之作，擁有廣泛的影響力。第3 版更新了大量的內容，不但涵蓋了最新mysql 5.5版本的新特性，也講述了關於固態盤、高可擴展性設計和雲計算環境下的資料庫相關的新內容，原有的基準測試和性能優化部分也做了大量的擴展和補充。全書共分為16 章和6 個附錄，內容涵蓋mysql 架構和歷史，基準測試和性能剖析，資料庫軟硬體性能優化，復制、備份和恢復，高可用與高可擴展性，以及雲端的mysql 和mysql相關工具等方面的內容。每一章都是相對獨立的主題，讀者可以有選擇性地單獨閱讀。
《高性能mysql(第3版)》不但適合資料庫管理員（dba）閱讀，也適合開發人員參考學習。不管是資料庫新手還是專家，相信都能從本書有所收獲。
作者簡介：
關於作者
Baron Schwartz 是一位軟體工程師，居住在弗吉尼亞州的Charlottesville，網路常用名是Xaprb，這是按照QWERTY 鍵盤的順序在Dvorak 鍵盤上打出來的名字。在不忙於解決有趣的編程挑戰時，Baron 會和他的妻子Lynn 以及小狗Carbon 一起享受閑暇的時光。他有一個軟體工程方面的博客，地址是http://www.xaprb.com/blog/
Peter Zaitsev 曾經是MySQL AB 公司高性能組的經理，目前在運作mysqlperformance
blog.com 網站。他擅長於幫助那些每天有數以百萬計訪問量的網站的管理員解決問題，這些網站通常需要幾百台機器來處理TB 級的數據。他常常為了解決一個問題而不停地升級硬體和軟體（比如查詢優化）。Peter 還經常在各種會議上演講。
Vadim Tkachenko 曾經是MySQL AB 公司的性能工程師。作為一名在多線程編程和同步方面的專家，他的主要工作是基準測試、性能剖析，以及找出系統的性能瓶頸。他還在性能監控和調優方面做了一些工作，使得MySQL 在多核機器上有更好的可擴展性。
================================================================
譯者簡介
寧海元 有超過十年的資料庫管理經驗，從最初到SQL Server 2000到Oracle到MySQL，擅長資料庫高可用架構，性能優化和故障診斷。2007年加入淘寶，帶領淘寶DBA團隊支撐了淘寶業務的快速增長，完成了資料庫的垂直拆分、水平拆分，遷移到MySQL體系等主要工作。目前專注於無線數據領域。網路常用名NinGoo，個人博客：http://www.ningoo.net
周振興 畢業於北京師范大學數學系，09年加入淘寶資料庫團隊負責MySQL運維管理工作，有豐富的MySQL性能優化、Troubleshooting經驗，對MySQL主要模塊的實現和原理有深入的研究，經歷淘寶MySQL實例從30到3000的發展，對系統架構、高可用環境規劃都有深入理解。個人博客：http://orczhou.com
彭立勛 2010年大學畢業後加入阿里巴巴運維部。作為一名MySQL DBA，在運維MySQL的過程中，對MySQL和InnoDB的一些功能和缺陷就進行了補充，編寫了多主復制和數據閃回等補丁。目前在阿里集團核心系統研發部資料庫組，專注於MySQL資料庫相關的開發工作。後來一些補丁被MySQL之父Mony看中，成為MariaDB提交組（Maria-captains）成員，並且把多主復制，線程內存監控等補丁合並到了MariaDB 10.0版本。
翟衛祥 畢業於武漢大學，研究生階段從事資料庫相關研究。畢業後就職於阿里巴巴集團資料庫技術團隊至今，主要負責阿里內部MySQL代碼分支維護，包括MySQL Bug Fix及新特性開發。對MySQL內核有一定的研究。
劉輝 2008年畢業於西安電子科技大學計算機系，碩士學位。2011年加入阿里巴巴集團資料庫技術團隊，花名希羽，MySQL內核開發工程師。
㈣ 深入淺出mysql和高性能mysql哪本好
限流演算法目前程序開發過程常用的限流演算法有兩個：漏桶演算法和令牌桶演算法。
漏桶演算法
漏桶演算法的原理比較簡單，請求進入到漏桶中，漏桶以一定的速率漏水。當請求過多時，水直接溢出。可以看出，漏桶演算法可以強制限制數據的傳輸速度。如圖所示，把請求比作是水滴，水先滴到桶里，通過漏洞並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢出，即拒絕服務。
圖片來自網路
漏桶演算法和令牌桶演算法的選擇
兩者的主要區別漏桶演算法能夠強行限制處理數據的速率，不論系統是否空閑。而令牌桶演算法能夠在限制數據的平均處理速率的同時還允許某種程度的突發流量。如何理解上面的含義呢？漏桶演算法，比如系統吞吐量是 120/s，業務請求 130/s，使用漏斗限流 100/s，起到限流的作用，多餘的請求將產生等待或者丟棄。對於令牌桶演算法，每秒產生 100 個令牌，系統容量 200 個令牌。正常情況下，業務請求 100/s 時，請求能被正常被處理。當有突發流量過來比如 200 個請求時，因為系統容量有 200 個令牌可以同一時刻處理掉這 200 個請求。如果是漏桶演算法，則只能處理 100 個請求，其他的請求等待或者被丟棄。
㈤ 如何寫出高性能sql語句
盡量不要在where中包含子查詢;
關於時間的查詢，盡量不要寫成：where to_char(dif_date,'yyyy-mm-dd')=to_char('2007-07-01','yyyy-mm-dd');
2
在過濾條件中，可以過濾掉最大數量記錄的條件必須放在where子句的末尾;
FROM子句中寫在最後的表(基礎表，driving table)將被最先處理，在FROM子句中包含多個表的情況下，你必須選擇記錄條數最少的表作為基礎表。如果有三個以上的連接查詢，那就需要選擇交叉表(intersection table)作為基礎表，交叉表是指那個被其他表所引用的表;
3
採用綁定變數
4
在WHERE中盡量不要使用OR
5
用EXISTS替代IN、用NOT EXISTS替代NOT IN;
6
避免在索引列上使用計算：WHERE SAL*12>25000;
7
用IN來替代OR： WHERE LOC_ID=10 OR LOC_ID=15 OR LOC_ID=20
8
避免在索引列上使用IS NULL和IS NOT NULL;
9
總是使用索引的第一個列;
10
用UNION-ALL替代UNION;
11
避免改變索引列的類型：SELECT...FROM EMP WHERE EMPNO='123'，由於隱式數據類型轉換，to_char(EMPNO)='123'，因此，將不採用索引，一般在採用字元串拼湊動態SQL語句出現;
12
'!=' 將不使用索引;
13
優化GROUP BY;
14
避免帶有LIKE參數的通配符，LIKE '4YE%'使用索引，但LIKE '%YE'不使用索引
15
避免使用困難的正規表達式，例如select * from customer where zipcode like "98___"，即便在zipcode上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改成select * from customer where zipcode>"98000"，在執行查詢時就會利用索引來查詢，顯然會大大提高速度;
16
盡量明確的完成SQL語句，盡量少讓資料庫工作。比如寫SELECT語句時，需要把查詢的欄位明確指出表名。盡量不要使用SELECT *語句。組織SQL語句的時候，盡量按照資料庫的習慣進行組織。
㈥ 如何寫出高性能SQL語句
1. SQL優化的原則是:將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量.
調整不良SQL通常可以從以下幾點切入:
? 檢查不良的SQL,考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句,要明確查出的欄位.
3. 在一個SQL語句中,如果一個where條件過濾的資料庫記錄越多,定位越准確,則該where條件越應該前移.
4. 查詢時盡可能使用索引覆蓋.即對SELECT的欄位建立復合索引,這樣查詢時只進行索引掃描,不讀取數據塊.
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT (*)和select top 1 語句.
6. 使用內層限定原則,在拼寫SQL語句時,將查詢條件分解、分類,並盡量在SQL語句的最里層進行限定,以減少數據的處理量.
㈦ 高性能MySQL的內容簡介
《高性能MySQL》是分享MySQL實用經驗的圖書。它不但可以幫助MySQL初學者提高使用技巧，更為有經驗的MySQL DBA指出了開發高性能MySQL應用的途徑。
《高性能MySQL(第2版)》包含14章和4個附錄，內容覆蓋MySQL系統架構、設計應用技巧、SQL語句優化、伺服器性能調優、系統配置管理和安全設置、監控分析，以及復制、擴展和備份/還原等主題，每一章的內容自成體系，適合各領域技術人員作選擇性的閱讀。
㈧ 寫出高性能SQL語句1，首先要搞明白什麼叫執行計劃
1、首先要搞明白什麼叫執行計劃？2、統一SQL語句的寫法3、不要把SQL語句寫得太復雜4、使用「臨時表」暫存中間結果5、OLTP系統SQL語句必須採用綁定變數6、綁定變數窺測7、只在必要的情況下才使用begintran
㈨ 請簡單說明SQL語句書可以提高執行效率的幾種需要注意的書寫方法
1.1 where條件的列上都得有統計信息。
沒統計信息SQLServer就無法估算不同查詢計劃開銷優劣，而只能採用最穩妥的Scan（不管是table scan還是clustered index scan）。一般情況下我們不會犯這種錯誤——where條件里不使用非索引列是個常識。索引上的統計信息是無法刪除的。
1.2 盡量不使用不等於（!=）或者NOT邏輯運算符。
這條規則被廣為傳頌，原因據聯機文檔和百敬同學的書講，也是SQLServer無法評估不同查詢計劃開銷的優劣。但是SqlServer2k5聰明了很多，試驗發現盡管用了!=或者not，查詢還是會被優化。如下：
create table tb1
(
col1 int identity(1,1) primary key,
col2 int not null,
col3 varchar(64) not null
)
create index ix_tb1_col2 on tb1
(
col2
)
create index ix_tb1_col3 on tb1
(
col3
)
declare @f int
set @f = 0
while @f < 9999
begin
insert into tb1 (col2, col3) values(1, 'ssdd')
set @f = @f + 1
end
insert into tb1 (col2, col3) values(0, 'aadddd')
insert into tb1 (col2, col3) values(2, 'bbddd')
insert into tb1 (col2, col3) values(3, 'bbaaddddddaa')
通過上述代碼，各位可以看到數據分布。col2值為1的有9999條；col2值為0、2、3的分別有1條。
按照本條規則，!= 和NOT帶來的應該是個scan操作，但實際情況是：
其實重要的是要符合你的邏輯要求，那樣應用這些原理就OK
建議你看一本書《The art of SQL》