專題查詢優(yōu)化使用索引安全隱患事務與鎖

1、 MYSQL專題 1. 查詢優(yōu)化2. 使用索引3. 安全隱患4. 事務與鎖 作者：鄺偉林 梧桐網絡工作室MySQL優(yōu)化查詢操作數(shù)據(jù)庫最重要的一個環(huán)節(jié)就是查詢，如何優(yōu)化數(shù)據(jù)庫查詢加快查詢速度與最優(yōu)化數(shù)據(jù)庫空間顯得尤為重要，下面我將從多個方面以分析原理與具體采取怎樣的措施的方式進行講解。(一)給字段選取最合適的數(shù)據(jù)類型選擇CHAR還是VARCHAR ?我們知道，這兩個屬性都是給字符分配空間的，一個是定長，一個是變長，對于使用MyISAM數(shù)據(jù)存儲引擎的表，在能夠比較事先確定長度的情況下，比如一個郵政編碼，最好使用CHAR類型,因為查詢定長的數(shù)據(jù)比查詢變長的數(shù)據(jù)要快，再則，盡可能地將字段的寬度設得小些

2、，以免增加不必要的空間；對于MEMORY數(shù)據(jù)表，由于目前都使用固定長度的數(shù)據(jù)行存儲，因此無論使用CHAR或VARCHAR列都沒有關系，兩者都是作為CHAR類型處理的。對于InnoDB數(shù)據(jù)表，內部的行存儲格式沒有區(qū)分固定長度和可變長度列（所有數(shù)據(jù)行都使用指向數(shù)據(jù)列值的頭指針），因此在本質上，使用固定長度的 CHAR列不一定比使用可變長度VARCHAR列簡單。因而，主要的性能因素是數(shù)據(jù)行使用的存儲總量。由于CHAR平均占用的空間多于VARCHAR，因此使用VARCHAR來最小化需要處理的數(shù)據(jù)行的存儲總量和磁盤I/O是比較好的。 需要注意的是，如果MySQL運行在嚴格模式，使用CHAR類型時超過列長

3、度的值將不被保存，并且會出現(xiàn)錯誤；再則，諸如CHAR(10)與VARCHAR(10)檢索到的值并不總是相同，因為CHAR列會刪除尾部的空格，而VARCHAR列會保留尾部的空格。在選擇FLOAT/DOUBLE/REAL（浮點數(shù)）時需要說明的是浮點數(shù)能夠表示更大的數(shù)據(jù)范圍，但會引起精度的問題，即，類型為浮點數(shù)的字段值比如123456.31，檢索出來時值可能會是123456.30，這時如果用于做數(shù)據(jù)的比較時就可能出錯，要避免這個問題。同理，給數(shù)值類型選擇字段屬性時，盡可能地減小字段的寬度，如可以使用MEDIUMINT滿足要求的情況就不要將字段設置為BIGINT,以節(jié)省空間，而一旦表占用的空間越小，檢

4、索的速度就會越快。(二)BLOB與TEXT的問題第一：在對設置為BLOB和TEXT字段屬性的值做大量的刪除或更新操作的時，這種值會在數(shù)據(jù)表中留下很大的"空洞"，以后填入這些"空洞"的記錄可能長度不同,為了提高性能,建議定期使用 OPTIMIZE TABLE 功能對這類表進行碎片整理. 第二：在有BLOB或TEXT時，盡可能地避免使用：select *.，這樣的查詢語句，因為這樣可能會引起大量的值在網絡上做無謂的傳輸，此時，我的建議是你可以把有BLOB或TEXT的字段單獨拿出來用另外一個表來存儲，這樣就可以避免做無謂的檢索大型的值；還有一種方法就是使用合成

5、的索引，它是根據(jù)其它的列的內容（或使用MD5，SHA1,CRC32等函數(shù)）建立一個散列值，并把這個值存儲在單獨的數(shù)據(jù)列中，通過檢索散列值來找到數(shù)據(jù)行，用散列標識符值查找的速度比搜索BLOB或TEXT列本身的速度快很多。(三)使用NOT NULL把數(shù)據(jù)列定義成不能為空（NOT NULL），這樣有利于簡化查詢，因為不需要檢查值的NULL屬性，有利于檢索引擎做出判斷。(四)使用ENUM如果你擁有的某個數(shù)據(jù)列的基數(shù)很低（包含的不同的值數(shù)量有限），那么可以考慮把它轉換為ENUM列。ENUM值可以被更快地處理，因為它們在內部表現(xiàn)為數(shù)值,通常，檢索數(shù)值要比檢索字符文本要快。(五)優(yōu)化GROUP BY 語句默

6、認情況下，MySQL排序所有GROUP BY 包含的字段，為了避免排序結果的消耗，你可以指定ORDER BY NULL禁止排序。(六)優(yōu)化JOIN 語句Mysql4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創(chuàng)建一個單列的查詢結果，然后把這個結果作為過濾條件用在另一個查詢中。使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，并且寫起來也很容易。但是，有些情況下，子查詢可以被更有效率的連接(JOIN) 替代。 假設我們要將所有沒有訂單記錄的用戶取出來，可以用下面這個子查詢方式完成： SELECT * FROM customeri

7、nfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 如果使用連接(JOIN)來完成這個查詢工作，速度將會快很多。尤其是當salesinfo表中對CustomerID建有索引的話，性能將會更好，查詢如下： SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo.CustomerID WHERE salesinfo.CustomerID IS NULL 連接(JOIN)之所以更有效率一些，是因為 MySQL不需要在

8、內存中創(chuàng)建臨時表來完成這個邏輯上的需要兩個步驟的查詢工作。(七)使用查詢緩存(mysql query cache)查詢緩存的功能在于存儲SELECT查詢的文本以及發(fā)送給客戶端的相應結果。如果隨后收到一個相同的查詢，服務器會從查詢緩存中重新得到查詢結果，而不再需要解析和執(zhí)行查詢，這樣可以大大提高那些重復執(zhí)行的SELECT語句的處理速度。查詢緩存是基于服務器所接收到的查詢字符串的文本內容的。如果某些查詢的文本完全相同，那它就認為這些查詢是相同的。如果某些查詢的字符不同，或者來自那些使用了不同的字符集或通訊協(xié)議的客戶端，那么它會認為這些查詢是不同的。同樣，如果某些查詢采用其它的功能相當、但實際上沒有

9、指向相同的數(shù)據(jù)表（例如引用了不同的數(shù)據(jù)庫中的同名數(shù)據(jù)表），那么它們也是不同的。當數(shù)據(jù)表被更新了之后，涉及到該數(shù)據(jù)表的任何緩存查詢都變成無效的，并且會被丟棄;這可以防止服務器返回過期的結果。 在默認情況下，MySQL對查詢緩存的支持是內建的。如果你不希望使用這種緩存，并且想避免它所導致的性能開銷，可以使用-without-query-cache選項來運行配置腳本建立服務器。關于查詢緩存的操作有一下幾個系統(tǒng)變量需要掌握：have_query_cache檢查服務器是否支持查詢緩存使用語句：SHOW VARIABLES LIKE 'have_query_cache'query_cach

10、e_type查詢緩存的操作模式它有三個模式值：0:不要緩存查詢結果或檢索緩存的結果;1:緩存查詢，除非它們以SELECT SQL_NO_CACHE開頭;2:根據(jù)需要只緩存那些以SELECT SQL_CACHE開頭的query_cache_size決定分配給緩存的內存數(shù)量，單位是字節(jié)說明：即使query_cache_type的值設置為零，query_cache_size指定內存數(shù)量也會被分配。為了避免浪費內存，只有在希望激活緩存 的時候才把大小設置成大于零。同時，即使query_cache_type不為零，查詢緩存的大小設置為零也會禁用緩存。query_cache_limit設置被緩存的最大結果

11、集大小,比這個值大的查詢結果不會被緩存說明：SELECT SQL_CACHE語句會讓查詢結果被緩存；SELECT SQL_NO_CACHE語句會使查詢結果不被緩存；它們并不會受到緩存模式的影響，前提是服務器支持查詢緩存并分配了內存大小。使用索引使用索引屬于優(yōu)化查詢的范疇，我把它單獨成章來講解，是為了突出它的重要性。關于索引，我將以下面幾個方面來闡述：(1)索引的工作原理(2)索引的創(chuàng)建方式(3)設計索引的要點(4)控制MySQL對索引的使用(5)正視使用索引的缺陷(一)索引的工作原理當你在一張沒有索引的表里進行某種查詢時，服務器會從表的第一行開始逐條進行查找，即使在中間段就已經找到了匹配的數(shù)據(jù)

12、行，它仍然會繼續(xù)往下找，直到表尾。如果這張表的數(shù)據(jù)行數(shù)量很大，比如成千上萬條，那么，這種查詢肯定會耗去很大部分的時間。 使用索引的表的查詢方式就不同，當在某列上面使用索引后，該索引就包含了該列每行數(shù)值的有序排列和指向各自實際位置的"指針"，查詢時，服務器不是逐行地查看數(shù)據(jù)表，而是首先掃描索引，掃描索引時，也不必從索引頭進行線性掃描，而是使用定位算法快速地找到第一條匹配的索引條目，由于索引是事先排序過的，所以，一旦發(fā)現(xiàn)了不匹配的記錄，就會終止對索引的掃描。通過索引便能夠快速地找到查找的數(shù)據(jù)行。為什么索引能過快速地找到相應的數(shù)據(jù)行呢？這是因為索引采用了某種數(shù)據(jù)結構進行查找，不同

13、的MySQL存儲引擎，索引采用的數(shù)據(jù)結構也有所區(qū)別，對于MyISAM數(shù)據(jù)表，使用的是R樹索引，并且索引與數(shù)據(jù)使用單獨的文件存儲，即MYI與MYD文件;MEMORY(HEAP)存儲引擎使用hash索引，但也支持B-樹索引,其它的引擎大多使用B樹索引，只有MyISAM支持空間類型，使用了R樹。舉例說明：現(xiàn)有三張表Table1,Table2,Table3,其中Name字段使用了索引，我們的查詢任務是查找出表1中在另外兩張表中都出現(xiàn)的的名字,查詢語句可能為：select Table1.Name from Table1,Table2,Table3 where Table2.Name=Table1.Nam

14、e and Table3.Name=Table2.Name查詢流程如下圖：我們來比較一下不使用索引與使用索引的查詢方式：不使用索引時，存儲引擎會掃描所有的數(shù)據(jù)行，即，如果每個表的行數(shù)都為1000行的情況下就得查找1000 x 1000 x 1000(10億！)，可能是匹配記錄數(shù)量的上百萬倍，明顯的浪費了大量的工作，導致性能下降；而使用索引時，它的流程是這樣的：(1)選擇表1中的第一行并查看該數(shù)據(jù)行的值.(2)使用表2的索引，直接定位到與表1的值匹配的數(shù)據(jù)行；類似地，使用表3上的索引，直接定位到與表2的值匹配的數(shù)據(jù)行。(3)處理表1的下一行并重復前面的過程。執(zhí)行這樣的操作直到t1中的所有數(shù)據(jù)行都

15、被檢查過。在這種情況下，我們仍然對表1執(zhí)行了完整的掃描，但是我們可以在表2和表3上執(zhí)行索引查找，從這些表中直接地獲取數(shù)據(jù)行。理論上采用這種方式運行上面的查詢會快一百萬倍。(二)創(chuàng)建索引的方式索引有三種類型：(1)主鍵索引，即primary key,只能在創(chuàng)建表時創(chuàng)建；(2)唯一值索引，即unique key,值不能重復；(3)普通索引，即 key,值可以重復。可以在創(chuàng)建表時就創(chuàng)建索引，方式為： PRIMARY|UNIQUE KEY (col_name);比如：create table book(isbn int unsigned not null,title varchar(50) not n

16、ull,author char(20) not null,unique key isbn(isbn),key autor(author)engin=myisam default charset=utf8也可以在表創(chuàng)建完畢后創(chuàng)建索引： CREATE UNIQUEINDEX index_name ON table_name(col_name(length),col_name(lenght);比如：create unique index isbn on book(isbn(5); (三)設計索引時要考慮到的1.索引所在列最好是出現(xiàn)在where，order by等子句中的列，而不是出現(xiàn)在select關

17、鍵字后選擇列表中的列,因為索引最大的特點在于根據(jù)查詢條件快速定位到查詢的數(shù)據(jù)行中；2.對于重復值少的列進行索引，如果滿足查詢的結果占整個表記錄的30%以上時MySQL會自動放棄使用索引，所以這時你設置的索引并不能起到作用，比如你把一張表的性別字段設置為索引，那么，索引指向的數(shù)據(jù)行有可能是整個表數(shù)據(jù)行的50%，這是沒有意義的，何況這樣還會把時間浪費在索引排序上；如果重復值少，索引指向的數(shù)據(jù)行范圍就會越窄，查詢速度就會大幅度加快。3.利用短索引，即指定索引的前綴長度，例如，如果有一個CHAR(200) 列，如果在前10個或20個字符內，多數(shù)值是惟一的，那么就不要對整個列進行索引。對前10個或20個

18、字符進行索引能夠節(jié)省大量索引空間，也可能會使查詢更快。較小的索引涉及的磁盤I/O 較少，較短的值比較起來更快。更為重要的是，對于較短的鍵值，索引高速緩存中的塊能容納更多的鍵值。4.不要過多地索引。不要認為"索引越多，性能越高"，不要對每個數(shù)據(jù)列都進行索引。每個額外的索引都會花費更多的磁盤空間，并降低寫操作的性能。當你修改表的內容的時候，索引就必須被更新，甚至可能重新整理。如果你的索引很少使用或永不使用，你就沒有必要減小表的修改操作的速度。此外，為檢索操作生成執(zhí)行計劃的時候，MySQL會考慮采用哪一個索引，建立額外的索引會給查詢優(yōu)化器增加更多的工作量，如果索引太多，有可能（未

19、必）出現(xiàn)MySQL選擇最優(yōu)索引失敗的情況，維護自己必須的索引可以幫助查詢優(yōu)化器來避免這類錯誤。對于如何控制MySQL選擇最優(yōu)索引接下來我會談到。5.利用最左前綴。在創(chuàng)建一個n列的索引時,實際是創(chuàng)建了MySQL可利用的n個索引。多列索引可起幾個索引的作用，因為可利用索引中最左邊的列集來匹配行。這樣的列集稱為最左前綴。（這與索引一個列的前綴不同，索引一個列的前綴是利用該的前n 個字符作為索引值。）例如當你準備給索引過的表添加索引時，你可以先考慮下將增加的索引是否是已有的多列索引的最左前綴，如果是這樣的，就不用再增加索引。(四)控制MySQL對索引的使用一般情況下，在查詢時MySQL將自己決定是否使

20、用索引，使用哪一個索引。但在一些特殊情況下，我們希望MySQL只使用一個或幾個索引，或者不希望使用某個索引。這就需要使用MySQL的控制索引的一些查詢選項。(1)限制使用索引的范圍:USE INDEX有時我們在數(shù)據(jù)表里建立了很多索引，當MySQL對索引進行選擇時，這些索引都在考慮的范圍內。但有時我們希望MySQL只考慮幾個索引，而不是全部的索引，這就需要用到USE INDEX對查詢語句進行設置;比如:SELECT * FROM TABLE1 USE INDEX (FIELD1, FIELD2);這時，無論在TABLE1中已經建立了多少個索引，MySQL在選擇索引時，只考慮在FIELD1和FIE

21、LD2上建立的索引。(2)限制不使用索引的范圍:IGNORE INDEX如果我們要考慮的索引很多，而不被使用的索引又很少時，可以使用IGNORE INDEX進行反向選取;比如:SELECT * FROM TABLE1 IGNORE INDEX (FIELD1, FIELD2);這時，TABLE1表中FIELD1和FIELD2上的索引不被使用。(3)強迫使用某一個索引:FORCE INDEX有時我們希望MySQL必須要使用某一個索引(由于 MySQL在查詢時只能使用一個索引，因此只能強迫MySQL使用一個索引)。這就需要使用FORCE INDEX來完成這個功能;比如:SELECT * FROM

22、TABLE1 FORCE INDEX (FIELD1);這時,只使用建立在FIELD1上的索引，而不使用其它字段上的索引。(五)正視索引的缺陷首先，索引加快了檢索的速度，但是減慢了插入和刪除的速 度，同時還減慢了更新被索引的數(shù)據(jù)列中的值的速度。也就是說，索引減慢了大多數(shù)涉及寫操作的速度。發(fā)生這種現(xiàn)象的原因在于寫入一條記錄的時候不但需要寫入 數(shù)據(jù)行，還需要改變所有的索引。數(shù)據(jù)表帶有的索引越多，需要做出的修改就越多，平均性能的降低程度也就越大;所以對于寫操作更頻繁而需檢索查詢很少的表，最好不要設置索引。其次，索引會花費磁盤空間，多個索引相應地花費更多的磁盤空間。這可能導致更快地到達數(shù)據(jù)表的大小限制

23、. 對于MyISAM表，頻繁地索引可能引起索引文件比數(shù)據(jù)文件更快地達到最大限制;對于BDB表，它把數(shù)據(jù)和索引值一起存儲在同一個文件中，添加索引引起這種表更快地達到最大文件限制; 在InnoDB的共享表空間中分配的所有表都競爭使用相同的公共空間池，因此添加索引會更快地耗盡表空間中的存儲。但是，與MyISAM和BDB表使用的文件不同，InnoDB共享表空間并不受操作系統(tǒng)的文件大小限制，因為我們可以把它配置成使用多個文件。只要有額外的磁盤空間，你就可以通過添加新組件來 擴展表空間;使用單獨表空間的InnoDB表與BDB表受到的約束是一樣的，因為它的數(shù)據(jù)和索引值都存儲在單個文件中;所以，如果你不需要使

24、用特殊的索引幫助查詢執(zhí)行得更快，就不要建立索引。到此，我們?yōu)椴樵儍?yōu)化與使用索引做一番總結從上面的分析我們不難得出以下幾點優(yōu)化原則：第一：設置表的字段時要恰當，盡可能地減小字段占用空間；第二：SQL查詢語句要采用優(yōu)化方式，并且避免對大宗量的數(shù)據(jù)段做無謂的檢索；第三：使服務器盡可能地從緩存區(qū)獲取數(shù)據(jù)，少指向內存或磁盤；第四：合理地使用索引，可以極大地提高服務器性能和查詢速度;第五：對數(shù)據(jù)庫的操作，一定要注重優(yōu)化措施，特別是有大宗量的訪問時更是如此，當然，關于優(yōu)化還有更多的細節(jié)需要我們掌握好。 安全隱患數(shù)據(jù)庫的安全隱患來自多方面，比如權限設置不恰當，服務器系統(tǒng)本身存在漏洞等等，下面我以SQL注入為例

25、講解數(shù)據(jù)庫的安全隱患，以及如何采取防范措施。什么是SQL注入？它是如何入侵數(shù)據(jù)庫系統(tǒng)的？首先用一個簡單的示例展示SQL如何注入的：如果程序員對用戶傳遞的數(shù)據(jù)沒有進行處理，使用下面的查詢語句：$page=$_GET"p"$sql="select * from tb where page_id='$page'". 在正常輸入的情況下，用戶進入查詢某條信息時，地址欄可能是這樣的： 這時你在該地址的后面加入SQL語句，比如簡單地輸入 "and 1=2",即地址欄里是這樣的： 如果出現(xiàn)返回錯誤信息的情況，就可以確定數(shù)據(jù)庫存在注入

26、的漏洞，通過采取一系列有針對性的SQL盲注技術，最終非法地獲取操控數(shù)據(jù)庫系統(tǒng)的權限。SQL注入是存在于常見的多連接的應用程序中一種漏洞，攻擊者通過在應用程序中預先定義好的查詢語句結尾加上額外的SQL語句元素，欺騙數(shù)據(jù)庫服務器執(zhí)行非授權的任意查詢。這類應用程序一般是網絡應用程序，它允許用戶輸入查詢條件，并將查詢條件嵌入SQL請求語句中，發(fā)送到與該應用程序相關聯(lián)的數(shù)據(jù)庫服務器中去執(zhí)行。通過構造一些畸形的輸入，攻擊者能夠操作這種請求語句去獲取預先未知的結果.SQL注入攻擊利用的是SQL語法，這使得這種攻擊具有廣泛性。理論上說，對于所有基于SQL語言標準的數(shù)據(jù)庫軟件包括SQL Server，Oracl

27、e，MySQL, DB2，Informix等以及與之連接的網絡應用程序包括Active/Java Server Pages, Cold Fusion Management, PHP或Perl等都是有效的。當然各種軟件有自身的特點，實際的攻擊代碼可能不盡相同。SQL注入的一般步驟是這樣的：第一步，首先像上述那樣簡單地在地址欄加入SQL語句判斷是否存在注入漏洞；第二步，根據(jù)各種數(shù)據(jù)庫使用的SQL語句上的差異，如，不同的SQL服務器連結字符串的語法不同，MS SQL Server使用符號"+"來連結字符串，Oracle使用符號"|"來連結，MySQL使用符號&

28、quot;.",進行試探，得出數(shù)據(jù)庫的類型；第三步，使用ORDER BY 加數(shù)字的方式試探出字段數(shù)，這是為了UNION SELECT 語句做準備的；第四步，通過ORDER BY得出字段數(shù)后，再用UNION SELECT 匹配字段數(shù)目n-1個NULL值，另外一個在字符，數(shù)值，時間類型的值里一一試探，直到可以確定每個字段的數(shù)據(jù)類型；第五步，在明確了字段數(shù)與數(shù)據(jù)類型后，就可以大大地發(fā)揮UNION SELECT 語句的功效了，包括試探出管理員帳號，密碼所在表名字段名。至于SQL注入的詳細過程我在此就點到為止了，我只是提醒網站開發(fā)程序員要注意對用戶傳遞過來的數(shù)據(jù)進行嚴格的檢查，不能讓非法的語句

29、成為SQL查詢條件的一部分。防止SQL注入攻擊的防御手段從上面談到的可以看出，SQL之所以能夠成功注入，就是讓注入者利用了SQL語法上的特點進行攻擊的，如何讓傳遞的數(shù)據(jù)在SQL語句中安全使用，是我們采取防御手段的核心所在。對此，我們可以從一下幾個方面防御SQL注入：(1)在有必要的情況下，對提交的數(shù)據(jù)進行客戶端與服務器端兩重的的合法性檢驗，確保服務器按我們指定的方式正常執(zhí)行；(2)屏蔽出錯信息，因為粗錯信息里大都包含了了一些重要信息，比如目錄，甚至與數(shù)據(jù)庫有關的信息都會因此出來；(3)替換或刪除敏感的字符或字符串；(4)對于潛在的而難以預料的錯誤，比如可能是服務器本身的問題，可以使用跳轉頁面的

30、方式，以免因此暴露信息；(5)對于PHP+MySQL，要充分利用好異常處理與錯誤處理（專題PHP對此做了講述）. 事務與鎖（一）事務(Transaction)什么是事務？事務（transation）指的是能夠使對數(shù)據(jù)庫的一系列操作，要么都成功，要么都失敗的一種機制。事務有什么用？它的作用就在于能夠保證彼此有制約有關聯(lián)的操作成為一個有機的整體，即使發(fā)生了錯誤，或服務器崩潰的情況下，也能保證數(shù)據(jù)庫一致的的狀態(tài)。舉個例子說明：最形象的例子莫過于轉賬時發(fā)生的情況，轉賬至少包括兩個操作，一個是從匯款人的卡里扣掉寄款，一個是收款人的卡要加上這個數(shù)目，如果由于某種原因，這其中有一個操作失敗了，可能就會造成比

31、較嚴重的后果，為了防止這單方面的失敗，我們就引入了事務這種機制，引入事務后，如果其中有一個操作失敗了，那么系統(tǒng)會自動回復到操作前的狀態(tài)，也就是說，當你的卡上匯出了款，而對方卡上又沒有增加款項時，你卡上的款也不會少。怎么創(chuàng)建事務？在默認狀態(tài)下，MySQL是使用自動提交(autocommit)的方式，也就是說，一旦有操作，它立刻就會執(zhí)行，并且不會有"撤銷"功能，因為它已經把執(zhí)行結果寫入物理磁盤上了。為了實現(xiàn)事務，首先就要取消自動提交的方式；當然你可以先查看一下是否打開了自動提交，語句為：select autocommit; 如果返回值為非0，則證明是自動提交方式，這時你可以使用：set autocommit=0;來關閉自動提交。接著就開始啟動一個事務：start transation;這時我們就可以寫入我們想要放到事務里的操作語句了。比如：insert into tb1 values(.);i