系統(tǒng)性能的調(diào)優(yōu)：優(yōu)化Apache和PHP
LAMP 系統(tǒng)性能調(diào)優(yōu)，第 2 部分: 優(yōu)化 Apache 和 PHP
本文大綱：LAMP 架構(gòu)、 優(yōu)化 Apache 和 PHP、MySQL的調(diào)優(yōu)
如今，使用 LAMP(Linux®、Apache、MySQL 和 PHP/Perl)架構(gòu)的應(yīng)用程序不斷被開(kāi)發(fā)和部署。但是，服務(wù)器管理員常常對(duì)應(yīng)用程序本身幾乎沒(méi)有控制能力，因?yàn)閼?yīng)用程序是別人編寫(xiě)的。這份 共三部分的系列文章 將討論許多服務(wù)器配置問(wèn)題，這些配置會(huì)影響應(yīng)用程序的性能。第二篇文章重點(diǎn)討論可為優(yōu)化 Apache 和 PHP 而采取的措施。
Linux、Apache、MySQL 和 PHP(或 Perl)是許多 Web 應(yīng)用程序的 LAMP 架構(gòu)的基礎(chǔ)。有很多基于 LAMP 組件的開(kāi)源軟件包可用于解決各種各樣的問(wèn)題。隨著應(yīng)用程序負(fù)載的增加，底層基礎(chǔ)設(shè)施的瓶頸也會(huì)越來(lái)越明顯，其表現(xiàn)形式就是響應(yīng)用戶請(qǐng)求的速度變慢。 上一篇文章 展示了調(diào)優(yōu) Linux 系統(tǒng)的方法，還介紹了 LAMP 和性能度量的基礎(chǔ)知識(shí)。本文重點(diǎn)關(guān)注 Web 服務(wù)器組件：Apache 和 PHP。
調(diào)優(yōu) Apache
Apache 是一種高度可配置的軟件。它具有大量特性，但每一種都代價(jià)高昂。從某種程度上來(lái)說(shuō)，調(diào)優(yōu) Apache 來(lái)說(shuō)就是以恰當(dāng)?shù)姆绞椒峙滟Y源，還涉及到將配置簡(jiǎn)化為僅包含必要內(nèi)容。
配置 MPM
Apache 是模塊化的，因?yàn)榭梢暂p松添加和移除特性。在 Apache 的核心，多處理模塊(Multi-Processing Module，MPM)提供了這種模塊化功能性 —— 管理網(wǎng)絡(luò)連接、調(diào)度請(qǐng)求。MPM 使您能夠使用線程，甚至能夠?qū)?Apache 遷移到另外一個(gè)操作系統(tǒng)。
每次只能有一個(gè) MPM 是活動(dòng)的，必須使用 --with-mpm=(worker|prefork|event) 靜態(tài)編譯。
每個(gè)請(qǐng)求使用一個(gè)進(jìn)程的傳統(tǒng)模型稱為 prefork。較新的線程化模型稱為 worker，它使用多個(gè)進(jìn)程，每個(gè)進(jìn)程又有多個(gè)線程，這樣就能以較低的開(kāi)銷(xiāo)獲得更好的性能。最新的 event MPM 是一種實(shí)驗(yàn)性的模型，為不同的任務(wù)使用單獨(dú)的線程池。要確定當(dāng)前使用的是哪種 MPM，可執(zhí)行 httpd -l。
選 擇使用何種 MPM 取決于許多因素。在 event MPM 脫離實(shí)驗(yàn)狀態(tài)之前，不應(yīng)考慮這種模型，而是在使用線程和不使用線程之間作出選擇。表面上看來(lái)，如果所有底層模塊(包括 PHP 使用的所有庫(kù))都是線程安全的，線程要優(yōu)于分叉(forking)。而 Prefork 是較為安全的選擇;如果選擇了 worker，則應(yīng)該謹(jǐn)慎測(cè)試。性能收益還取決于您的發(fā)布版所附帶的庫(kù)及硬件。
無(wú)論選擇了哪種 MPM，都必須恰當(dāng)?shù)嘏渲盟?。一般而言，配?MPM 包括告知 Apache 怎樣去控制有多少 worker 正在運(yùn)行，它們是線程還是進(jìn)程。prefork MPM 的重要配置選項(xiàng)如清單 1 所示。
清單 1. prefork MPM 的配置
- StartServers 50MinSpareServers 15MaxSpareServers 30MaxClients 225MaxRequestsPerChild 4000
編譯您自己的軟件
最初使用 UNIX® 時(shí)，我堅(jiān)持為加入系統(tǒng)的一切編譯軟件。最終，維護(hù)更新給我?guī)?lái)了麻煩，所以我學(xué)會(huì)了如何構(gòu)建包來(lái)簡(jiǎn)化這一任務(wù)。后來(lái)我意識(shí)到，大多數(shù)時(shí)候我都在重復(fù)做發(fā)布 版做過(guò)的事情?，F(xiàn)在，在很大程度上來(lái)說(shuō)，我會(huì)盡可能堅(jiān)持使用我所選擇的發(fā)布版提供的一切，僅在必要的時(shí)候使用自己的包。
類(lèi)似地，您可能會(huì)發(fā)現(xiàn)，就可維護(hù)性而言，使用廠商提供的軟件包要優(yōu)于使用最新、最棒的代碼。有些時(shí)候，性能調(diào)優(yōu)和系統(tǒng)管理的目標(biāo)會(huì)有所沖突。如果使用商業(yè)版的 Linux 或依賴于第三方支持，那么可能不得不考慮廠商的支持。
如果您一意孤行，那么請(qǐng)學(xué)會(huì)如何構(gòu)建能與您的發(fā)布版協(xié)同工作的包，請(qǐng)學(xué)會(huì)如何將其集成到補(bǔ)丁系統(tǒng)之中。這將確保軟件，以及您作出的任何更改得到一致的構(gòu)建，且能跨多個(gè)系統(tǒng)使用。還應(yīng)訂閱恰當(dāng)?shù)泥]件列表和 RSS 提要來(lái)及時(shí)獲得軟件更新。
prefork 模型會(huì)為每個(gè)請(qǐng)求創(chuàng)建一個(gè)新進(jìn)程。多余的進(jìn)程保持空閑，以處理傳入的請(qǐng)求，這縮短了啟動(dòng)延遲。只要 Web 服務(wù)器出現(xiàn)，預(yù)先完成的配置就會(huì)立即啟動(dòng) 50 個(gè)進(jìn)程，并盡力保持 10 到 20 個(gè)空閑服務(wù)器運(yùn)行。進(jìn)程數(shù)的硬性限制由 MaxClients 指定。盡管一個(gè)進(jìn)程能夠處理許多相繼的請(qǐng)求，Apache 還是會(huì)取消連接數(shù)超過(guò) 4,000 以后的進(jìn)程，這降低了內(nèi)存泄漏的風(fēng)險(xiǎn)。
配置線程化 MPM 與之類(lèi)似，不同之處只是必須確定使用多少線程和進(jìn)程。Apache 文檔解釋了所有必要的參數(shù)和計(jì)算。
要經(jīng)過(guò)幾次嘗試和出錯(cuò)之后才能選好要使用的值。最重要的值是 MaxClients。目標(biāo)在于允許足夠多的 workder 進(jìn)程或線程運(yùn)行，同時(shí)又不會(huì)導(dǎo)致服務(wù)器進(jìn)行過(guò)度的交換。如果傳入的請(qǐng)求超出處理能力，那么至少滿足此值的那些請(qǐng)求會(huì)得到服務(wù)，其他請(qǐng)求被阻塞。
如果 MaxClients 過(guò)高，那么所有客戶機(jī)都將體驗(yàn)到糟糕的服務(wù)，因?yàn)?Web 服務(wù)器會(huì)試圖換出一個(gè)進(jìn)程，以使另一個(gè)進(jìn)程能夠運(yùn)行。而設(shè)得過(guò)低意味著可能會(huì)不必要地拒絕服務(wù)。查看高負(fù)載下運(yùn)行的進(jìn)程數(shù)量和所有 Apache 進(jìn)程所導(dǎo)致的內(nèi)存占用情況對(duì)設(shè)置這個(gè)值很有幫助。如果 MaxClients 的值超過(guò) 256，必須將 ServerLimit 也設(shè)為同樣的數(shù)值，請(qǐng)仔細(xì)閱讀 MPM 的文檔，了解相關(guān)信息。
根據(jù)服務(wù)器的角色調(diào)優(yōu)要啟動(dòng)和保持空閑的服務(wù)器數(shù)量。如果服務(wù)器僅運(yùn)行 Apache，那么可以使用適中的值，如 清單 1 所示，因?yàn)檫@樣就能充分利用機(jī)器。如果系統(tǒng)中還有其他數(shù)據(jù)庫(kù)或服務(wù)器，那么就應(yīng)該限制運(yùn)行中的空閑服務(wù)器的數(shù)量。
有效地使用選項(xiàng)和重寫(xiě)
Apache 處理的每個(gè)請(qǐng)求都要履行一套復(fù)雜的規(guī)則，這些規(guī)則指明了 Web 服務(wù)器必須遵循的約束或特殊指令。對(duì)文件夾的訪問(wèn)可能按 IP 地址約束為某個(gè)特定文件夾，也可配置用戶名和密碼。這些選項(xiàng)還包含處理特定文件，例如，如果提供了一個(gè)目錄列表，該如何處理的文件，或輸出結(jié)果是否應(yīng)壓 縮。
這些配置以 httpd.conf 中容器的形式出現(xiàn)，例如
清單 2. 為根目錄應(yīng)用的一個(gè) Directory 容器
- AllowOverride None Options FollowSymLinks
在清單 2 中，位于一對(duì) Directory 和 /Directory 標(biāo)記之間的配置應(yīng)用于給定目錄和該目錄下的一切內(nèi)容 —— 在本例中，這個(gè)給定目錄是根目錄。此處，AllowOverride 標(biāo)記指出，用戶不允許重寫(xiě)任何選項(xiàng)(稍后將進(jìn)一步介紹)。FollowSymLinks 選項(xiàng)被啟用，它允許 Apache 查看之前的符號(hào)連接來(lái)為請(qǐng)求提供服務(wù)，即便文件位于包含 Web 文件的目錄之外。這就意味著，如果 Web 目錄中的一個(gè)文件是 /etc/passwd 的符號(hào)連接，Web 服務(wù)器將在請(qǐng)求時(shí)順利為該文件提供服務(wù)。如果使用了 -FollowSymLinks，該特性就會(huì)被禁用，同樣的請(qǐng)求將致使為客戶機(jī)返回錯(cuò)誤。
最后這個(gè)場(chǎng)景正是導(dǎo)致兩方面關(guān)注的原因所在。第一個(gè)方面與性能有關(guān)。如果禁用了 FollowSymLinks，Apache 就必須檢查使用該文件名的所有組件(目錄和文件本身)，以確保它們不是符號(hào)連接。這會(huì)帶來(lái)額外的開(kāi)銷(xiāo)(磁盤(pán)操作)。另外一個(gè)稱為 FollowSymLinksIfOwnerMatch 的選項(xiàng)會(huì)在文件所有者與連接所有者相同時(shí)使用符號(hào)連接。為獲得最佳性能，請(qǐng)使用 清單 2 中的選項(xiàng)。
至 此，有安全意識(shí)的讀者應(yīng)該有了警惕的感覺(jué)。安全性永遠(yuǎn)是功能性與風(fēng)險(xiǎn)之間的權(quán)衡。在我們的例子中，功能性是速度，而風(fēng)險(xiǎn)是允許對(duì)系統(tǒng)上的文件進(jìn)行未經(jīng)授權(quán) 的訪問(wèn)。緩解風(fēng)險(xiǎn)的措施之一是 LAMP 應(yīng)用服務(wù)器通常專注于一種具體功能，用戶無(wú)法創(chuàng)建危險(xiǎn)的符號(hào)連接。如果有必要啟用符號(hào)連接，那么可以將其約束在文件系統(tǒng)的特定區(qū)域，如清單 3 所示。
清單 3. 將 FollowSymLinks 約束為一個(gè)用戶的目錄
- Options FollowSymLinks Options -FollowSymLinks
在清單 3 中，一個(gè)用戶的主目錄中的任何 public_html 目錄及其所有子目錄都移除了 FollowSymLinks 選項(xiàng)。
如您所見(jiàn)，通過(guò)主服務(wù)器配置，可為每個(gè)目錄單獨(dú)配置選項(xiàng)。用戶可以自行重寫(xiě)這種服務(wù)器配置(如果管理員通過(guò) AllowOverrides 語(yǔ)句允許了這種操作)，只需將一個(gè) .htaccess 文件放入目錄即可。該文件包含額外的服務(wù)器指令，每次請(qǐng)求包含 .htaccess 文件的目錄時(shí)將加載并應(yīng)用這些指令。盡管之前探討過(guò)系統(tǒng)沒(méi)有用戶的問(wèn)題，但許多 LAMP 應(yīng)用程序都利用這種功能性來(lái)控制訪問(wèn)、實(shí)現(xiàn) URL 重寫(xiě)，因此有必要理解其工作原理。
即便 AllowOverrides 語(yǔ)句能阻止用戶去做您不希望他們做的事，Apache 也必須檢查 .htaccess 文件，看看是否有要完成的工作。父目錄可以指定由來(lái)自子目錄的請(qǐng)求處理的指令，這也就表示，Apache 必須搜索所請(qǐng)求文件的目錄樹(shù)的所有組件?？上攵@會(huì)使每次請(qǐng)求都導(dǎo)致大量磁盤(pán)操作。
最簡(jiǎn)單的解決方案 是不允許重寫(xiě)，這能消除 Apache 檢查 .htaccess 的需求。之后的任何特殊配置都將直接放在 httpd.conf 中。清單 4 顯示為對(duì)一個(gè)用戶的項(xiàng)目目錄進(jìn)行密碼檢查向 httpd.conf 增加的代碼，而不是將其放入一個(gè) .htaccess 文件并依賴于 AllowOverrides。
清單 4. 將 .htaccess 配置移入 httpd.conf
- AuthUserFile /home/user/.htpasswd AuthName "uber secret project" AuthType basic Require valid-user
如果配置轉(zhuǎn)移到 httpd.conf 中，且 AllowOverrides 被禁用，磁盤(pán)的使用就能減少。一個(gè)用戶的項(xiàng)目可能不會(huì)吸引許多人來(lái)點(diǎn)擊，但設(shè)想一下，將這項(xiàng)技術(shù)應(yīng)用于一個(gè)忙碌的站點(diǎn)時(shí)會(huì)有多么強(qiáng)大。
有時(shí)不可能徹底消除 .htaccess 文件的使用。例如，在清單 5 中，一個(gè)選項(xiàng)被約束到文件系統(tǒng)的特定部分，重寫(xiě)也可以是有作用域的。
清單 5. 限定 .htaccess 檢查的作用域
- AllowOverrides None AllowOverrides AuthConfig
實(shí)現(xiàn)清單 5 之后，Apache 會(huì)在父目錄中查找 .htaccess 文件，但會(huì)在 public_html 目錄處停止，因?yàn)槲募到y(tǒng)的其余部分禁用了此功能。例如，如果請(qǐng)求的是一個(gè)映射到 /home/user/public_html/project/notes.html 的文件，那么僅有 public_html 和 project 目錄被搜索。
關(guān)于每目錄單獨(dú)配置的最后一個(gè)提示就是：要按順序依次進(jìn)行。任何介紹 Apache 調(diào)優(yōu)的的文章都會(huì)告訴您，應(yīng)通過(guò) HostnameLookups off 指令禁用 DNS 查找，因?yàn)樵噲D反向解析連接到您的服務(wù)器的所有 IP 地址無(wú)疑是浪費(fèi)資源。然而，基于主機(jī)名的任何約束都會(huì)迫使 Web 服務(wù)器對(duì)客戶機(jī)的 IP 地址執(zhí)行反向查找，對(duì)其結(jié)果進(jìn)行正向查找，以驗(yàn)證該名稱的真實(shí)性。因此，避免使用基于客戶主機(jī)名的訪問(wèn)控制，在必須使用時(shí)限定其作用域，這些都是明智的做 法。
持久連接
一 個(gè)客戶機(jī)連接到 Web 服務(wù)器時(shí)，允許客戶機(jī)通過(guò)同一個(gè) TCP 連接發(fā)出多個(gè)請(qǐng)求，這減少了與多個(gè)連接相關(guān)的延遲。在一個(gè) Web 頁(yè)面引用了多幅圖片時(shí)，這就很有用：客戶機(jī)可以通過(guò)一個(gè)連接先請(qǐng)求頁(yè)面，再請(qǐng)求所有圖片。其缺點(diǎn)在于服務(wù)器上的 worker 進(jìn)程必須等待客戶機(jī)要關(guān)閉的會(huì)話，之后才能轉(zhuǎn)到下一個(gè)請(qǐng)求。
Apache 使您能夠配置如何處理持久連接(稱為 keepalives)。httpd.conf 全局級(jí)的 KeepAlive 5 允許服務(wù)器在連接強(qiáng)制關(guān)閉之前處理一個(gè)連接上的 5 個(gè)請(qǐng)求。將此值設(shè)置為 0 將禁用持久連接。同樣位于全局級(jí)上的 KeepAliveTimeout 確定在會(huì)話關(guān)閉之前，Apache 將等待另外一個(gè)連接多久。
持久連接的處理并非 “一刀切” 式的配置。對(duì)于某些 Web 站點(diǎn)，禁用 keepalives 更合適(KeepAlive 0);而對(duì)于其他一些站點(diǎn)，啟用它會(huì)帶來(lái)巨大的收益。惟一的解決之道就是嘗試使用這兩種配置，自己觀察哪種更合適。但若啟用了 keepalives，使用較小的超時(shí)時(shí)間較為明智，例如 2，即 KeepAliveTimeout 2。這能確保希望發(fā)出另外一個(gè)請(qǐng)求的客戶機(jī)有充足的時(shí)間，還能確保 worker 進(jìn)程不會(huì)一直空閑，等待可能永遠(yuǎn)不會(huì)出現(xiàn)的下一個(gè)請(qǐng)求。
壓縮
Web 服務(wù)器能夠在將輸出發(fā)回給客戶機(jī)之前壓縮它。這將使通過(guò) Internet 發(fā)送的頁(yè)面更小，代價(jià)是 Web 服務(wù)器上的 CPU 周期。對(duì)于那些負(fù)擔(dān)得起 CPU 開(kāi)銷(xiāo)的服務(wù)器來(lái)說(shuō)，這是提高頁(yè)面下載速度的好辦法 —— 頁(yè)面壓縮后大小變?yōu)樵瓉?lái)的三分之一這種事情并不罕見(jiàn)。
圖片通常已經(jīng)是壓縮過(guò)的，因此壓縮應(yīng)僅限于文本輸出。Apache 通過(guò) mod_deflate 提供壓縮。盡管 mod_deflate 可輕松啟用，但它涉及到太多的復(fù)雜性，很多手冊(cè)都解釋了這些復(fù)雜的內(nèi)容。本文不會(huì)介紹壓縮的配置，但提供了相應(yīng)文檔的鏈接(參見(jiàn) 參考資料 部分)。
調(diào)優(yōu) PHP
PHP 是運(yùn)行應(yīng)用程序代碼的引擎。應(yīng)該僅安裝計(jì)劃使用的那些模塊，并配置您的 Web 服務(wù)器，使之僅為腳本文件(通常是以 .php 結(jié)尾的那些文件)使用 PHP，而非所有靜態(tài)文件。
操作碼緩存
請(qǐng)求一個(gè) PHP 腳本時(shí)，PHP 會(huì)讀取該腳本，并將其編譯為 Zend 操作碼，這是要執(zhí)行的代碼的一種二進(jìn)制表示形式。隨后，此操作碼由 PHP 執(zhí)行并丟棄。操作碼緩存將保存這個(gè)編譯后的操作碼，并在下一次調(diào)用該頁(yè)面時(shí)重用它。這會(huì)節(jié)省很多時(shí)間。有多種緩存可用，我比較常用的是 eAccelerator。
要安裝 eAccelerator，您的計(jì)算機(jī)上需要有 PHP 開(kāi)發(fā)庫(kù)。由于不同的 Linux 發(fā)布版存放文件的位置不同，所以最好直接從 eAccelerator 的 Web 站點(diǎn)獲得安裝說(shuō)明(參見(jiàn) 參考資料 部分獲得鏈接)。您的發(fā)布版也有可能已經(jīng)包含了一個(gè)操作碼緩存，只需安裝即可。
無(wú)論如何在系統(tǒng)上安裝 eAccelerator，都有一些配置選項(xiàng)需要注意。配置文件通常是 /etc/php.d/eaccelerator.ini。eaccelerator.shm_size 定義共享高速緩存的大小，編譯后的腳本就存儲(chǔ)在這里。該值的單位是兆字節(jié)(MB)。根據(jù)您的應(yīng)用程序確定恰當(dāng)?shù)拇笮?。eAccelerator 提供了一個(gè)腳本來(lái)顯示緩存的狀態(tài)，其中包含內(nèi)存占用，64MB 是個(gè)不錯(cuò)的選擇(eaccelerator.shm_size="64")。如果您選擇的值未被接受，那么必須修改內(nèi)核的最大共享內(nèi)存的大小。向 /etc/sysctl.conf 添加 kernel.shmmax=67108864，運(yùn)行 sysctl -p 來(lái)使設(shè)置生效。kernel.shmmax 值的單位是字節(jié)。
如果共享內(nèi)存的分配超出極限，eAccelerator 必須將舊腳本從內(nèi)存中清除。默認(rèn)情況下，這是被禁用的;eaccelerator.shm_ttl = "60" 指定：當(dāng) eAccelerator 用完共享內(nèi)存時(shí)，60 秒內(nèi)未被訪問(wèn)的所有腳本都將被清除。
另一種流行的 eAccelerator 替代工具是 Alternative PHP Cache(APC)。Zend 的廠商也提供了一種商業(yè)操作碼緩存，包括一個(gè)進(jìn)一步提高效率的優(yōu)化器。
php.ini
PHP 的配置是在 php.ini 中完成的。四個(gè)重要的設(shè)置控制 PHP 可使用多少系統(tǒng)資源
設(shè)置描述建議值
max_execution_time一個(gè)腳本可使用多少 CPU 秒 30
max_input_time一個(gè)腳本等待輸入數(shù)據(jù)的時(shí)間有多長(zhǎng)(秒)60
memory_limit在被取消之前，一個(gè)腳本可使用多少內(nèi)存(字節(jié))32M
output_buffering數(shù)據(jù)發(fā)送給客戶機(jī)之前，有多少數(shù)據(jù)(字節(jié))需要緩存4096
具體數(shù)字主要取決于您的應(yīng)用程序。如果要從用戶處接收大文件，那么 max_input_time 可能必須增加，可以在 php.ini 中修改，也可以通過(guò)代碼重寫(xiě)它。與之類(lèi)似，CPU 或內(nèi)存占用較多的程序也可能需要更大的設(shè)置值。目標(biāo)就是緩解超標(biāo)程序的影響，因此不建議全局禁用這些設(shè)置。關(guān)于 max_execution_time，還有一點(diǎn)需要注意：它表示進(jìn)程的 CPU 時(shí)間，而不是絕對(duì)時(shí)間。因此一個(gè)進(jìn)行大量 I/O 和少量計(jì)算的程序的運(yùn)行時(shí)間可能遠(yuǎn)遠(yuǎn)超過(guò) max_execution_time。這也是 max_input_time 可以大于 max_execution_time 的原因所在。
PHP 可執(zhí)行的日志記錄數(shù)是可配置的。在生產(chǎn)環(huán)境中，禁用除最重要的日志以外的一切日志記錄能夠減少磁盤(pán)寫(xiě)操作。如果需要使用日志來(lái)排除問(wèn)題，那么可以按需啟用日志記錄。error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR 將啟用足夠的日志記錄，使您發(fā)現(xiàn)問(wèn)題，同時(shí)從腳本中消除大量無(wú)用的內(nèi)容?！ ?/P>
本文大綱：LAMP 架構(gòu)、 優(yōu)化 Apache 和 PHP、MySQL的調(diào)優(yōu)
結(jié)束語(yǔ)
本文重點(diǎn)探討 Web 服務(wù)器的調(diào)優(yōu)，包括 Apache 和 PHP。對(duì)于 Apache，總體的想法是消除 Web 服務(wù)器必須執(zhí)行的多余檢查，例如處理 .htaccess 文件。還必須調(diào)優(yōu)所用的多處理模塊，以便在使用的系統(tǒng)資源和可供傳入請(qǐng)求使用的空閑 worker 之間找到平衡。對(duì)于 PHP，最好的事情就是安裝一個(gè)操作碼緩存。密切注意幾個(gè)資源設(shè)置也能確保腳本不會(huì)浪費(fèi)系統(tǒng)資源，不會(huì)減慢系統(tǒng)處理其他任務(wù)的速度。
本系列的下一篇也是最后一篇文章將介紹 MySQL 數(shù)據(jù)庫(kù)的調(diào)優(yōu)。請(qǐng)繼續(xù)關(guān)注!
