SQL優化經歷總結。本站提示廣大學習愛好者：（SQL優化經歷總結）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL優化經歷總結正文
一. 優化SQL步調
1. 經由過程 show status和運用特色懂得各類 SQL的履行頻率
經由過程 SHOW STATUS 可以供給辦事器狀況信息，也能夠應用 mysqladmin extende d-status 敕令取得。 SHOW STATUS 可以依據須要顯示 session 級其余統計成果和 global級其余統計成果。
如顯示以後session： SHOW STATUS like "Com_%"; 全局級別：show global status;
以下幾個參數對 Myisam 和 Innodb 存儲引擎都計數：
1）. Com_select 履行 select 操作的次數，一次查詢只累加 1 ；
2）. Com_insert 履行 insert 操作的次數，關於批量拔出的 insert 操作，只累加一次 ；
3）. Com_update 履行 update 操作的次數；
4）. Com_delete 履行 delete 操作的次數；
以下幾個參數是針對 Innodb 存儲引擎計數的，累加的算法也略有分歧：
1）. Innodb_rows_read select 查詢前往的行數；
2）. Innodb_rows_inserted 履行 Insert 操作拔出的行數；
3）. Innodb_rows_updated 履行 update 操作更新的行數；
4）. Innodb_rows_deleted 履行 delete 操作刪除的行數；
經由過程以上幾個參數，可以很輕易的懂得以後數據庫的運用是以拔出更新為主還 是以查詢操作為主，和各類類型的 SQL年夜致的履行比例是若干。關於更新操作的計 數，是對履行次數的計數，豈論提交照樣回滾都邑累加。
關於事務型的運用，經由過程 Com_commit 和 Com_rollback 可以懂得事務提交和回 滾的情形，關於回滾操作異常頻仍的數據庫，能夠意味著運用編寫存在成績。另外，以下幾個參數便於我們懂得數據庫的根本情形：
1）. Connections 試圖銜接 Mysql 辦事器的次數
2）. Uptime 辦事器任務時光
3）. Slow_queries 慢查詢的次數
2. 定位履行效力較低的SQL語句
可以經由過程以下兩種方法定位履行效力較低的 SQL 語句：
1）. 可以經由過程慢查詢日記定位那些履行效力較低的 sql 語句，用 --log-slow-queries[=file_name] 選項啟動時， mysqld 寫一個包括一切履行時光跨越long_query_time 秒的 SQL 語句的日記文件。可以鏈接到治理保護中的相干章節。
2）. 應用show processlist檢查以後MYSQL的線程， 敕令慢查詢日記在查詢停止今後才記載，所以在運用反應履行效力湧現成績的時刻查 詢慢查詢日記其實不能定位成績，可使用 show processlist 敕令檢查以後 MySQL 在停止的線程，包含線程的狀況，能否鎖表等等，可以及時的檢查 SQL 履行情形， 同時對一些鎖表操作停止優化。
3）. 經由過程EXPLAIN 剖析低效 SQL的履行籌劃：
經由過程以上步調查詢到效力低的 SQL 後，我們可以經由過程 explain 或許 desc 獲得MySQL 若何履行 SELECT 語句的信息，包含 select 語句履行進程表若何銜接和銜接 的順序。
二. MySQL索引
1. mysql若何應用索引
索援用於疾速找出在某個列中有一特定值的行。對相干列應用索引是進步SELECT 操作機能的最好門路。
查詢要應用索引最重要的前提是查詢前提中須要應用索引症結字，假如是多列 索引，那末只要查詢前提應用了多列症結字最右邊的前綴時（前綴索引），才可使用索引，不然 將不克不及應用索引。
以下情形下， Mysql 不會應用已有的索引：
1）.假如 mysql 估量應用索引比全表掃描更慢，則不應用索引。例如：假如 key_part 1平均散布在 1 和 100 之間，以下查詢中應用索引就不是很好：
SELECT * FROM table_name where key_part1 > 1 and key_part1 < 90
2）.假如應用 heap 表而且 where 前提中不消＝索引列，其他 > 、 < 、 >= 、 <= 均不使 用索引（MyISAM和innodb表應用索引）；
3）.應用or朋分的前提，假如or前的前提中的列有索引，前面的列中沒有索引，那末觸及到的索引都不會應用。
4）.假如創立復合索引，假如前提中應用的列不是索引列的第一部門；（不是前綴索引）
5）.假如 like 是以％開端；
6）.對 where 後邊前提為字符串的必定要加引號，字符串假如為數字 mysql 會主動轉 為字符串，然則不應用索引。
2. 檢查索引應用情形
假如索引正在任務， Handler_read_key 的值將很高，這個值代表了一個行被索引值讀的次數，很低的值注解增長索引獲得的機能改良不高，由於索引其實不常常使 用。
Handler_read_rnd_next 的值高則意味著查詢運轉低效，而且應當樹立索引解救。這個值的寄義是在數據文件中讀下一行的要求數。假如你正停止年夜量的表掃描，
該值較高。平日解釋表索引不准確或寫入的查詢沒有益用索引。
語法：
mysql> show status like 'Handler_read%';
三. 詳細優化查詢語句
1. 查詢停止優化，應盡可能防止全表掃描
對查詢停止優化，應盡可能防止全表掃描，起首應斟酌在 where 及 order by 觸及的列上樹立索引
. 測驗考試上面的技能以免優化器錯選了表掃描：
· 應用ANALYZE TABLEtbl_name為掃描的表更新症結字散布。
· 對掃描的表應用FORCEINDEX告訴MySQL，絕對於應用給定的索引表掃描將異常耗時。
SELECT * FROM t1, t2 FORCE INDEX (index_for_column) WHERE t1.col_name=t2.col_name；
· 用--max-seeks-for-key=1000選項啟動mysqld或應用SET max_seeks_for_key=1000告訴優化器假定症結字掃描不會跨越1,000次症結字搜刮。
1). 應盡可能防止在 where 子句中對字段停止 null 值斷定
不然將招致引擎廢棄應用索引而停止全表掃描，如：
select id from t where num is null
NULL關於年夜多半數據庫都須要特別處置，MySQL也不破例，它須要更多的代碼，更多的檢討和特別的索引邏輯，有些開辟人員完整沒無意識到，創立表時NULL是默許值，但年夜多半時刻應當應用NOT NULL，或許應用一個特別的值，如0，-1作為默 認值。
不克不及用null作索引，任何包括null值的列都將不會被包括在索引中。即便索引有多列如許的情形下，只需這些列中有一列含有null，該列 就會從索引中消除。也就是說假如某列存在空值，即便對該列建索引也不會進步機能。 任安在where子句中應用is null或is not null的語句優化器是不許可應用索引的。
此例可以在num上設置默許值0，確保表中num列沒有null值，然後如許查詢：
select id from t where num=0
2). 應盡可能防止在 where 子句中應用!=或<>操作符
不然將引擎廢棄應用索引而停止全表掃描。
MySQL只要對以下操作符才應用索引：<，<=，=，>，>=，BETWEEN，IN，和某些時刻的LIKE。
可以在LIKE操作中應用索引的情況是指另外一個操作數不是以通配符（%或許_）開首的情況。例如:
SELECT id FROM t WHERE col LIKE 'Mich%'; # 這個查詢將應用索引，
SELECT id FROM t WHERE col LIKE '%ike'; #這個查詢不會應用索引。
3). 應盡可能防止在 where 子句中應用 or 來銜接前提
不然將招致引擎廢棄應用索引而停止全表掃描，如：
select id from t where num=10 or num=20
可以 應用UNION歸並查詢： select id from t where num=10 union all select id from t where num=20
在某些情形下，or前提可以免全表掃描的。
1 .where 語句外面假如帶有or前提, myisam表能用到索引， innodb不可。
2 .必需一切的or前提都必需是自力索引
mysql or前提可使用索引而防止全表
4) .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
5).上面的查詢也將招致全表掃描：
select id from t where name like '%abc%' 或許
select id from t where name like '%abc' 或許
若要進步效力，可以斟酌全文檢索。
而select id from t where name like 'abc%' 才用到索引
6). 假如在 where 子句中應用參數，也會招致全表掃描。
由於SQL只要在運轉時才會解析部分變量，但優化法式不克不及將拜訪籌劃的選擇推 遲到運轉時；它必需在編譯時停止選擇。但是，假如在編譯時樹立拜訪籌劃，變量的值照樣未知的，因此沒法作為索引選擇的輸出項。以下面語句將停止全表掃描：
select id from t where num=@num
可以改成強迫查詢應用索引： select id from t with(index(索引名)) where num=@num
7). 應盡可能防止在 where 子句中對字段停止表達式操作，
這將招致引擎廢棄應用索引而停止全表掃描。如：
select id from t where num/2=100
應改成: select id from t where num=100*2
8). 應盡可能防止在where子句中對字段停止函數操作，
這將招致引擎廢棄應用索引而停止全表掃描。如：
select id from t where substring(name,1,3)='abc' --name
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'
9).不要在 where 子句中的“=”右邊停止函數、算術運算或其他表達式運算，
不然體系將能夠沒法准確應用索引。
10). 索引字段不是復合索引的前綴索引
例如 在應用索引字段作為前提時，假如該索引是復合索引，那末必需應用到該索引中的第一個字段作為前提時能力包管體系應用該索引，不然該索引將不會被應用，而且應盡量的讓字段次序與索引次序相分歧。
2 .其他一些留意優化：
11). 不要寫一些沒成心義的查詢，
如須要生成一個空表構造：
select col1,col2 into #t from t where 1=0
這類代碼不會前往任何成果集，然則會消費體系資本的，應改成如許： create table #t(...)
12). 許多時刻用 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)
13). 其實不是一切索引對查詢都有用，
SQL是依據表中數據來停止查詢優化的，當索引列有年夜量數據反復時，SQL查詢能夠不會去應用索引，如一表中有字段sex，male、female簡直各一半，那末即便在sex上建了索引也對查詢效力起不了感化。
14). 索引其實不是越多越好，
索引雖然可以進步響應的 select 的效力，但同時也下降了 insert 及 update 的效力，由於 insert 或 update 時有能夠會重建索引，所以如何建索引須要鄭重斟酌，視詳細情形而定。一個表的索引數最好不要跨越6個，若太多則應斟酌一些不常應用到的列上建的索引能否有需要。
15).應盡量的防止更新 clustered 索引數據列，
由於 clustered 索引數據列的次序就是表記載的物理存儲次序，一旦該列值轉變將招致全部表記載的次序的調劑，會消耗相當年夜的資本。若運用體系須要頻仍更新 clustered 索引數據列，那末須要斟酌能否應將該索引建為 clustered 索引。
16).盡可能應用數字型字段，
若只含數值信息的字段盡可能不要設計為字符型，這會下降查詢和銜接的機能，並會增長存儲開支。這是由於引擎在處置查詢和銜接時會逐一比擬字符串中每個字符，而關於數字型而言只須要比擬一次就夠了。
17).盡量的應用 varchar/nvarchar 取代 char/nchar ，
由於起首變長字段存儲空間小，可以節儉存儲空間，其次關於查詢來講，在一個絕對較小的字段內搜刮效力明顯要高些。
18).最好不要應用"*"前往一切： select * from t ，
器具體的字段列表取代“*”，不要前往用不到的任何字段。
3. 暫時表的成績：
19). 盡可能應用表變量來取代暫時表。
假如表變量包括年夜量數據，請留意索引異常無限（只要主鍵索引）。
20).防止頻仍創立和刪除暫時表，以削減體系表資本的消費。
21).暫時表其實不是弗成應用，
恰當地應用它們可使某些例程更有用，例如，當須要反復援用年夜型表或經常使用表中的某個數據集時。然則，關於一次性事宜，最好應用導出表。
22).在新建暫時表時，假如一次性拔出數據量很年夜，那末可使用 select into 取代 create table，防止形成年夜量 log ，以進步速度；
假如數據量不年夜，為了緊張體系表的資本，應先create table，然後insert。
23). 假如應用到了暫時表，在存儲進程的最初務勢必一切的暫時表顯式刪除，先 truncate table ，然後 drop table ，如許可以免體系表的較長時光鎖定。
4. 游標的成績：
24).盡可能防止應用游標，
由於游標的效力較差，假如游標操作的數據跨越1萬行，那末就應當斟酌改寫。
25).應用基於游標的辦法或暫時表辦法之前，
應先尋覓基於集的處理計劃來處理成績，基於集的辦法平日更有用。
26).與暫時表一樣，游標其實不是弗成應用。
對小型數據集應用 FAST_FORWARD 游標平日要優於其他逐行處置辦法，特別是在必需援用幾個表能力取得所需的數據時。在成果集中包含“算計”的例程平日要比應用游標履行的速度快。假如開辟時光許可，基於游標的辦法和基於集的辦法都可以測驗考試一下，看哪種辦法的後果更好。
27).在一切的存儲進程和觸發器的開端處設置 SET NOCOUNT ON ，在停止時設置 SET NOCOUNT OFF 。
無需在履行存儲進程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 新聞。
5. 事務的成績：
28).盡可能防止年夜事務操作，進步體系並發才能。
6. 數據量的成績
29).盡可能防止向客戶端前往年夜數據量，若數據量過年夜，應當斟酌響應需求能否公道。
7. COUNT優化：
30) count(*) 優於count(1)和count(primary_key)
許多工資了統計記載條數，就應用 count(1) 和 count(primary_key) 而不是 count(*) ，他們以為如許機能更好，其實這是一個誤區。關於有些場景，如許做能夠機能會更差，應為數據庫對 count(*) 計數操作做了一些特殊的優化。
31）count(column) 和 count(*) 是紛歧樣的
這個誤區乃至在許多的資深工程師或許是 DBA 中都廣泛存在，許多人都邑以為這是天經地義的。現實上，count(column) 和 count(*) 是一個完整紛歧樣的操作，所代表的意義也完整紛歧樣。
count(column) 是表現成果集中有若干個column字段不為空的記載
count(*) 是表現全部成果集有若干筆記錄
8. 優化order by語句
基於索引的排序
MySQL的弱點之一是它的排序。固然MySQL可以在1秒中查詢年夜約15,000筆記錄，但因為MySQL在查詢時最多只能應用一個索引。是以，假如WHERE前提曾經占用了索引，那末在排序中就不應用索引了，這將年夜年夜下降查詢的速度。我們可以看看以下的SQL語句:
SELECT * FROM SALES WHERE NAME = “name” ORDER BY SALE_DATE DESC;
在以上的SQL的WHERE子句中曾經應用了NAME字段上的索引，是以，在對SALE_DATE停止排序時將不再應用索引。為懂得決這個成績，我們可以對SALES表樹立復合索引:
ALTER TABLE SALES DROP INDEX NAME, ADD INDEX (NAME,SALE_DATE)
如許再應用上述的SELECT語句停止查詢時速度就會年夜副晉升。但要留意，在應用這個辦法時，要確保WHERE子句中沒有排序字段，在上例中就是不克不及用SALE_DATE停止查詢，不然固然排序快了，然則SALE_DATE字段上沒有零丁的索引，是以查詢又會慢上去。
在某些情形中， MySQL可使用一個索引來知足 ORDER BY子句，而不須要額定的排序。 where前提和order by應用雷同的索引，而且order by 的次序和索引次序相 同，而且order by的字段都是升序或許都是降序。例如：以下sql可使用索引。
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;
然則以下情形不應用索引：
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC ； --order by 的字段混雜 ASC 和 DESC
SELECT * FROM t1 WHERE key2=constant ORDER BY key1 ；-- 用於查詢行的症結字與 ORDER BY 中所應用的不雷同
SELECT * FROM t1 ORDER BY key1, key2 ；-- 對分歧的症結字應用 ORDER BY ：
9. 優化GROUP BY
默許情形下， MySQL 排序一切 GROUP BY col1 ， col2 ， .... 。查詢的辦法好像在查詢中指定 ORDER BY col1 ， col2 ， ... 。假如顯式包含一個包括雷同的列的 ORDER BY
子句， MySQL 可以絕不加速地對它停止優化，雖然依然停止排序。假如查詢包含 GROUP BY 但你想要防止排序成果的消費，你可以指定 ORDER BY NULL制止排序。
例如 ：
INSERT INTO foo SELECT a, COUNT(*) FROM bar GROUP BY a ORDER BY NULL;
10. 優化 OR
詳細詳解看：mysql or前提可使用索引而防止全表
四. Explain說明解釋
explain顯示了mysql若何應用索引來處置select語句和銜接表。可以贊助選擇更好的索引和寫出更優化的查詢語句。
應用辦法，在select語句前加上explain便可以了：
如：
explain select surname,first_name form a,b where a.id=b.id
剖析成果情勢以下：
table | type | possible_keys | key | key_len | ref | rows | Extra
EXPLAIN列的說明：
1 table:
顯示這一行的數據是關於哪張表的
2 type:
這是主要的列，顯示銜接應用了何品種型。從最好到最差的銜接類型為：system、const、eg_reg、ref、ref_or_null、 range、indexhe、 ALL。
system:表唯一一行(=體系表)。這是const聯接類型的一個特例
const:(PRIMARY KEY或UNIQUE)
表最多有一個婚配行，它將在查詢開端時被讀取。由於唯一一行，在這行的列值可被優化器殘剩部門以為是常數。
const表很快，由於它們只讀取一次！
const用於用常數值比擬PRIMARY KEY或UNIQUE索引的一切部門時。
鄙人面的查詢中，tbl_name可以用於const表：
SELECT * from tbl_name WHERE primary_key=1；
eq_reg:key
關於每一個來自於後面的表的行組合，從該表中讀取一行。這能夠是最好的聯接類型，除const類型。
它用在一個索引的一切部門被聯接應用而且索引是UNIQUE或PRIMARY KEY。
eq_ref可以用於應用= 操作符比擬的帶索引的列。比擬值可認為常量或一個應用在該表後面所讀取的表的列的表達式。
鄙人面的例子中，MySQL可使用eq_ref聯接來處置ref_tables：
SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;
SELECT * FROM ref_table,other_table WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;
ref:key
關於每一個來自於後面的表的行組合，一切有婚配索引值的即將從這張表中讀取。假如聯接只應用鍵的最右邊的前綴，或假如鍵不是UNIQUE或PRIMARY KEY（換句話說，假如聯接不克不及基於症結字選擇單個行的話），則應用ref。
假如應用的鍵僅僅婚配大批行，該聯接類型是不錯的。
ref可以用於應用=或<=>操作符的帶索引的列。
鄙人面的例子中，MySQL可使用ref聯接來處置ref_tables：
SELECT * FROM ref_table WHERE key_column=expr;
SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;
SELECT * FROM ref_table,other_table WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;
ref_or_null:Or Is null
該聯接類型好像ref，然則添加了MySQL可以專門搜刮包括NULL值的行。在處理子查詢中常常應用該聯接類型的優化。
鄙人面的例子中，MySQL可使用ref_or_null聯接來處置ref_tables：
SELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;
range:=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或許IN
只檢索給定規模的行，應用一個索引來選擇行。key列顯示應用了哪一個索引。
key_len包括所應用索引的最長症結元素。在該類型中ref列為NULL。
當應用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或許IN操作符，用常量比擬症結字列時，可使用range：
SELECT * FROM tbl_name WHERE key_column = 10;
SELECT * FROM tbl_name WHERE key_column BETWEEN 10 and 20;
SELECT * FROM tbl_name WHERE key_column IN (10,20,30);
SELECT * FROM tbl_name WHERE key_part1= 10 AND key_part2 IN (10,20,30);
indexhe:
該聯接類型與ALL雷同，除只要索引樹被掃描。這平日比ALL快，由於索引文件平日比數據文件小。
當查詢只應用作為單索引一部門的列時，MySQL可使用該聯接類型。
ALL：
關於每一個來自於先前的表的行組合，停止完全的表掃描。假如表是第一個沒標志const的表，
這平日欠好，而且平日在它情形下很差。平日可以增長更多的索引而不要應用ALL，
使得行能基於後面的表中的常數值或列值被檢索出。
3 possible_keys :
顯示能夠運用在這張表中的索引。假如為空，沒有能夠的索引。可認為相干的域從WHERE語句中
選擇一個適合的語句
4 key ：
現實應用的索引。假如為NULL，則沒有應用索引。很少的情形下，MYSQL會選擇優化缺乏的索引 。
這類情形下，可以在SELECT語句中應用USEINDEX（indexname）來強迫應用一個索引或許用IGNORE INDEX（indexname）來強迫MYSQL疏忽索引
5key_len:
應用的索引的長度。在不喪失准確性的情形下，長度越短越好
6 ref
顯示索引的哪一列被應用了，假如能夠的話，是一個常數
7 rows
MYSQL以為必需檢討的用來前往要求數據的行數 (掃描行的數目)
8 Extra
該列包括MySQL處理查詢的具體信息
關於MYSQL若何解析查詢的額定信息。將在表4.3中評論辯論，但這裡可以看到的壞的例子是Using temporary和Using filesort，
意思MYSQL基本不克不及應用索引，成果是檢索會很慢
extra列前往的描寫的意義
Distinct:
一旦MYSQL找到了與行相結合婚配的行，就不再搜刮了
Not exists :
MYSQL優化了LEFT JOIN，一旦它找到了婚配LEFT JOIN尺度的行， 就不再搜刮了
面是一個可以如許優化的查詢類型的例子：
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL；
假定t2.id界說為NOT NULL。在這類情形下，MySQL應用t1.id的值掃描t1並查找t2中的行。
假如MySQL在t2中發明一個婚配的行，它曉得t2.id毫不會為NULL，而且不再掃描t2內有雷同的id值的行。
換句話說，關於t1的每一個行，MySQL只須要在t2中查找一次，不管t2內現實有若干婚配的行。
Range checked for each Record（index map:#）
沒有找到幻想的索引，是以關於早年面表中來的每個行組合，MYSQL檢討應用哪一個索引，並用它來從表中前往行。
這是應用索引的最慢的銜接之一
MySQL沒有發明好的可使用的索引，但發明假如來自後面的表的列值已知，能夠部門索引可使用。
對後面的表的每一個行組合，MySQL檢討能否可使用range或index_merge拜訪辦法來討取行。
關於實用性尺度的描寫拜見7.2.5節，“規模優化”和7.2.6節，“索引歸並優化”，
分歧的是後面表的一切列值已知而且以為是常量。這其實不很快，但比履行沒有索引的聯接要快很多。
Using filesort
看到這個的時刻，查詢就須要優化了。MYSQL須要停止額定的步調來發明若何對前往的行排序。
它依據銜接類型和存儲排序鍵值和婚配前提的全體行的行指針來排序全體行
Using index
列數據是從僅僅應用了索引中的信息而沒有讀取現實的行為的表前往的，
這產生在對表的全體的要求列都是統一個索引的部門的時刻
Using temporary
看到這個的時刻，查詢須要優化了。這裡，MYSQL須要創立一個暫時表來存儲成果，這平日產生在對分歧的列集停止ORDER BY上，而不是GROUP BY上
Using where
應用了WHERE從句來限制哪些即將與下一張表婚配或許是前往給用戶。假如不想前往表中的全體行，
而且銜接類型ALL或index，這就會產生，或許是查詢有成績
Impossible WHERE noticed after reading const table...
五 SQL焦點語句(異常適用的幾個技能)
1) 拔出數據
批量拔出:
INSERT mytable (first_column,second_column,third_column)
VALUES ('some data','some more data','yet more data') ,
VALUES ('some data','some more data','yet more data') ,
VALUES ('some data','some more data','yet more data')
2）.清空數據表
TRUNCATE TABLE `mytable`
留意：刪除表中的一切記載，應應用TRUNCATE TABLE語句。留意這裡為何要用TRUNCATE TABLE語句取代DELETE語句:當你應用TRUNCATE TABLE語句時，記載的刪除是不作記載的。也就是說，這意味著TRUNCATE TABLE要比DELETE快很多。
3）用SELECT創立記載和表
INSERT語句與DELETE語句和UPDATE語句有一點分歧，它一次只操作一個記載。但是，有一個辦法可使INSERT 語句一次添加多個記載。要作到這一點，你須要把INSERT語句與SELECT語句聯合起來，象如許:
INSERT mytable(first_column,second_column) SELECT another_first,another_second FROM anothertable WHERE another_first='Copy Me!';
這個語句從anothertable拷貝記載到mytable.只要表anothertable中字段another_first的值為'Copy Me!'的記載才被拷貝。
當為一個表中的記載樹立備份時，這類情勢的INSERT語句長短常有效的。在刪除一個表中的記載之前，你可以先用這類辦法把它們拷貝到另外一個表中。
假如你須要拷貝全部表，你可使用SELECT INTO語句。例如，上面的語句創立了一個名為newtable的新表，該表包括表mytable的一切數據:
SELECT * INTO newtable FROM mytable;
你也能夠指定只要特定的字段被用來創立這個新表。要做到這一點，只需在字段列表中指定你想要拷貝的字段。別的，你可使用WHERE子句來限制拷貝到新表中的記載。上面的例子只拷貝字段second_columnd的值等於'Copy Me!'的記載的first_column字段。
SELECT first_column INTO newtable FROM mytable WHERE second_column='Copy Me!';
應用SQL修正曾經樹立的表是很艱苦的。例如，假如你向一個表中添加了一個字段，沒有輕易的方法往來來往除它。別的，假如你不當心把一個字段的數據類型給錯了，你將沒有方法轉變它。然則，應用本節中講述的SQL語句，你可以繞過這兩個成績。
例如，假定你想從一個表中刪除一個字段。應用SELECT INTO語句，你可以創立該表的一個拷貝，但不包括要刪除的字段。這使你既刪除該字段，又保存了不想刪除的數據。
假如你想轉變一個字段的數據類型，你可以創立一個包括准確數據類型字段的新表。創立好該表後，你便可以聯合應用UPDATE語句和SELECT語句，把本來表中的一切數據拷貝到新表中。經由過程這類辦法，你既可以修正表的構造，又能保留原本的數據。
以上就是整頓的SQL優化經歷，願望對年夜家的進修有所贊助。
