本文目錄一覽：
運行mysql數據庫時總出現這個錯誤怎麼解決
(1)偶爾連接不上(localhost),請查找到底是哪些頁面會出現這個問題. (2)連接使用完成後及時釋放.懷疑是你請求的連接太多,導致mysql達到了最大連接數,拒絕你的新連接.有可能是你每次連接完成都沒有使用mysql_close來關閉連接. (3)盡量避免在循環中不停的連接數據庫 (4)查看mysql的日誌,或許能查到一些線索.
服務器mysql數據庫老自動停止，請問怎麼回事
服務器mysql數據庫老自動停止是因為在設置時出現了問題，解決方法為：
1、首先登陸服務器。
2、登陸MySQL數據庫；命令如下：mysql -u root -p pwd。
3、查詢MySQL數據庫是否允許遠程ip訪問。
4、開啟遠程訪問操作。命令如下：GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’IDENTIFIED BY ‘111qqqpwd’ WITH GRANT OPTION;FLUSH PRIVILEGES。
5、打開navicate客戶端，新建mysql鏈接。
6、輸入遠程MySQL數據庫鏈接信息，點擊測試鏈接。數據庫鏈接成功。
注意事項：
MySQL 軟件採用了雙授權政策，分為社區版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇 MySQL 作為網站數據庫。
mysql幾個常見問題匯總
一、Can’t connect to MySQL server on ‘localhost’ (10061)
翻譯：不能連接到 localhost 上的mysql
分析：這說明“localhost”計算機是存在的，但在這台機器上卻沒提供MySQL服務。
需要啟動這台機器上的MySQL服務,如果機子負載太高沒空相應請求也會產生這個錯誤。
解決:既然沒有啟動那就去啟動這台機子的mysql。如果啟動不成功，多數是因為你的my.ini配置的有問題。重新配置其即可。
如果覺得mysql負載異常，可以到mysql/bin 的目錄下執行mysqladmin -uroot -p123 processlist來查看mysql當前的進程。
二、Unknown MySQL Server Host ‘localhosadst’ (11001)
翻譯：未知的MySQL服務器 localhosadst
分析：服務器 localhosasdst 不存在。或者根本無法連接
解決：仔細檢查自己論壇下面的 ./config.inc.php 找到$dbhost重新設置為正確的mysql 服務器地址。
三、Access denied for user: ‘roota@localhost’ (Using password: YES)
翻譯：用戶 roota 訪問 localhost 被拒絕（沒有允許通過）
分析：造成這個錯誤一般數據庫用戶名和密碼相對mysql服務器不正確
解決：仔細檢查自己論壇下面的 ./config.inc.php 找到$dbuser、$dbpw核實後重新設置保存即可。
四、Access denied for user: ‘red@localhost’ to database ‘newbbs’
翻譯：用戶 red 在localhost 服務器上沒有權限操作數據庫newbbs
分析：這個提示和問題三是不同的。那個是在連接數據庫的時候就被阻止了，而這個錯誤是在對數據庫進行操作時引起的。比如在select update等等。這個是因為該用戶沒有操作數據庫相應的權力。比如select 這個操作在mysql.user.Select_priv里記錄 Y 可以操作N 不可以操作。
解決：如果是自己的獨立主機那麼更新mysql.user 的相應用戶記錄，比如這裡要更新的用戶為red 。或者直接修改 ./config.inc.php 為其配置一個具有對數據庫操作權限的用戶
或者通過如下的命令來更新授權grant all privileges on dbname.* to ‘user’@’localhost’ identified by ‘password’
提示：更新了mysql庫中的記錄一定要重啟mysql服務器才能使更新生效
FLUSH PRIVILEGES;
五、No Database Selected
翻譯：沒有數據庫被選擇上
分析：產生的原因有兩種
config.inc.php 裡面$dbname設置的不對。致使數據庫根本不存在，所以在 $db-select_db($dbname); 時返回了false
和上面問題四是一樣的，數據庫用戶沒有select權限，同樣會導致這樣的錯誤。當你發現config.inc.php的設置沒有任何問題，但還是提示這個錯誤，那一定就是這種情況了。
解決：對症下藥
打開config.inc.php 找到$dbname核實重新配置並保存
同問題四的解決方法
六、Can’t open file: ‘xxx_forums.MYI’. (errno: 145)
翻譯：不能打開xxx_forums.MYI
問題分析：
這種情況是不能打開 cdb_forums.MYI 造成的，引起這種情況可能的原因有：
1、服務器非正常關機，數據庫所在空間已滿，或一些其它未知的原因，對數據庫表造成了損壞。
2、類 unix 操作系統下直接將數據庫文件拷貝移動會因為文件的屬組問題而產生這個錯誤。
解決方法：
1、修複數據表
可以使用下面的兩種方式修複數據表：（第一種方法僅適合獨立主機用戶）
1）使用 myisamchk ，MySQL 自帶了專門用戶數據表檢查和修復的工具 —— myisamchk 。更改當前目錄到 MySQL/bin 下面，一般情況下只有在這個下面才能運行 myisamchk 命令。常用的修復命令為：myisamchk -r 數據文件目錄/數據表名.MYI；
2）通過 phpMyAdmin 修復， phpMyAdmin 帶有修複數據表的功能，進入到某一個表中後，點擊“操作”，在下方的“表維護”中點擊“修復表”即可。
注意：以上兩種修復方式在執行前一定要備份數據庫。
mysql 運行問題
MYSQL只是1個連接到oracle的中間軟件。你要運行數據庫的話，首先要安裝有oracle，在安裝的時候會有個系統用戶，一般是用戶：system/密碼：system。打開MYSQL，通過system用戶能進入數據庫，進去後才可以開始創建新的用戶，導入數據，查詢數據之類的操作。
mysql數據庫崩潰的原因？
MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。
臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/308722.html
微信掃一掃 
支付寶掃一掃 