mysqlsql優化方法
Ⅰ mysql sql優化之 優化GROUP BY 和 DISTINCT
創建表tb_point 表
准備空的tb_box表
函數
編寫存儲過程，給tb_box表添加100萬條數據
修改關聯數據
好於
優於
在執行以下語句時會報錯：
前面在 https://www.jianshu.com/p/95e50fd017ea 文章中有提到這個問題，是直接修改sql_mode將 ONLY_FULL_GROUP_BY直接幹掉。但是在《高性能mysql》中有一段話是這樣的：
那麼既然指出不要直接修改 sql_mode，那麼我們應該如何讓沖突的GRUOPBY語句正確執行呢？
文中有提到，可以使用max()和min()函數來實現；但是這種方式使用max和min函數較真的人可能會說這樣寫的分組查詢有問題，確實如此。但是如果更加在乎查詢效率，這樣做也無可厚非。
如果，實在無法接受使用上面那種方式的話，可以這樣使用子查詢的方式來進行查詢：
書上對於這種方式有描述如下：
這樣寫更滿足關系理論，但是成本有點高，因為子查詢需要填充臨時表，而子查詢中創建的臨時表是沒有任何索引的。
作者認為這樣寫對性能有影響。
但是從我測得結果來看，子查詢的耗時反而更少。性能反而更佳。這個子查詢耗時0.4秒。而使用max方式耗時0.8秒。幾乎一倍。我的mysql版本是 5.7.22-log
為了解其中的原因，我們查看它的執行計劃：
可見，因為子查詢而產生了一層 DERIVED 臨時表，但是這個臨時表的Extra欄位有顯示 Using index、key裡面顯示自建索引。說明用到了索引。這是查詢性能可觀的一個重要原因吧；
另外我分別使用 SHOW PROFILE命令查看各部分耗時，對比之下。沒看到有哪部分耗時差別特別大，使用JOIN、MAX 耗時比上子查詢耗時都差不多是1倍
有些時候對一沒有建立索引的欄位，進行GRUOP BY時。會產生Using filesort 文件內排序。因為GRUOP BY是在排序的基礎上進行分組的。
如下面sql：
如果業務上不對排序有要求。那麼就可以禁止GRUOP BY的排序：
這樣就把Using filesort給幹掉了！ 執行時間 1.237
當然，多數情況是多排序有要求的。此時也可以在GRUOP BY後面使用DESC和ASC關鍵字，使分組的結果集按需要的方向排序。如下：
分組查詢的一個變種就是要求mysql對分組結果再進行一次超級聚合。可以使用GROUP BY WITH ROLLUP 來實現這種邏輯，但可能性能不佳。因為通過查詢計劃分析出它是使用 Using temporary; Using filesort 來實現的。
使用WITH ROLLUP，查詢時間2.531秒。不使用0.774 秒。
1、所以，很多時候。我們在應用程序中做超級聚合是最好的！
2、當然也可使用UNION ALL 來實現：
3、還可以通過FROM子句嵌套使用子查詢：
Ⅱ SQL語句的幾種優化方法
1、盡可能建立索引，包括條件列，連接列，外鍵列等。
2、盡可能讓where中的列順序與復合索引的列順序一致。
3、盡可能不要select *，而只列出自己需要的欄位列表。
4、盡可能減少子查詢的層數。
5、盡可能在子查詢中進行數據篩選 。
Ⅲ 怎麼進行mysql資料庫優化
有八個方面可以對mysql進行優化：
1、選取最適用的欄位屬性
MySQL可以很好的支持大數據量的存取，但是一般說來，資料庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中欄位的寬度設得盡可能小。
2. 使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL從4.0的版本開始支持union查詢，它可以把需要使用臨時表的兩條或更多的select查詢合並的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證資料庫整齊、高效。
4、事務
盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯合（UNION）來創建各種各樣的查詢，但不是所有的資料庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設想一下，要把某個數據同時插入兩個相關聯的表中，可能會出現這樣的情況：第一個表中成功更新後，資料庫突然出現意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數據的不完整，甚至會破壞資料庫中的數據。要避免這種情況，就應該使用事務，它的作用是：要麼語句塊中每條語句都操作成功，要麼都失敗
5、鎖定表
盡管事務是維護資料庫完整性的一個非常好的方法，但卻因為它的獨占性，有時會影響資料庫的性能，尤其是在很大的應用系統中。由於在事務執行的過程中，資料庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務結束。其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。
6、使用外鍵
鎖定表的方法可以維護數據的完整性，但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。
7、使用索引
索引是提高資料庫性能的常用方法，它可以令資料庫伺服器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(),MIN()和ORDERBY這些命令的時候，性能提高更為明顯。
8、優化的查詢語句
絕大多數情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當的話，索引將無法發揮它應有的作用。
Ⅳ mysql的sql語句優化5種方式
只有5種嗎？我知道十種以上的說。
索引（沒我得全表查詢了）
改變數據儲引擎（MyISAM沒事務再也不用擔心鎖表了）
增加冗餘數來減少連表查詢數（消耗硬碟空間減少CPU使用）
調整查詢順序減少查詢量優先（數量少了連表的笛卡兒積也少了）
全文索引（文字長度有限制，而且IO使用量會大增，但是妥妥的快）
查詢盡量不要用函數（函數可是不走索引的哦親）
查詢變數類型要提前對好減少系統負擔（我提前改變了系統你就不用檢測了）
升級伺服器硬體（沒什麼是氪金解決不了的）
配置好臨時表空間，合理理由臨時表減少主表查詢搶資源（唯我獨查）
合理理由函數減少系統的判斷（明明都能確認內容不同你用UNION 系統還是傻傻的查一遍是否重復UNION ALL則跳過這個步驟同理 inner join 和 left join 也一樣）
強制走索引（復合索引的情況有時候手動走比系統判斷要好哦）
臟讀、幻讀等（你堵車我繞路）
數據歸檔，遷移（沒用的數據要進倉哦，別占著主表的資源）
表的碎片整理（遷移後碎片整理更健康哦親）
索引重構（數據都走了索引也應該重構一下才能保證速度哦）
善用存儲過程（串N個表（N大於10）的查詢千萬別一個SQL到底，分布式查詢在吧結果集合並吧騷年）
預處理數據（mysql也有job哦，對於經常要子查詢的數據可以先弄個明細表根據主表在後台進行補完，查詢的時候就更方便了）
懶得說了。。。。。。。。。。。。。。。。。。
Ⅳ sql優化的N種方法
1.SQL語句中IN包含的值不應過多:
例如：select id from t where num in(1,2,3) 對於連續的數值，能用between就不要用in了； 實測速度差距不是很大.
2.SELECT語句務必指明欄位名稱:
禁止用 * 來查詢 ,禁止用 * 來查詢 ,禁止用 * 來查詢 , 查找哪個欄位,就寫具體的欄位.
select * from user_test WHERE address=15988;
select address from user_test WHERE address=15988;
3.只查詢一條數據的時候，使用limit 1
【這個很有用】
4.避免在where子句中對欄位進行null值判斷:
【實測：null值的判斷依然走了索引】
explain select uid from user_test WHERE phone is null;
5.避免在where子句中對欄位進行表達式操作:
6.對於聯合索引來說，要遵守最左前綴法則:
例如組合索引(id,name,sex) 使用的時候,可以id 或者id,name . 禁止直接name,或者sex.會導致聯合索引失敗
注意: id, name,sex 這三個欄位填寫順序不會有影響, mysql會自動優化成最左匹配的順序.
前三條sql都能命中索引,中間兩條由於不符合最左匹配原則,索引失效.
最後一條sql 由於有最左索引id 所以索引部分成功,部分失效. id欄位索引使用成功.
7.盡量使用inner join，避免left join：
如果連接方式是inner join，在沒有其他過濾條件的情況下MySQL會自動選擇小表作為驅動表，但是left join在驅動表的選擇上遵循的是左邊驅動右邊的原則，即left join左邊的表名為驅動表。
【實測：不是很准確，具體用explain測試】
8.注意范圍查詢語句:
對於聯合索引來說，如果存在范圍查詢，比如between、>、<等條件時，會造成後面的索引欄位失效。
解決辦法: 業務允許的情況下,使用 >= 或者<= 這樣不影響索引的使用.
explain select * from user_test where uid=10 and name='張三' and phone='13527748096';
explain select * from user_test where uid between( 1 and 10) and name ='張三' and phone='13527748096';
9.不建議使用%前綴模糊查詢:
例如 : LIKE「%name」或者LIKE「%name%」，這種查詢會導致索引失效而進行全表掃描。但是可以使用LIKE 「name%」。
explain select * from user_test where uid=10 and uid like "%1" ;
explain select * from user_test where uid=10 and uid like "1%" ;
10.在 where 子句中使用 or 來連接條件，如果or連接的條件有一方沒有索引,將導致引擎放棄使用索引而進行全表掃描
解決辦法: 將or連接的雙方都建立索引,就可以使用.
explain select * from user_test where uid=10 or name='張三';
11.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。(此處存在疑點,我本人測試的時候,發現索引還是能使用到)
12.字元串類型的欄位 查詢的時候如果不加引號'' ,會導致自動進行隱式轉換,然後索引失效
Ⅵ mysql如何優化以下語句，查詢耗時太久了
根據所描述的問題，可嘗試在mms_profitcenter 的FOrderID ，FSuffix列上建立索引，再查詢試試。 下面提供30種mysql常用優化方法供參考：
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
若要提高效率，可以考慮全文檢索。
6.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
13.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。
17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。
20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
29.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
30.盡量避免大事務操作，提高系統並發能力。
Ⅶ 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
Ⅷ mysql資料庫如何優化誰能給出點具體的解決方案
1、explain：解釋sql的執行計劃，後邊的sql不執行
2、explain partitions ：用於查看存在分區的表的執行計劃
3、explain extended：待驗證
4、show warnings:
5、show create table:查看錶的詳細的創建語句，便於用戶對表進行優化
6、show indexes :產看錶的所有索引，show indexes from table_name，同樣也可以從information_schema.statistics表中獲得同樣的信息。cardinality列很重要，表示數據量。
7、show tables status: 查看資料庫表的底層大小以及表結構，同樣可以從information_schema.tables表中獲得底層表的信息。
8、show [global|session]status:可以查看mysql伺服器當前內部狀態信息。可以幫助卻行mysql伺服器的負載的各種指標。默認是session。同information_schema.global_status和information_schema.session_status
9、show [global|session] variables ：查看當前mysql系統變數的值，其中一些值能影響到sql語句的執行方式。同information_schema.global_variables和information_schema.session_variables;
10、information_schema:包含的表的數量和mysql的版本有關系。
Ⅸ 北大青鳥設計培訓：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的查詢語句的條件順序去匹配合適的索引。