這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)使用PHPCMS用哪個(gè)數(shù)據(jù)庫(kù)比較好，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

創(chuàng)新互聯(lián)是一家專業(yè)提供兩當(dāng)企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、成都做網(wǎng)站、H5響應(yīng)式網(wǎng)站、小程序制作等業(yè)務(wù)。10年已為兩當(dāng)眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

PHPCMS用MySQL數(shù)據(jù)庫(kù)比較好，因?yàn)镻HPCMS是使用PHP進(jìn)行編寫(xiě)的，而PHP對(duì)MySQL支持比較好，所以推薦使用MySQL，該數(shù)據(jù)庫(kù)是一種開(kāi)放源代碼的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)。

MySQL 優(yōu)化

選擇InnoDB作為存儲(chǔ)引擎

大型產(chǎn)品的數(shù)據(jù)庫(kù)對(duì)于可靠性和并發(fā)性的要求較高，InnoDB作為默認(rèn)的MySQL存儲(chǔ)引擎，相對(duì)于MyISAM來(lái)說(shuō)是個(gè)更佳的選擇。

優(yōu)化數(shù)據(jù)庫(kù)結(jié)構(gòu)

組織數(shù)據(jù)庫(kù)的schema、表和字段以降低I/O的開(kāi)銷(xiāo)，將相關(guān)項(xiàng)保存在一起，并提前規(guī)劃，以便隨著數(shù)據(jù)量的增長(zhǎng)，性能可以保持較高的水平。

設(shè)計(jì)數(shù)據(jù)表應(yīng)盡量使其占用的空間最小化，表的主鍵應(yīng)盡可能短?！?duì)于InnoDB表，主鍵所在的列在每個(gè)輔助索引條目中都是可復(fù)制的，因此如果有很多輔助索引，那么一個(gè)短的主鍵可以節(jié)省大量空間。

僅創(chuàng)建你需要改進(jìn)查詢性能的索引。索引有助于檢索，但是會(huì)增加插入和更新操作的執(zhí)行時(shí)間。

InnoDB的ChangeBuffering特性

InnoDB提供了changebuffering的配置，可減少維護(hù)輔助索引所需的磁盤(pán)I/O。大規(guī)模的數(shù)據(jù)庫(kù)可能會(huì)遇到大量的表操作和大量的I/O，以保證輔助索引保持最新。當(dāng)相關(guān)頁(yè)面不在緩沖池里面時(shí)，InnoDB的changebuffer將會(huì)更改緩存到輔助索引條目，從而避免因不能立即從磁盤(pán)讀取頁(yè)面而導(dǎo)致耗時(shí)的I/O操作。當(dāng)頁(yè)面被加載到緩沖池時(shí)，緩沖的更改將被合并，更新的頁(yè)面之后會(huì)刷新到磁盤(pán)。這樣做可提高性能，適用于MySQL5.5及更高版本。

InnoDB頁(yè)面壓縮

InnoDB支持對(duì)表進(jìn)行頁(yè)面級(jí)的壓縮。當(dāng)寫(xiě)入數(shù)據(jù)頁(yè)的時(shí)候，會(huì)有特定的壓縮算法對(duì)其進(jìn)行壓縮。壓縮后的數(shù)據(jù)會(huì)寫(xiě)入磁盤(pán)，其打孔機(jī)制會(huì)釋放頁(yè)面末尾的空塊。如果壓縮失敗，數(shù)據(jù)會(huì)按原樣寫(xiě)入。表和索引都會(huì)被壓縮，因?yàn)樗饕ǔＪ菙?shù)據(jù)庫(kù)總大小中占比很大的一部分，壓縮可以顯著節(jié)約內(nèi)存，I/O或處理時(shí)間，這樣就達(dá)到了提高性能和伸縮性的目的。它還可以減少內(nèi)存和磁盤(pán)之間傳輸?shù)臄?shù)據(jù)量。MySQL5.1及更高版本支持該功能。

注意，頁(yè)面壓縮并不能支持共享表空間中的表。共享表空間包括系統(tǒng)表空間、臨時(shí)表空間和常規(guī)表空間。

使用批量數(shù)據(jù)導(dǎo)入

在主鍵上使用已排序的數(shù)據(jù)源進(jìn)行批量數(shù)據(jù)的導(dǎo)入可加快數(shù)據(jù)插入的過(guò)程。否則，可能需要在其他行之間插入行以維護(hù)排序，這會(huì)導(dǎo)致磁盤(pán)I/O變高，進(jìn)而影響性能，增加頁(yè)的拆分。關(guān)閉自動(dòng)提交的模式也是有好處的，因?yàn)樗鼤?huì)為每個(gè)插入執(zhí)行日志刷新到磁盤(pán)。在批量插入期間臨時(shí)轉(zhuǎn)移唯一鍵和外鍵檢查也可顯著降低磁盤(pán)I/O。對(duì)于新建的表，最好的做法是在批量導(dǎo)入后創(chuàng)建外鍵/唯一鍵約束。

一旦你的數(shù)據(jù)達(dá)到穩(wěn)定的大小，或者增長(zhǎng)的表增加了幾十或幾百兆字節(jié)，就應(yīng)該考慮使用OPTIMIZETABLE語(yǔ)句重新組織表并壓縮浪費(fèi)的空間。對(duì)重新組織后的表進(jìn)行全表掃描所需要的I/O會(huì)更少。

優(yōu)化InnoDB磁盤(pán)I/O

增加InnoDB緩沖池大小可以讓查詢從緩沖池訪問(wèn)而不是通過(guò)磁盤(pán)I/O訪問(wèn)。通過(guò)調(diào)整系統(tǒng)變量innodb_flush_method來(lái)調(diào)整清除緩沖的指標(biāo)使其達(dá)到最佳水平。

MySQL的內(nèi)存分配

在為MySQL分配足夠的內(nèi)存之前，請(qǐng)考慮不同領(lǐng)域?qū)ySQL的內(nèi)存需求。要考慮的關(guān)鍵領(lǐng)域是：并發(fā)連接——對(duì)于大量并發(fā)連接，排序和臨時(shí)表將需要大量?jī)?nèi)存。在撰寫(xiě)本文時(shí)，對(duì)于處理3000+并發(fā)連接的數(shù)據(jù)庫(kù)，16GB到32GB的RAM是足夠的。

內(nèi)存碎片可以消耗大約10%或更多的內(nèi)存。像innodb_buffer_pool_size、key_buffer_size、query_cache_size等緩存和緩沖區(qū)要消耗大約80%的已分配內(nèi)存。

日常維護(hù)

定期檢查慢的查詢?nèi)罩静?yōu)化查詢機(jī)制以有效使用緩存來(lái)減少磁盤(pán)I/O。優(yōu)化它們，以掃描最少的行數(shù)，而不是進(jìn)行全表掃描。

其他可以幫助DBA檢查和分析性能的日志包括：錯(cuò)誤日志、常規(guī)查詢?nèi)罩尽⒍M(jìn)制日志、DDL日志(元數(shù)據(jù)日志)。

定期刷新緩存和緩沖區(qū)以降低碎片化。使用OPTIMIZETABLE語(yǔ)句重新組織表并壓縮任何可能被浪費(fèi)的空間。

上述就是小編為大家分享的使用PHPCMS用哪個(gè)數(shù)據(jù)庫(kù)比較好了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。