有人給出以下解決方案：
1，利用phpmyadmin >> 當前資料庫 >> wp_posts表 >> 結構》第一行(名字為id的那行)>>修改 >> 勾選a_i >> 儲存》 檢視額外變成：auto_increment
重新整理後台問題解決
2，檢查你的資料庫配置檔案my.cnf或my.ini
開啟你的mysql資料庫配置檔案：
linux版本是my.cnf，一般會放在/etc/my.cnf，/etc/mysql/my.cnf
win下的是my.ini，一般會在安裝目錄的根目錄
開啟配置檔案找到 innodb_force_recovery 引數。
innodb_force_recovery影響整個innodb儲存引擎的恢復狀況。預設為0，表示當需要恢復時執行所有的
innodb_force_recovery可以設定為1-6,大的數字包含前面所有數字的影響。當設定引數值大於0後，可以對錶進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
如果你的innodb_force_recovery引數設不是預設值0，可以修改為預設值0，重啟mysql 再看是否有效。
3，修復你的資料庫表
這個問題也有可能是某些情況下，mysql的表受到了損壞，那麼你可以修復表，一般情況下，配置檔案除非自己修改會有所改變，而資料庫表損壞是比較常見的。
文章和頁面無法發布新的，是post表出現了問題，因此我們只需要修復post表即可，進入你的資料庫管理，左鍵選取你的post表，右鍵(具體看你的資料庫面板軟體是什麼樣子的)，選擇修復表，修復完整一般這個問題即可得到解決。
博主於是按第一條方案嘗試，結果phpmyadmin根本也進不去，於是重啟了下vps，結果正常了，可是不到十分鐘用掛掉。
從上圖的下半部分可以看到，執行df -h檢查磁碟情況，硬碟已經100%使用了，原來是硬碟不足導致了。
想到最近wordpress快取可能開的有點大，還有乙個類似於搜尋引擎小偷的程式也是快取的，恍然大悟。
wordpress是我們最喜歡的cms建站系統，mysql又是我們最常用的資料庫之一，所以它們兩個碰到一起，產生一點小摩擦，也是很正常的哈。
讚賞
nginx配置後重啟無效與重啟失敗
nginx配置新增了個網域名稱配置，重啟nginx後怎麼訪問都直接到nginx的預設頁，也就是新的網域名稱配置沒生效，仔細檢視配置檔案沒發現任何問題。重啟n遍，問題依舊。在其他方面各種排查，也沒發現問題，奇了。後來偶然發現竟然啟動了兩個nginx！逐一kill掉。重啟。出現了新的問題 解決方法 找到...
關於Tomcat重啟和關閉後重啟session變化
當頁面第一次訪問，session的attribute還未賦值，為null 當頁面第二次訪問時，這時當前的session的attribute有值了！到了本文章的點題時刻！如果我是直接點選server的 之後頁面再訪問，結果如下圖所示！可以看到，session竟然沒有被清除，並且完好的儲存了下來！但是如...
IIS停掉後重啟
有時候我們在web程式如 asp,中無意中使用到了乙個死迴圈，或者在測試dll元件時，掛了。這時候iis就停止了響應，我們要繼續我們的工作啊，重啟iis服務吧。然而這個程序還在執行，internet 服務管理器還關閉不了。而當想結束inetinfo.exe 或者 dllhost.exe 程序的時候，...