一、數(shù)據(jù)庫表清理
紅橋ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書未來市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
1. wordpress數(shù)據(jù)庫表
wp_commentmeta: 用于保存評(píng)論的元信息，在將評(píng)論放入回收站等操作時(shí)會(huì)將數(shù)據(jù)放入此表，Akismet等插件也會(huì)生成此表的數(shù)據(jù)。此表不太重要
wp_comments: 用于保存評(píng)論信息的表
wp_links: 用于保存用戶輸入到Wordpress中的鏈接(通過Link Manager)的表
wp_options: 用于保存Wordpress相關(guān)設(shè)置、參數(shù)的表，里面包括了大量的重要信息
wp_postmeta: 用于保存文章的元信息(meta)的表
wp_posts: 用于保存你所有的文章相關(guān)信息的表，非常的重要。一般它存儲(chǔ)的數(shù)據(jù)是最多的
wp_terms: 文章和鏈接分類以及文章的tag分類可以在表里找到
wp_term_relationships: 日志與wp_terms中的類別與標(biāo)簽聯(lián)合起來共同存儲(chǔ)在wp_terms_relationships表中。類別相關(guān)鏈接也存儲(chǔ)在wp_terms_relationships中
wp_term_taxonomy: 該表格對(duì)wp_terms表中的條目分類（類別、鏈接以及標(biāo)簽）進(jìn)行說明
wp_usermeta : 用于保存用戶元信息(meta)的表
wp_users:用于保存Wordpress使用者的相關(guān)信息的表
2. 清理涉及到的表
更換主題，刪除插件會(huì)在將數(shù)據(jù)留在數(shù)據(jù)庫中，在卸載后無法被清理。除此之外，在由于一些操作，會(huì)導(dǎo)致數(shù)據(jù)庫的冗余，比如已經(jīng)沒有的評(píng)論，不應(yīng)該在評(píng)論元數(shù)據(jù)表中有記錄，由于沒有外鍵的約束，這些記錄沒有被刪除，會(huì)造成數(shù)據(jù)的冗余。本文的宗旨是刪除掉不必要的數(shù)據(jù)庫內(nèi)容，提高wordpress的效率
在此，主要涉及到一下幾張表：wp_options，wp_posts，wp_postmeta，wp_commentmeta
注意清理之前進(jìn)行備份
3. wp_options的清理
wp_options 這個(gè)數(shù)據(jù)表是wordpress設(shè)置的全局?jǐn)?shù)據(jù)，這個(gè)表會(huì)經(jīng)常有數(shù)據(jù)膨脹。主要原因是：
(1)以前用過的一些插件、主題在刪除之后沒有進(jìn)行設(shè)置的清理，造成殘留數(shù)據(jù)
(2)占用數(shù)據(jù)的大戶–RSS緩存，后臺(tái)的數(shù)據(jù)調(diào)用竟然會(huì)放到數(shù)據(jù)庫里面
處理方法：
①網(wǎng)上對(duì)RSS處理方法有兩種一個(gè)是修改后臺(tái)的文件直接不去調(diào)用，這個(gè)是我不喜歡的畢竟修改了程序，其實(shí)這個(gè)很容
易忘記WP升級(jí)是太頻繁的哪次更新覆蓋了新文件還是照樣緩存.另外一種就是在配置文件里面填寫define(‘MAGPIE_CACHE_ON’, ’0′); 這個(gè)是管用的,添加以后后臺(tái)首頁的調(diào)用明顯變慢
②使用插件clean options
③費(fèi)力但是簡(jiǎn)單的清除方法：刪除wp_options表，會(huì)刪除一些設(shè)置，需要重新設(shè)置wordpress，推薦新手使用
TRUNCATE TABLE wp_options;
4.wp_posts清理
wordpress的文章有好多：wp_posts表中包括
文章種類：文章、修訂版本、頁面、文章的附件、菜單
其中每種文章又會(huì)有很多狀態(tài)：繼承、發(fā)布、私有、草稿、自動(dòng)草稿、回收站中
冗余原因：
(1)在博主寫文章的時(shí)候，系統(tǒng)會(huì)保存很多的中間狀態(tài)，在文章發(fā)布之后其很多的中間狀態(tài)沒有被刪除
解決辦法：
①使用插件：WP Cleaner，使用插件的好處就是有保護(hù)機(jī)制，無論怎么操作都無法影響已發(fā)布的貼子，請(qǐng)放心使用
②自己動(dòng)手刪除，數(shù)據(jù)庫中的標(biāo)志刪除文章，注意備份
說明：wp_posts的重要字段含義：
post_type：文章類型，post表示為文章，revision表示為修訂版本，page為頁面，attachment是文章的附件信息，nav_menu_item是菜單。這里我們需要的是文章、頁面、和菜單
post_status：文章狀態(tài)，inherit是繼承的附件和文章的附帶信息，publish是已經(jīng)發(fā)布、private是私有的，draft是草稿，auto-draft是自動(dòng)草稿，trash是在回收站。這里我們需要的是publish的狀態(tài)的
這里我們主要是要 已經(jīng)發(fā)布的文章、頁面和菜單，除此之外的都可以刪除，當(dāng)然可以根據(jù)自己的需求選擇刪除哪些
DELETE FROM wp_posts
WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
③去除WP保存修訂版本的功能
WordPress默認(rèn)的功能并不都是我們想要的，比如修訂版本歷史對(duì)于大多數(shù)人來說是無用的雞肋功能。所以我么需要禁止一些博客功能，來達(dá)到較為符合個(gè)
人要求的博客應(yīng)用。對(duì)于高手來說，可以直接修改程序的配置文件，來禁止相關(guān)功能。對(duì)于我等程序小白來說還是利用插件是最佳的選擇
推薦中文插件SuperSwitch來關(guān)閉一些我們不需要的博客功能。這個(gè)插件可以關(guān)閉自動(dòng)保存和修訂歷史版本，還可以關(guān)閉博客程序、主題、插件的自動(dòng)更新。功能非常強(qiáng)大，操作及其簡(jiǎn)單。用SuperSwitch禁止了保存修訂版本之后，文章序號(hào)就不會(huì)斷得太厲害了
5.wp_postmeta清理
wp_postmeta是文章的元信息表，其數(shù)據(jù)是系統(tǒng)或者插件使用
冗余原因：
(1)文章被刪除之后，其在wp_postmeta中的數(shù)據(jù)理應(yīng)被刪除，在系統(tǒng)中多數(shù)情況是系統(tǒng)自動(dòng)刪除，但是由于人為刪除文章，系統(tǒng)不知道被刪除，就不會(huì)刪除wp_postmeta表中的數(shù)據(jù)，造成冗余
(2)很多主題、插件沒有做好及時(shí)清除的工作
解決辦法：
① 手動(dòng)刪除
規(guī)矩刪除
刪除文章中不存在文章的元信息
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT post_id FROM wp_posts);
安全刪除
刪除_edit_lock和_edit_last條目是安全的，所以這里給出SQL語句
DELETE FROM wp_postmeta WHERE meta_key = ‘_edit_lock’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_edit_last’;
風(fēng)險(xiǎn)刪除
除了這兩條還執(zhí)行了一些其他語句由于有些風(fēng)險(xiǎn)：自己酌情考慮
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_old_slug’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_revision-control’;
DELETE FROM wp_postmeta WHERE meta_value = ‘{{unknown}}’;
特殊插件刪除
postnav插件會(huì)記錄每個(gè)文章的訪問數(shù)，如果不需要，可以刪除
DELETE FROM wp_postmeta WHERE meta_key = ‘views’;
特殊操作刪除
在WordPress的后臺(tái)上傳圖片或者附件后會(huì)在wp_postmeta中生成_wp_attached_file和_wp_attachment_metadata兩個(gè)項(xiàng)，wp_posts也會(huì)記錄附件的信息。如果使用FTP工具上傳文件，表中就不會(huì)有這些信息
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attached_file’;
DELETE FROM wp_postmeta WHERE meta_key = ‘_wp_attachment_metadata’;
潔癖刪除
這幾條條語句執(zhí)行完畢能夠刪除掉95%以上的數(shù)據(jù)，算的上是極限優(yōu)化了，最后考慮到這個(gè)數(shù)據(jù)表并不是很重要，有潔
凈癖的人可以嘗試清空這個(gè)表，當(dāng)然我測(cè)試清空表會(huì)讓一些原本的數(shù)據(jù)丟失
TRUNCATE TABLE wp_postmeta;
6. wp_commentmeta清理
冗余原因：
(1)評(píng)論被刪除之后，其在wp_commentmeta中的數(shù)據(jù)理應(yīng)被刪除，在系統(tǒng)中多數(shù)情況是系統(tǒng)自動(dòng)刪除，但是由于人為刪除文章，系統(tǒng)不知道被刪除，就不會(huì)刪除wp_commentmeta表中的數(shù)據(jù)，造成冗余
(2)很多主題、插件沒有做好及時(shí)清除的工作
解決辦法：
一下語句去除沒有用的數(shù)據(jù)，如果評(píng)論中沒有此條評(píng)論，那么在wp_commentmeta也沒有意義，好像wordpress在清空回收站的時(shí)候會(huì)刪除wp_commentmeta相應(yīng)的數(shù)據(jù)。如果不出意外，下面的操作我們應(yīng)該不需要做
DELETE FROM wp_comments WHERE comment_approved = ‘trash’;
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);
在wp_commentmeta里面會(huì)記錄評(píng)論被刪除的時(shí)間，這些信息用處不是很大，當(dāng)評(píng)論被從回收站刪除之后，這些刪除的時(shí)間意義就不是很大，就可以刪除了，所以用下面的語句一樣達(dá)到刪除的目的
DELETE FROM wp_commentmeta WHERE meta_key LIKE ‘%trash%’;
如果直接全部刪除wp_commentmeta，影響不會(huì)太大，這里面不會(huì)涉及重要的數(shù)據(jù)
TRUNCATE TABLE wp_commentmeta
7. 總結(jié)
其實(shí)大部分無用的數(shù)據(jù)均在這幾張表中，清理過后應(yīng)該不會(huì)又太多的冗余數(shù)據(jù)了。但這里沒有針對(duì)特殊插件或主題做數(shù)據(jù)庫清理，有時(shí)這些插件和主題會(huì)悄悄動(dòng)了一些數(shù)據(jù)庫表，這樣給清理帶來很大難度，需要看代碼才知道哦
二、數(shù)據(jù)庫表優(yōu)化
原理：數(shù)據(jù)庫優(yōu)化不
涉及數(shù)據(jù)的刪除，是將數(shù)據(jù)庫的表的狀態(tài)調(diào)整好。在使用phpmyadmin時(shí)候，或許您會(huì)看到數(shù)據(jù)庫表后面有多余xxMB的字樣，這個(gè)指的是那些已經(jīng)分配
給當(dāng)前表但是卻沒有使用的空間。這個(gè)多余是沒有什么害處的，他不會(huì)占用你的空間。當(dāng)刪除一個(gè)表的一部分記錄時(shí),這些記錄仍然保持在一個(gè)linked
list 中，當(dāng)插入新數(shù)據(jù)時(shí)會(huì)再次使用這些老紀(jì)錄的位置。所以刪除紀(jì)錄會(huì)閑置一些空間造成你說的“多余”
優(yōu)化：
(1)在phpmyadmin手動(dòng) 優(yōu)化或者修復(fù)表即可
(2)運(yùn)行SQL：
OPTIMIZE TABLE wp_commentmeta;
OPTIMIZE TABLE wp_comments;
OPTIMIZE TABLE wp_links;
OPTIMIZE TABLE wp_options;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_terms;
OPTIMIZE TABLE wp_term_relationships;
OPTIMIZE TABLE wp_term_taxonomy;
OPTIMIZE TABLE wp_usermeta;
OPTIMIZE TABLE wp_users;
(3)插件：Optimize DB
我是使用SQL語句進(jìn)行清理與優(yōu)化的，附我的優(yōu)化SQL語句（我的表前綴是wp1）：
DELETE FROM wp1_posts WHERE NOT(post_status = ‘publish’ AND post_type IN(‘post’,'nav_menu_item’,’ page’));
DELETE FROM wp1_postmeta WHERE meta_key in (‘_edit_lock’,
‘_edit_last’, ‘_wp_old_slug’, ‘_revision-control’, ‘{{unknown}}’,
‘_wp_attached_file’, ‘_wp_attachment_metadata’);
DELETE FROM wp1_postmeta WHERE post_id NOT IN (SELECT id FROM wp1_posts);
DELETE FROM wp1_comments WHERE comment_approved like ‘%trash%’;
DELETE FROM wp1_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp1_comments);
OPTIMIZE TABLE wp1_commentmeta;
OPTIMIZE TABLE wp1_comments;
OPTIMIZE TABLE wp1_links;
OPTIMIZE TABLE wp1_options;
OPTIMIZE TABLE wp1_postmeta;
OPTIMIZE TABLE wp1_posts;
OPTIMIZE TABLE wp1_terms;
OPTIMIZE TABLE wp1_term_relationships;
OPTIMIZE TABLE wp1_term_taxonomy;
OPTIMIZE TABLE wp1_usermeta;
OPTIMIZE TABLE wp1_users;
1、選取最適用的字段屬性
MySQL可以很好的支持大數(shù)據(jù)量的存取，但是一般說來，數(shù)據(jù)庫中的表越小，在它上面執(zhí)行的查詢也就會(huì)越快。因此，在創(chuàng)建表的時(shí)候，為了獲得更好的性能，我們可以將表中字段的寬度設(shè)得盡可能小。
2、使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個(gè)技術(shù)可以使用SELECT語句來創(chuàng)建一個(gè)單列的查詢結(jié)果，然后把這個(gè)結(jié)果作為過濾條件用在另一個(gè)查詢中。例如，我們要將客戶基本信息表中沒有任何訂單的客戶刪除掉，就可以利用子查詢先從銷售信息表中將所有發(fā)出訂單的客戶ID取出來，然后將結(jié)果傳遞給主查詢。
3、使用聯(lián)合(UNION)來代替手動(dòng)創(chuàng)建的臨時(shí)表
MySQL從4.0的版本開始支持union查詢，它可以把需要使用臨時(shí)表的兩條或更多的select查詢合并的一個(gè)查詢中。在客戶端的查詢會(huì)話結(jié)束的時(shí)候，臨時(shí)表會(huì)被自動(dòng)刪除，從而保證數(shù)據(jù)庫整齊、高效。使用union來創(chuàng)建查詢的時(shí)候，我們只需要用UNION作為關(guān)鍵字把多個(gè)select語句連接起來就可以了，要注意的是所有select語句中的字段數(shù)目要想同。下面的例子就演示了一個(gè)使用UNION的查詢。
4、事務(wù)
盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯(lián)合（UNION）來創(chuàng)建各種各樣的查詢，但不是所有的數(shù)據(jù)庫操作都可以只用一條或少數(shù)幾條SQL語句就可以完成的。更多的時(shí)候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當(dāng)這個(gè)語句塊中的某一條語句運(yùn)行出錯(cuò)的時(shí)候，整個(gè)語句塊的操作就會(huì)變得不確定起來。設(shè)想一下，要把某個(gè)數(shù)據(jù)同時(shí)插入兩個(gè)相關(guān)聯(lián)的表中，可能會(huì)出現(xiàn)這樣的情況：第一個(gè)表中成功更新后，數(shù)據(jù)庫突然出現(xiàn)意外狀況，造成第二個(gè)表中的操作沒有完成，這樣，就會(huì)造成數(shù)據(jù)的不完整，甚至?xí)茐臄?shù)據(jù)庫中的數(shù)據(jù)。要避免這種情況，就應(yīng)該使用事務(wù)，它的作用是：要么語句塊中每條語句都操作成功，要么都失敗。換句話說，就是可以保持?jǐn)?shù)據(jù)庫中數(shù)據(jù)的一致性和完整性。事物以BEGIN關(guān)鍵字開始，COMMIT關(guān)鍵字結(jié)束。在這之間的一條SQL操作失敗，那么，ROLLBACK命令就可以把數(shù)據(jù)庫恢復(fù)到BEGIN開始之前的狀態(tài)。
5、鎖定表
盡管事務(wù)是維護(hù)數(shù)據(jù)庫完整性的一個(gè)非常好的方法，但卻因?yàn)樗莫?dú)占性，有時(shí)會(huì)影響數(shù)據(jù)庫的性能，尤其是在很大的應(yīng)用系統(tǒng)中。由于在事務(wù)執(zhí)行的過程中，數(shù)據(jù)庫將會(huì)被鎖定，因此其它的用戶請(qǐng)求只能暫時(shí)等待直到該事務(wù)結(jié)束。如果一個(gè)數(shù)據(jù)庫系統(tǒng)只有少數(shù)幾個(gè)用戶來使用，事務(wù)造成的影響不會(huì)成為一個(gè)太大的問題；但假設(shè)有成千上萬的用戶同時(shí)訪問一個(gè)數(shù)據(jù)庫系統(tǒng)，例如訪問一個(gè)電子商務(wù)網(wǎng)站，就會(huì)產(chǎn)生比較嚴(yán)重的響應(yīng)延遲。其實(shí)，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。
6、使用外鍵
鎖定表的方法可以維護(hù)數(shù)據(jù)的完整性，但是它卻不能保證數(shù)據(jù)的關(guān)聯(lián)性。這個(gè)時(shí)候我們就可以使用外鍵。
7、使用索引
索引是提高數(shù)據(jù)庫性能的常用方法，它可以令數(shù)據(jù)庫服務(wù)器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當(dāng)中包含有MAX(),MIN()和ORDERBY這些命令的時(shí)候，性能提高更為明顯。
希望可以幫到你，謝謝！
Z-Blog里面有三個(gè)插件是做搜索引擎優(yōu)化（SEO）必不可少。
Google站點(diǎn)地圖
Ping中心和引用通告發(fā)送器
標(biāo)題搜索引擎優(yōu)化
1、Z-Blog 默認(rèn)模板里面是沒有keywords，description等meta標(biāo)簽的。有很多的SEO文章說著兩個(gè)都要加進(jìn)去。但我的建議是Description就不要加了，這個(gè)容易出錯(cuò)?？梢栽赲THEMES\xxxxxxxx\TEMPLATE目錄下的找到single.html（xxxxxxx是你用的主題名稱）。
在文件的title里加入如下代碼：
meta name="Keywords" content="#article/tagtoname#"
2、于h1和h2的使用。 h1/h1在標(biāo)準(zhǔn)化里面的意義是表示標(biāo)題，而并不是用來弄大小。Z-Blog里面用h1顯示了網(wǎng)站名稱，用h2顯示副標(biāo)題。但顯然把這個(gè)h1留給文章的標(biāo)題更加合適。你可以在同樣的目錄里找到single.html default.html catalog.html三個(gè)文件。
把其中的h1 換成h2，h2換成h3（記得前后都要換） 。
h1 id="BlogTitle"a href="#ZC_BLOG_HOST#"#ZC_BLOG_NAME#/a/h1
h2 id="BlogSubTitle"#ZC_BLOG_SUB_NAME#/h2
然后再把文章的標(biāo)題用h1表示。在有的SEO文章里面，提到了文章標(biāo)題用h1，但是沒有指出文章標(biāo)題的位置。準(zhǔn)確的說，文章的標(biāo)題并不在single.html里面，而是在目錄內(nèi)的b_article-single.html里面。找到它，把其中的h2換成h1，同樣前后都要換。
h2 class="post-title"#article/title#/h2
zblog文章太多了吧，文章多查詢數(shù)據(jù)庫就會(huì)很卡，升級(jí)你的服務(wù)器，優(yōu)化mysql以及php時(shí)間。
重慶分公司
重慶分公司
