愛華網(wǎng)1、觸發(fā)器不會返回結(jié)果，但是它可以讀取或修改數(shù)據(jù)。因此，可以使用觸發(fā)器代替客戶端代碼來強(qiáng)制約束（Constraint）或保證商業(yè)邏輯;2、如果你習(xí)慣于在其他數(shù)據(jù)庫產(chǎn)品中廣泛地使用觸發(fā)器，那么就應(yīng)該假設(shè)它在MySQL中不會按照同樣的方式工作，尤其是：（1）對于每個(gè)事件，在每個(gè)表上只能有一個(gè)觸發(fā)器。換句話說，不會有兩個(gè)觸發(fā)器啟動AFTER INSERT事件。（2）MySQL只支持行級觸發(fā)器，也就是說，服務(wù)器總是針對每一行進(jìn)行操作，而不是把它們看成一個(gè)整體。這使得處理大型數(shù)據(jù)集的效率很差。下面這些針對觸發(fā)器的通用警示條款也適用于MySQL：（1）它們讓服務(wù)器正在做的事情變得模糊，因?yàn)橐粋€(gè)簡單的語句也可能導(dǎo)致很多“不可見”的工作。例如，如果一個(gè)觸發(fā)器更新了一個(gè)相關(guān)的表，那么受影響的行的數(shù)量就會加倍。（2）觸發(fā)器很難調(diào)試，并且它也不利于分析性能。（3）觸發(fā)器會引起不明顯的死鎖和鎖等待。如果觸發(fā)器失敗了，原始查詢也會失敗，如果沒意識到觸發(fā)器的存在，就很難準(zhǔn)確地解釋錯(cuò)誤碼。3、觸發(fā)器也不能保持原子性。例如，一個(gè)更新 MyISAM 表的觸發(fā)器發(fā)生了錯(cuò)誤，但卻無法回滾。假設(shè)在一個(gè)MyISAM 表中使用AFTER UPDATE 觸發(fā)器更新另外一個(gè)MyISAM 表，如果觸發(fā)器發(fā)生錯(cuò)誤，導(dǎo)致第二個(gè)表更新失敗，但第一個(gè)表的更新卻不會被回滾。4、InnoDB 表上的觸發(fā)器的所有操作都在一個(gè)事務(wù)中完成，所以觸發(fā)器和引發(fā)它的操作是原子操作。 事件
1、事件和連接完全無關(guān)，它運(yùn)行在一個(gè)獨(dú)立的定時(shí)器線程上。事件不接受參數(shù)，也不返回值，也沒有任何連接讓它們可以得到輸入或返回輸出。2、適合事件的任務(wù)包括周期性的維護(hù)工作、重新建立緩存和匯總表以模擬物化視圖，或者保存用于監(jiān)視和診斷的狀態(tài)值。3、盡管事件和連接無關(guān)，但它和線程有關(guān)。服務(wù)器有一個(gè)主調(diào)度線程，必須用配置文件或利用命令把它激活，一旦激活了它，每執(zhí)行一個(gè)事件，都會創(chuàng)建一個(gè)新線程。 游標(biāo)
1、MySQL現(xiàn)在提供了只能向前的只讀游標(biāo)（Cursor），它只能在存儲過程中使用。一個(gè)存儲過程在同一時(shí)刻可以使用多個(gè)游標(biāo)，也可以在循環(huán)中嵌套游標(biāo)。2、MySQL以后也許會提供用于更新的游標(biāo)，但現(xiàn)在沒有。因?yàn)橛螛?biāo)讀取的是臨時(shí)表，而不是產(chǎn)生數(shù)據(jù)的原始表，所以它是只讀的。用戶自定義函數(shù)
1、MySQL支持用戶自定義函數(shù)（UDF, User-Defined Functions）已經(jīng)有很長時(shí)間了。UDF 和用SQL語句寫的存儲函數(shù)不同，它可以用任何支持C 調(diào)用方式的編程語言來寫。2、如果使用了UDF，升級MySQL的時(shí)候要仔細(xì)地檢查版本間的不同，也許需要對它進(jìn)行重新編譯，甚至得做出改變才能和新版本兼容。同時(shí)要保證 UDF是絕對線程安全的，它們在 MySQL服務(wù)器進(jìn)程里面運(yùn)行，那是純粹的多線程環(huán)境。3、和SQL 語言寫成的存儲函數(shù)不同，UDF現(xiàn)在不能讀寫表，至少在調(diào)用上下文中不行。這意味著它對純計(jì)算，或者是和外部的交互非常有幫助。視圖
1、視圖（View）是很普通的概念，MySQL 5.0包含了這一特性。MySQL視圖就像一張表，但其自身不會存儲任何數(shù)據(jù)，它的數(shù)據(jù)來自SQL查詢語句。出于很多考慮，MySQL把視圖當(dāng)成表來看待，并且兩者共享了同樣的命名空間。（mysql是用C語言寫成的一個(gè)軟件）。但是MySQL處理它們的方式并不完全一樣。例如，不能在視圖上創(chuàng)建觸發(fā)器，也不能用DROP TABLE 命令刪除視圖。2、MySQL可以使用這兩種執(zhí)行方式，它們分別調(diào)用了合并算法（MERGEAlgorithm）和臨時(shí)表算法（TEMPTABLEAlgorithm)。MySQL會優(yōu)先考慮使用合并算法。它甚至可以合并嵌套的視圖。3、在視圖包含GROUP BY、DISTINCT 、聚集函數(shù)、UNION、子查詢或其他無法保持視圖返回的行和待查詢的行之間一對一關(guān)系的結(jié)構(gòu)的時(shí)候，MySQL就會使用臨時(shí)表算法。4、可更新視圖可以通過視圖更新它所引用的表，視圖如果含有GROUP BY 、UNION、聚集函數(shù)或任何其他的異常，就不是可更新的。使用TEMPTABLE算法的視圖是不可更新的。構(gòu)造臨時(shí)表的查詢不會從外部查詢中得到WHERE條件，并且臨時(shí)表沒有索引。5、有時(shí)可以使用偽臨時(shí)視圖取得好的效果。這不用創(chuàng)建一個(gè)只在當(dāng)前連接中存在的真正臨時(shí)視圖，而是用一種特殊的方式，比如在特定的數(shù)據(jù)庫中，創(chuàng)建一個(gè)視圖，接下來就可以在FROM子句中使用這個(gè)視圖，在使用完之后就可以把它刪除。6、MySQL不支持物化視圖（MaterializedView）。物化視圖通常把結(jié)果存儲在一個(gè)不可見的表里面，然后周期性地從原始數(shù)據(jù)對不可見表進(jìn)行刷新。MySQL也不支持索引視圖（Indexed View ），可以通過創(chuàng)建緩存表和匯總表模擬物化視圖和索引視圖。7、MySQL對視圖的實(shí)現(xiàn)有一些讓人煩惱的地方。最大的問題是MySQL不會保持視圖的原始SQL 語句。如果試著使用SHOWCREATE VIEW 命令把視圖顯示出來，然后對它進(jìn)行編輯，你會非常驚訝。 字符集1、UTF -8 多字節(jié)字符集以可變字節(jié)數(shù)（1 字節(jié)到3字節(jié)）來保存每個(gè)字符。MySQL內(nèi)部許多字符串操作使用了固定大小的緩沖區(qū)，所以它必須分配足夠的空間，以容納最大的可能長度。例如，CHAR(10)使用UTF -8 進(jìn)行編碼，即使實(shí)際的字符串沒有所謂的寬字符，也需要30 個(gè)字節(jié)。2、另外一個(gè)出人意料的地方就是索引限制。如果索引了一個(gè)使用了UTF -8 字符集的列，MySQL就會假設(shè)每個(gè)字符都會是3字節(jié)，所以平常的長度限制突然就減少為三分之一。3、某些人推薦在所有的地方都使用UTF -8 。但是，如果在意性能的話，這不是一個(gè)好主意。許多應(yīng)用程序根本不需要UTF -8，并且使用何種字符集依賴于數(shù)據(jù)。UTF -8 使用更多的磁盤空間。 全文索引
1、在MySQL中，只有MyISAM 存儲引擎支持全文索引。盡管只有MyISAM 支持全文索引，如果想使用InnoDB或其他存儲引擎，也不用擔(dān)心，因?yàn)槟憧梢宰约鹤鋈乃饕?。一個(gè)通常的辦法就是把表復(fù)制到從服務(wù)器上，它可以使用 MyISAM存儲引擎，然后使用從服務(wù)器進(jìn)行全文搜索。如果不想在不同的服務(wù)器上處理查詢，可以把表垂直地分為兩部分，一部分保留文本列，另一部分保留其余的數(shù)據(jù)。2、如果定義了MATCH()函數(shù)兩次，也不會有額外的開銷，MySQL知道它們是同樣的函數(shù)，只會執(zhí)行一次。但是，如果在ORDER BY子句中使用了MATCH()，MySQL會使用文件排序來對結(jié)果進(jìn)行排序。3、布爾全文搜索的結(jié)果是沒有排序的。4、短語搜索很慢。只靠全文索引無法響應(yīng)這種搜索，因?yàn)樗饕龥]有在原始的全文集合中記錄單詞之間的相對位置。這樣造成的結(jié)果就是服務(wù)器不得不到行內(nèi)部去執(zhí)行單詞搜索。5、布爾全文搜索實(shí)際不需要全文索引。如果有全文索引的話，它就會使用索引，如果沒有的話，它就會掃描整個(gè)表。甚至可以對多個(gè)表使用布爾全文搜索，例如對聯(lián)接的結(jié)果進(jìn)行搜索。但是在所有的情況下，它都很慢。6、MySQL全文索引只會按照頻率進(jìn)行相關(guān)性排序。索引不會記錄被索引的單詞在字符串中的位置，所以即使單詞相鄰，也不會對相關(guān)性有貢獻(xiàn)。盡管這對大多數(shù)應(yīng)用都沒有問題，尤其是數(shù)據(jù)量較小的時(shí)候，但是這仍然有可能無法達(dá)到需求，并且MySQL全文索引沒有提供自由選擇排名算法的可能。它甚至沒有把用于相鄰性排名的數(shù)據(jù)保存起來。7、如果正在向數(shù)據(jù)庫導(dǎo)入大量的數(shù)據(jù)并且希望全文索引某些列，那么在導(dǎo)入之前就應(yīng)該使用DISABLE KEYS禁止全文索引，然后在導(dǎo)入后再用ENABLE KEYS重新啟用它。這通常會更快，因?yàn)闉椴迦氲拿恳恍懈滤饕枰芏鄷r(shí)間，并且這樣還可以避免碎片產(chǎn)生。8、InnoDB 現(xiàn)在是主要的支持外鍵的存儲引擎。 合并表和分區(qū)表
1、合并表其實(shí)并不是一個(gè)真正的表，它更像一個(gè)用于放置相似表的容器，可以使用合并存儲引擎創(chuàng)建合并表。相反的是，分區(qū)表是一個(gè)正常的表，它包含了一些特殊的指令，告訴MySQL物理數(shù)據(jù)被存放在什么地方，每個(gè)分區(qū)實(shí)際都是有索引的獨(dú)立表，分區(qū)表其實(shí)包裝了很多句柄對象。分區(qū)表看上去像一個(gè)單獨(dú)的表，但它實(shí)際上是一大堆獨(dú)立的表，但是無法訪問分區(qū)表下面的獨(dú)立表，不過合并表可以。2、MySQL在對分區(qū)表和合并表的實(shí)現(xiàn)上有很多共通之處，它們也有同樣的限制，兩個(gè)特性都會帶來同樣的好處，它們可以讓你做到下面這些事情： 分離靜態(tài)的和變化的數(shù)據(jù)。 使用相關(guān)數(shù)據(jù)的物理相鄰性來優(yōu)化查詢。 設(shè)計(jì)表以便查詢訪問較少的數(shù)據(jù)。 更容易地維護(hù)非常多的數(shù)據(jù)。（合并表在這個(gè)領(lǐng)域上比分區(qū)表更有優(yōu)勢）3、注意到合并表包含的表列的數(shù)量和類型都是一樣的，并且合并表上的索引也會在下屬表上存在。這是創(chuàng)建合并表的要求。4、合并表還有其他有趣的特性和限制，比如刪除合并表或它的某個(gè)下屬表。刪除合并表讓所有的“子表”都變得不可訪問，但是刪除其中的某個(gè)子表有不同的影響，它的行為和操作系統(tǒng)有關(guān)。例如，在GNU/Linux 上，子表的文件描述符還保持開啟的狀態(tài)，并且表還繼續(xù)存在，但是只能從合并表中訪問。5、創(chuàng)建合并表的CREATE語句不會檢查下屬表是否是兼容的。如果下屬表的定義有輕微的不一樣，MySQL會創(chuàng)建合并表，但是卻無法使用。同樣，如果在創(chuàng)建了一個(gè)有效的合并表之后對某個(gè)下屬表進(jìn)行了改變，它也會無法工作，并且會顯示下面的錯(cuò)誤信息：“ERROR 1168 （HY000 ）：無法打開定義不同的下屬表，或者非MyISAM表，或者不存在的表”6、使用合并表的注意事項(xiàng)：(1)一旦唯一鍵和主鍵查詢成功，它們就立即停止。在這種情況下，服務(wù)器會挨個(gè)訪問下屬表，一旦查找到了值，就不會再查找更多的表。(2) 下屬表讀取的順序和CREATTABLE語句中定義的一致。如果經(jīng)常需要按照特定的順序取得數(shù)據(jù)，可以利用這種特性使合并排序操作更快。7、合并表非常適合但是并非只對日志和大量數(shù)據(jù)有效。它可以方便地按需創(chuàng)建繁忙的表。創(chuàng)建和刪除合并表的代價(jià)是很低的。索引可以像對視圖使用UNIONALL命令那樣使用合并表。但它的開銷更低，因?yàn)榉?wù)器不會把結(jié)果放到臨時(shí)表中然后再傳遞給客戶端。這使得它對于報(bào)告和倉庫化數(shù)據(jù)非常有用。例如，要?jiǎng)?chuàng)建一個(gè)每晚都會運(yùn)行的任務(wù)，它會把昨天的數(shù)據(jù)和8天前、15天前、以及之前的每一周的數(shù)據(jù)進(jìn)行合并。使用合并表就可以創(chuàng)建無須修改的查詢，并且自動地訪問合適的數(shù)據(jù)。甚至還可以創(chuàng)建臨時(shí)合并表，這是視圖無法做到的。8、MySQL隱藏了分區(qū)表的分區(qū)，并只能通過分區(qū)表訪問所有的分區(qū)，可以創(chuàng)建只包含想要的數(shù)據(jù)的臨時(shí)合并表，例如某個(gè)特定時(shí)間段的數(shù)據(jù)。這是分區(qū)表無法做到的。9、分區(qū)表和合并表有一個(gè)重大的區(qū)別：任何一個(gè)給定的數(shù)據(jù)行只會被存儲在一個(gè)合適的分區(qū)上。表的定義基于分區(qū)函數(shù)（PartitioningFunction)，它約定了行和分區(qū)之間的映射關(guān)系。10、分區(qū)表的局限：(1) 當(dāng)前，所有的分區(qū)都要使用同樣的存儲引擎。例如，不能像合并表那樣只壓縮部分分區(qū);(2) 盡管MySQL能避免分區(qū)表的查詢訪問所有的分區(qū)，但是它仍然鎖定了所有的分區(qū);(3) 分區(qū)不支持外鍵(4)分區(qū)表的靈活程度在某種程度上比合并表要小一些。例如想給分區(qū)表添加索引，這個(gè)操作并不能在一小段時(shí)間內(nèi)完成，因?yàn)锳LTER會將表鎖住，并且重新構(gòu)建整個(gè)表。合并表有更多的靈活性，比如可以給一個(gè)下屬表添加索引。同樣地，不能一次只備份或恢復(fù)一個(gè)分區(qū)，但是合并表沒有這個(gè)限制。 分布式（XA）事務(wù)
1、XA事務(wù)需要事務(wù)協(xié)調(diào)員，它會通知所有的參與者準(zhǔn)備提交事務(wù)（階段一）。當(dāng)協(xié)調(diào)員從所有參與者那里收到“就緒（R eady）”信號時(shí)，它會通知所有參與者進(jìn)行真正的提交（階段二）。MySQL可以是XA事務(wù)的參與者，但不能是協(xié)調(diào)員。2、內(nèi)部分布式事務(wù)：MySQL內(nèi)部使用XA事務(wù)的原因是服務(wù)器和存儲引擎之間是隔離的。存儲引擎之間是完全獨(dú)立的，彼此不知道對方的存在，所以任何跨引擎的事務(wù)本質(zhì)上都是分布的，并且要求第三方來進(jìn)行協(xié)調(diào)。MySQL就是第三方。假如沒有XA事務(wù)，跨引擎事務(wù)提交需要順序地要求每個(gè)引擎進(jìn)行提交。這樣就會引入一種可能，就是在某個(gè)引擎提交之后發(fā)生了崩潰，但是另外一個(gè)引擎還未提交。這就打破了事務(wù)的原則。3、MySQL不擅長分布式數(shù)據(jù)處理，因?yàn)樗鄙俨⑿胁樵兊膱?zhí)行能力。 綜合
1、與持久性連接相比，連接池在連接策略上有更多的控制。你可以把一個(gè)連接池配置成自動擴(kuò)充的，但是通常的做法還是當(dāng)連接池滿的時(shí)候，新的連接請求都被放在隊(duì)列里等待。這使得這些請求都在應(yīng)用服務(wù)器上等待，總好過MySQL因?yàn)檫B接太多而超載。2、優(yōu)化Apache的web程序的途徑:(1) 不要把Apache用作靜態(tài)內(nèi)容的服務(wù)，如果一定要用，那也至少要換個(gè)另外的Apache實(shí)例來處理這些事情。常見的替代品有l(wèi)ighttpd 和nginx;(2)使用一個(gè)緩存代理服務(wù)器，比如Squid 或Varnish，使用戶請求無須抵達(dá)Web服務(wù)器后才能被響應(yīng)。即使在這個(gè)層面上你無法緩存所有的頁面，你也能緩存大部分頁面，并通過Edge Side Includes（ESL，http://www.esi.org ）技術(shù)把頁面上的小塊動態(tài)部分放到緩存的靜態(tài)部分里。(3)對動態(tài)內(nèi)容和靜態(tài)內(nèi)容都設(shè)置過期策略。你可以使用緩存代理軟件，像Squid，去驗(yàn)證內(nèi)容的明確性。Wikipedia就是用這樣的技術(shù)在緩存里移除內(nèi)容已發(fā)生變化的文檔(4)不要將Apache上的長距離連接配置為“保活”（Keep-Alive）模式，因?yàn)樗鼤笰pache上臃腫的進(jìn)程長時(shí)間處于運(yùn)行狀態(tài)。代替的方案是，用一個(gè)服務(wù)端的代理來處理“?；睢钡倪B接，使服務(wù)器免受這類客戶端的傷害。如果將Apache與代理之間的連接方式設(shè)為“保活”，那是不錯(cuò)的主意，因?yàn)榇韮H使用幾個(gè)連接從服務(wù)器上讀取數(shù)據(jù)。
另外補(bǔ)充一些自己的體驗(yàn)：（1）mysql表中的記錄數(shù)沒有限制，即使操作系統(tǒng)對文件大小設(shè)置了限制（畢竟mysql表最終是存儲在磁盤上的文件），但是由于linux虛擬分區(qū)的概念，不會造成此問題。只是說表里面的記錄數(shù)太多的話，會影響查詢效率和排除故障的效率；（2）mysql查詢表的列中explain 表名 等于 show columns from 表名 也等于describe表名。如果在SELECT語句前放上關(guān)鍵詞EXPLAIN，MySQL將解釋它如何處理SELECT，提供有關(guān)表如何聯(lián)接和聯(lián)接的次序。結(jié)果字段的解釋:Table: 顯示該語句涉及數(shù)據(jù)庫表Type: 這列很重要， 顯示了該連接使用了哪種類別， 有無使用索引，反應(yīng)語句的質(zhì)量 。結(jié)果值從好到壞依次是 : system > const > eq_ref >ref > fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range > index > ALL， 一般來說，得保證查詢至少達(dá)到range級別， 最好能到達(dá)ref級別， 否則就可能出現(xiàn)性能問題。Possible_key : 指出mysql能使用哪個(gè)索引在該表中找到行Key: 顯示mysql實(shí)際使用的鍵（索引）, 如果沒有選擇索引， 鍵是null。Key_len ： 顯示mysql決定使用的鍵長度。 如果是null， 則長度為null，在不損失精確性的情況下，長度越短越好。Ref： 顯示使用哪個(gè)列或常數(shù)與key一起從表中選擇行。Rows: 顯示mysql認(rèn)為它執(zhí)行查詢時(shí)必須檢查的行數(shù)。Extra ： 包含mysql解決查詢的詳細(xì)信息。（3）查看 mysql版本：（1）打開終端，輸入：mysql -V（2）登錄mysql，在mysql里面直接輸入 status
