mysqlor語句優化

SQL語句中的多個OR該怎么來優化

與或非是邏輯判斷的必須，如果真的需要很多or來判斷，那么誰也沒有辦法。

一般優化or的辦法是，減少or，也就是減少判斷條件。這個不僅僅是數據庫的問題，需要從業務等多方面來考慮。

比如，業務可以減少一個or，那么這就是最好的優化方式。如果幾個or字段都有索引，那么可以考慮分開查詢，這樣能走索引，因為or不走索引。

也算優化。縮小查詢范圍也算，雖然還是or，還是那么多條件，但是其他條件卻可以，讓數據量從10w，變為5千，這也是優化。

至于其他的方法，什么換個寫法等等，大多數都是扯淡，沒什么實際意義。

MySQL數據庫如何對Where語句進行優化

下面提供的是在MySQL數據庫的一些優化： 刪除不必要的括號： （（a AND b） AND c OR (((a AND b) AND (c AND d)))) - (a AND b AND c) OR (a AND b AND c AND d) 常數調入：（a - b5 AND b=c AND a=5 ）。

刪除常數條件： （B=5 AND B=5） OR (B=6 AND 5=5) OR (B=7 AND 5=6) - B=5 OR B=6 索引使用的常數表達式僅計算一次。 在一個單個表上的沒有一個WHERE的COUNT（*)直接從表中檢索信息。

當僅使用一個表時，對任何NOT NULL表達式也這樣做。 無效常數表達式的早期檢測。

MySQL快速檢測某些SELECT語句是不可能的并且不返回行。 如果你不使用GROUP BY或分組函數（COUNT（)、MIN（)……），HAVING與WHERE合并。

為每個子聯結（sub join），構造一個更簡單的WHERE以得到一個更快的WHERE計算并且也盡快跳過記錄。 所有常數的表在查詢中的在其他任何表之前被讀出。

一個常數的表是，一個空表或一個有1行的表。 與在一個UNIQUE索引、或一個PRIMARY KEY的WHERE子句一起使用的表，這里所有的索引部分使用一個常數表達式并且索引部分被定義為NOT NULL。

所有下列的表用作常數表： mysql SELECT * FROM t WHERE primary_key=1; mysql SELECT * FROM t1,t2 WHERE *y_key=1 AND *y_key=*； 對聯結表的最好聯結組合是通過嘗試所有可能性來找到。如果所有在ORDER BY和GROUP BY的列來自同一個表，那么當聯結時，該表首先被選中。

如果你使用SQL_SMALL_RESULT,MySQL將使用一個在內存中的表。 如果有一個ORDER BY子句和一個不同的GROUP BY子句，或如果ORDER BY或GROUP BY包含不是來自聯結隊列中的第一個表的其他表的列，創建一個臨時表。

mysql怎么對這個語句優化

如何查看mysql語句的優化結果MySQL數據庫有幾個配置選項可以幫助我們及時捕獲低效SQL語句1,slow_query_log這個參數設置為ON，可以捕獲執行時間超過一定數值的SQL語句。

2,long_query_time當SQL語句執行時間超過此數值時，就會被記錄到日志中，建議設置為1或者更短。3,slow_query_log_file記錄日志的文件名。

4,log_queries_not_using_indexes這個參數設置為ON，可以捕獲到所有未使用索引的SQL語句，盡管這個SQL語句有可能。

sql or 語句優化問題

試試這個：

SELECT * FROM get_childs1('1')

WHERE addorgid=childid

OR receiveorgid=childid

OR sendorgid=childid

OR adddeptid =childid

OR senddeptid =childid

OR receivedeptid=childid

改成：

SELECT * FROM get_childs1('1')

WHERE childid in(addorgid,receiveorgid,sendorgid,adddeptid,senddeptid,receivedeptid)

MySQL語句優化技巧

1、應盡量避免在 where 子句中使用！=或操作符，否則將引擎放棄使用索引而進行全表掃描。

2、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

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 '?c%'

若要提高效率，可以考慮全文檢索。

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

mysql 優化包括哪些內容

mysql的優化大的有兩方面：1、配置優化 配置的優化其實包含兩個方面的：操作系統內核的優化和mysql配置文件的優化 1）系統內核的優化對專用的mysql服務器來說，無非是內存實用、連接數、超時處理、TCP處理等方面的優化，根據自己的硬件配置來進行優化，這里不多講； 2)mysql配置的優化，一般來說包含：IO處理的常用參數、最大連接數設置、緩存使用參數的設置、慢日志的參數的設置、innodb相關參數的設置等，如果有主從關系在設置主從同步的相關參數即可，網上的相關配置文件很多，大同小異，常用的設置大多修改這些差不多就夠用了。

2、sql語句的優化1、 盡量稍作計算Mysql的作用是用來存取數據的，不是做計算的，做計算的話可以用其他方法去實現，mysql做計算是很耗資源的。2.盡量少 joinMySQL 的優勢在于簡單，但這在某些方面其實也是其劣勢。

MySQL 優化器效率高，但是由于其統計信息的量有限，優化器工作過程出現偏差的可能性也就更多。對于復雜的多表 Join，一方面由于其優化器受限，再者在 Join 這方面所下的功夫還不夠，所以性能表現離 Oracle 等關系型數據庫前輩還是有一定距離。

但如果是簡單的單表查詢，這一差距就會極小甚至在有些場景下要優于這些數據庫前輩。3.盡量少排序 排序操作會消耗較多的 CPU 資源，所以減少排序可以在緩存命中率高等 IO 能力足夠的場景下會較大影響 SQL的響應時間。

對于MySQL來說，減少排序有多種辦法，比如： 通過利用索引來排序的方式進行優化 減少參與排序的記錄條數 非必要不對數據進行排序4.盡量避免 select * 在數據量少并且訪問量不大的情況下，select * 沒有什么影響，但是量級達到一定級別的時候，在執行效率和IO資源的使用上，還是有很大關系的，用什么字段取什么字段，減少不必要的資源浪費。 之前遇到過因為一個字段存儲的數據比較大，并發高的情況下把網絡帶寬跑滿的情況，造成網站打不開或是打開速度極慢的情況。

5.盡量用 join 代替子查詢 雖然 Join 性能并不佳，但是和 MySQL 的子查詢比起來還是有非常大的性能優勢。MySQL 的子查詢執行計劃一直存在較大的問題，雖然這個問題已經存在多年，但是到目前已經發布的所有穩定版本中都普遍存在，一直沒有太大改善。

雖然官方也在很早就承認這一問題，并且承諾盡快解決，但是至少到目前為止我們還沒有看到哪一個版本較好的解決了這一問題。6.盡量少 or 當 where 子句中存在多個條件以“或”并存的時候，MySQL 的優化器并沒有很好的解決其執行計劃優化問題，再加上 MySQL 特有的 SQL 與 Storage 分層架構方式，造成了其性能比較低下，很多時候使用 union all 或者是union（必要的時候）的方式來代替“or”會得到更好的效果。

7.盡量用 union all 代替 unionunion 和 union all 的差異主要是前者需要將兩個（或者多個）結果集合并后再進行唯一性過濾操作，這就會涉及到排序，增加大量的 CPU 運算，加大資源消耗及延遲。所以當我們可以確認不可能出現重復結果集或者不在乎重復結果集的時候，盡量使用 union all 而不是 union。

8.盡量早過濾 這一優化策略其實最常見于索引的優化設計中（將過濾性更好的字段放得更靠前）。 在 SQL 編寫中同樣可以使用這一原則來優化一些 Join 的 SQL。

比如我們在多個表進行分頁數據查詢的時候，我們最好是能夠在一個表上先過濾好數據分好頁，然后再用分好頁的結果集與另外的表 Join，這樣可以盡可能多的減少不必要的 IO 操作，大大節省 IO 操作所消耗的時間。9.避免類型轉換 這里所說的“類型轉換”是指 where 子句中出現 column 字段的類型和傳入的參數類型不一致的時候發生的類型轉換：A：人為在column_name 上通過轉換函數進行轉換 直接導致 MySQL（實際上其他數據庫也會有同樣的問題）無法使用索引，如果非要轉換，應該在傳入的參數上進行轉換B：由數據庫自己進行轉換 如果我們傳入的數據類型和字段類型不一致，同時我們又沒有做任何類型轉換處理，MySQL 可能會自己對我們的數據進行類型轉換操作，也可能不進行處理而交由存儲引擎去處理，這樣一來，就會出現索引無法使用的情況而造成執行計劃問題。

以上兩種情況在開發者因為某種原因經常會有，本來可以用到索引的結果類型不對沒有用到索引，或是因為類型不對又有越界的情況發生造成無法使用索引的情況，結果造成很嚴重的事故。10.優先優化高并發的 SQL，而不是執行頻率低某些“大”SQL 對于破壞性來說，高并發的 SQL 總是會比低頻率的來得大，因為高并發的 SQL 一旦出現問題，甚至不會給我們任何喘息的機會就會將系統壓跨。

而對于一些雖然需要消耗大量 IO 而且響應很慢的 SQL，由于頻率低，即使遇到，最多就是讓整個系統響應慢一點，但至少可能撐一會兒，讓我們有緩沖的機會。11.從全局出發優化，而不是片面調整SQL 優化不能是單獨針對某一個進行，而應充分考慮系統中所有的 SQL，尤其是在通過調整索引優化 SQL 的執行計劃的時候，千萬不能顧此失彼，因小失大。

12.盡可能對每一條運行在數據庫中的SQL進行 explain優化 SQL，需要做到心中有。

轉載請注明出處華閱文章網 » mysqlor語句優化