MySQL長途拜訪設置最終辦法。本站提示廣大學習愛好者：（MySQL長途拜訪設置最終辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL長途拜訪設置最終辦法正文
數據庫關於辦事端開辟人員來講，簡直就是左膀右臂。簡直每個辦事端開辟人員都要和數據庫打交道。而MySQL又以其開源收費，玲珑小巧，簡略易用，功效壯大占領中國數據庫應用份額的荊棘銅駝。從客歲接觸到Vagrant以來，Vagrant以其便利易用深深吸引了D瓜哥。為了盡量地和臨盆情況堅持盡量的分歧性，削減不用要的成績的產生，Vagrant+Ubuntu+MySQL簡直是絕配。
MySQL許可長途拜訪的設置
1.正文bind-address = 127.0.0.1。
>cd /etc/mysql
>sudo vim my.cnf
將bind-address = 127.0.0.1正文失落（即外行首加#），以下：
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
# bind-address = 127.0.0.1
除注目失落這句話以外，還可以把前面的IP地址修正成許可銜接的IP地址。然則，假如只是開辟用的數據庫，為了便利起見，照樣推舉直接正文失落。
從下面的正文中，可以看出，舊版本的MySQL（從一些材料上顯示是5.0及其之前的版本）上應用的是skip-networking。所以，好心提示一下，應用舊版本的小同伴請留意一下。
2.刪除匿名用戶
登錄進數據庫：
>mysql -uroot -p123456
然後，切換到數據庫mysql。SQL以下：
use mysql;
然後，刪除匿名用戶。SQL以下：
delete from user where user='';
3.增長許可長途拜訪的用戶或許許可現有效戶的長途拜訪。
接著下面，刪除匿名用戶後，給root授與在隨意率性主機（%）拜訪隨意率性數據庫的一切權限。SQL語句以下：
mysql> grant all privileges on *.* to 'root'@'%' identified by '123456' with grant option;
假如須要指定拜訪主機，可以把%調換為主機的IP或許主機名。別的，這類辦法會在數據庫mysql的表user中，增長一筆記錄。假如不想增長記載，只是想把某個已存在的用戶（例如root）修正成許可長途主機拜訪，則可使用以下SQL來完成：
update user set host='%' where user='root' and host='localhost';
4.加入數據庫
mysql> exit
在MySQL Shell履行完SQL後，須要加入到Bash履行體系敕令，須要履行exit。由於這個太經常使用也太簡略。以下內容就提醒“加入”，不再反復列出這個敕令。
5.重啟數據庫
完成上述一切步調後，須要重啟一下數據庫，能力讓修正的設置裝備擺設失效。履行以下敕令重啟數據庫：
>sudo service mysql restart
到此為止，應當便可以長途拜訪數據庫了。
固然，“雄關慢道真如鐵”，世界其實不是想象的那末圖樣圖森破，能夠還會碰到一些成績，影響到正常應用。上面，D瓜哥把本身碰到的一些成績整頓處置，便利列位同伙參考處理。（退一步講，沒有這些成績來撐門面，D瓜哥該叫“最終處理方法”嗎？！哈哈）
罕見成績解答
華仔說的好啊，“出來混的都是要還的”。關於我們從事挨踢行業的小同伴來講，“出來混的都是從成績堆裡走的”。馮鞏也說的好，“作為北京人，兜裡沒揣兩千塊錢都欠好意思給他人打召喚”。D瓜哥想，關於干挨踢的小同伴們來講，沒碰到干預干與題，都欠好意思說本身是干挨踢的。所以，關於一些罕見的成績，或許說是經常使用操作能夠激發的成績來講，有需要整頓一下，便利今後隨時查閱應用。
ERROR 1045 (28000)毛病的緣由和處理方法
>mysql -uroot -p123456
Warning: Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
假如沒有依照下面流程，刪除匿名用戶，再或許你是依照網上查的材料來停止設置（年夜多都沒有“刪除匿名用戶”這步），都能夠招致這個成績。至於這個成績的緣由說起來，D瓜哥感到“怪怪”的。要說清晰這個緣由，還得從MySQL數據庫的用戶認證機制說起。
MySQL中，用戶相干的信息存在數據庫mysql的user。然我們看一下該表的構造，敕令和前往值以下：
mysql> desc user;
+------------------------+-----------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------+-----------------------------------+------+-----+---------+-------+
| Host | char(60) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Password | char(41) | NO | | | |
| Select_priv | enum('N','Y') | NO | | N | |
| Insert_priv | enum('N','Y') | NO | | N | |
| Update_priv | enum('N','Y') | NO | | N | |
| Delete_priv | enum('N','Y') | NO | | N | |
| Create_priv | enum('N','Y') | NO | | N | |
| Drop_priv | enum('N','Y') | NO | | N | |
| Reload_priv | enum('N','Y') | NO | | N | |
| Shutdown_priv | enum('N','Y') | NO | | N | |
| Process_priv | enum('N','Y') | NO | | N | |
| File_priv | enum('N','Y') | NO | | N | |
| Grant_priv | enum('N','Y') | NO | | N | |
| References_priv | enum('N','Y') | NO | | N | |
| Index_priv | enum('N','Y') | NO | | N | |
| Alter_priv | enum('N','Y') | NO | | N | |
| Show_db_priv | enum('N','Y') | NO | | N | |
| Super_priv | enum('N','Y') | NO | | N | |
| Create_tmp_table_priv | enum('N','Y') | NO | | N | |
| Lock_tables_priv | enum('N','Y') | NO | | N | |
| Execute_priv | enum('N','Y') | NO | | N | |
| Repl_slave_priv | enum('N','Y') | NO | | N | |
| Repl_client_priv | enum('N','Y') | NO | | N | |
| Create_view_priv | enum('N','Y') | NO | | N | |
| Show_view_priv | enum('N','Y') | NO | | N | |
| Create_routine_priv | enum('N','Y') | NO | | N | |
| Alter_routine_priv | enum('N','Y') | NO | | N | |
| Create_user_priv | enum('N','Y') | NO | | N | |
| Event_priv | enum('N','Y') | NO | | N | |
| Trigger_priv | enum('N','Y') | NO | | N | |
| Create_tablespace_priv | enum('N','Y') | NO | | N | |
| ssl_type | enum('','ANY','X509','SPECIFIED') | NO | | | |
| ssl_cipher | blob | NO | | NULL | |
| x509_issuer | blob | NO | | NULL | |
| x509_subject | blob | NO | | NULL | |
| max_questions | int(11) unsigned | NO | | 0 | |
| max_updates | int(11) unsigned | NO | | 0 | |
| max_connections | int(11) unsigned | NO | | 0 | |
| max_user_connections | int(11) unsigned | NO | | 0 | |
| plugin | char(64) | YES | | | |
| authentication_string | text | YES | | NULL | |
| password_expired | enum('N','Y') | NO | | N | |
+------------------------+-----------------------------------+------+-----+---------+-------+
43 rows in set (0.00 sec)
或許檢查一下該表的建表語句。敕令以下：
mysql> show create table user;
因為前往值中攙雜了一些不用要的無用信息，為了便利年夜家檢查，D瓜哥對前往值做了簡略的處置，只把最重要的建表語句部門提掏出來。以下：
CREATE TABLE `user` (
`Host` char(60) COLLATE utf8_bin NOT NULL DEFAULT '',
`User` char(16) COLLATE utf8_bin NOT NULL DEFAULT '',
`Password` char(41) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '',
`Select_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Insert_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Update_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Delete_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Drop_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Reload_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Shutdown_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Process_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`File_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Grant_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`References_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Index_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Alter_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Show_db_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Super_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_tmp_table_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Lock_tables_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Execute_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Repl_slave_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Repl_client_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_view_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Show_view_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_routine_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Alter_routine_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_user_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Event_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Trigger_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`Create_tablespace_priv` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
`ssl_type` enum('','ANY','X509','SPECIFIED') CHARACTER SET utf8 NOT NULL DEFAULT '',
`ssl_cipher` blob NOT NULL,
`x509_issuer` blob NOT NULL,
`x509_subject` blob NOT NULL,
`max_questions` int(11) unsigned NOT NULL DEFAULT '0',
`max_updates` int(11) unsigned NOT NULL DEFAULT '0',
`max_connections` int(11) unsigned NOT NULL DEFAULT '0',
`max_user_connections` int(11) unsigned NOT NULL DEFAULT '0',
`plugin` char(64) COLLATE utf8_bin DEFAULT '',
`authentication_string` text COLLATE utf8_bin,
`password_expired` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N',
PRIMARY KEY (`Host`,`User`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Users and global privileges'
從下面兩個辦法中的任何一個都可以看出，MySQL中，應用(Host, User)如許的組合鍵作為主鍵，也就是標識獨一一個用戶。換句話說，即便關於統一個用戶名，例如root，跟著host的分歧，也表現分歧的用戶，便可以由分歧的暗碼和權限。這是，我們可以檢查一下該表內的數據。SQL和前往值以下：
mysql> select user, host, password from user;
+------------------+--------------------------+-------------------------------------------+
| user | host | password |
+------------------+--------------------------+-------------------------------------------+
| root | % | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| root | vagrant-ubuntu-trusty-64 | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| root | 127.0.0.1 | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| root | ::1 | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| | localhost | |
| | vagrant-ubuntu-trusty-64 | |
| debian-sys-maint | localhost | *9B8E84CA988E1CA66CEB919A0D9D3BF1532942B6 |
+------------------+--------------------------+-------------------------------------------+
7 rows in set (0.00 sec)
可以看到數據庫中有如上這些用戶。那末，假如有'root'@'localhost'登錄時，怎樣婚配呢？
依據MySQL官方文檔MySQL :: MySQL 5.6 Reference Manual :: 6.2.4 Access Control, Stage 1: Connection Verification裡是以下面如許說的：
When multiple matches are possible, the server must determine which of them to use. It resolves this issue as follows:
Whenever the server reads the user table into memory, it sorts the rows.
When a client attempts to connect, the server looks through the rows in sorted order.
The server uses the first row that matches the client host name and user name.
The server uses sorting rules that order rows with the most-specific Host values first. Literal host names and IP addresses are the most specific. (The specificity of a literal IP address is not affected by whether it has a netmask, so 192.168.1.13 and 192.168.1.0/255.255.255.0 are considered equally specific.) The pattern ‘%' means “any host” and is least specific. The empty string ” also means “any host” but sorts after ‘%'. Rows with the same Host value are ordered with the most-specific User values first (a blank User value means “any user” and is least specific).
請留意這句話：“The server uses sorting rules that order rows with the most-specific Host values first. Literal host names and IP addresses are the most specific.”
那末，當從當地銜接到數據庫時，匿名用戶將籠罩其他如'[any_username]'@'%'之類的用戶。詳細婚配進程以下：
在'root'@'localhost'可以婚配'root'@'%'，''也能夠婚配root，那末'root'@'localhost'也能夠婚配''@'localhost'。依據下面的文檔顯示，主機（host）有比用戶稱號user更高的婚配優先級，則localhost比%有比更高的婚配優先級。所以，''@'localhost'比'root'@'%'婚配優先級更高，'root'@'localhost'就婚配到了''@'localhost'。依據我們下面的查詢成果來看，''@'localhost'的暗碼為空，與登錄時供給的暗碼123456不婚配。所以，就登錄掉敗了。
說到這裡，想必年夜家曾經想到懂得決計劃：很簡略，直接把匿名用戶刪失落便可以了。
然則，如今的成績時，在當地基本登錄不上數據庫，更別扯刪除數據了。
怎樣辦？D瓜哥想到了三個處理方法，辦法以下：
①、比擬扯淡的處理辦法，在別的一台電腦或許虛擬機上，長途銜接這個數據庫
這是我想到的一個比擬扯淡的處理辦法。既然我們曾經許可了長途銜接，那末我們便可以在別的一台電腦或許別的一個虛擬機上，長途銜接到這個數據庫，然後把刪除匿名用戶。步調以下：
1.在長途電腦上銜接到該數據庫。敕令以下：
mysql -h192.168.1.119 -uroot -p123456
2.然後，切換到mysql數據庫。敕令以下：
use mysql
3.刪除匿名用戶。SQL以下：
delete from user where user='';
4.加入，然後便可以在當地直接登錄數據庫了。
②、投契取巧的處理方法，在當地應用跳過權限表認證的登錄數據庫
方才在下面的緣由說明中曾經說過，固然登錄應用的root帳號，然則被數據庫處置成了匿名用戶。而登錄用的帳號和暗碼與匿名帳號信息不婚配，才招致權限認證沒有經由過程。那爽性就“不走平常路”，跳過權限認證這一步，直接登錄不就OK了。詳細做法相似“忘卻暗碼”的處置方法相似，所以，可以參考上面的 忘卻數據庫暗碼 。須要留意的時，這裡和“忘卻數據庫暗碼”的處置紛歧樣的是，這裡不須要這裡只須要登錄出來，登錄出來以後須要刪除匿名帳號而不是重置暗碼。至於刪除匿名帳號的辦法，請參考下面的引見，這裡就不再贅述。
③、最詭異的處理方法，在當地假裝成長途主機來登錄數據庫
既然假如不曉得IP地址，MySQL會默許以為從當地主機登錄。那末，我們就指定一下主機，把本身假裝成長途主機登錄。D瓜哥以為這個處理方法從MySQL的認證機制上是說得通的。
起首，應用ifconfig查出當地主機的IP（留意，不是127開首的回環地址）。
然後，應用以下敕令登錄：
mysql -h192.168.1.119 -uroot -p123456
再然後的任務就是刪除匿名用戶。下面曾經引見過了，這裡不再贅述。
關於這個辦法，D瓜哥須要特殊解釋一下。這個辦法是D瓜哥推想出來的，還經由現實測試。所以，所以，迎接板磚和雞蛋！哈哈
忘卻MySQL用戶暗碼的處理方法
由於須要用一個很久不怎樣應用的數據庫，暗碼忘卻了，所以碰到了這個成績。此次原來沒盤算寫這個內容，然則籌劃趕不上變更，由於碰到了ERROR 1045 (28000)。後來，發明應用這個辦法也能夠處理失落這個成績。為了今後本身查材料便利，爽性把這個主題提出來，作為“罕見成績”之一，也記載一下。
1.停滯MySQL數據庫。敕令以下：
sudo service mysql stop
暴力點的做法是，應用ps敕令查出來MySQL數據庫的PID，然後在應用kill -9 PID直接殺失落數據庫過程。這個辦法，太甚血腥，就不供給敕令了。呵呵
2.啟動數據庫。敕令以下：
sudo mysqld_safe --skip-grant-tables &
解釋：參數--skip-grant-tables的意思是啟動MySQL辦事的時刻跳過權限表認證。啟動後，銜接到MySQL的root不須要口令。
別的，某些盤算機上沒有裝置mysqld_safe敕令，則可使用以下敕令來啟動數據庫：
sudo mysqld --skip-grant-tables &
除此以外，還可以修正MySQL的設置裝備擺設文件/etc/mysql/my.cnf，在[mysqld]的部門中加上一句：skip-grant-tables。然則，應用這類方法在重置完暗碼後，還要再從新刪除這句話。D瓜哥小我感到比擬費事。僅做懂得，不推舉應用這類方法。
3.登錄數據庫。敕令以下：
mysql -uroot
4.切換到mysql數據庫
mysql> use mysql
5.修正root帳號暗碼
mysql> update user set password=password('123456') where user='root';
6.加入，然後重啟數據庫
>sudo service mysql restart
如今，應當便可以應用新暗碼正常拜訪數據庫了。
ERROR 2002 (HY000)毛病的緣由和處理方法
在登錄數據庫的進程中，能夠碰到以下毛病：
mysql -uroot
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
剛開端，D瓜哥認為是數據庫沒有准確創立mysqld.sock這個文件，到/var/run/mysqld/下檢查了一下，確切沒有這個文件。
這是怎樣回事？怎樣會沒有這個文件呢？豈非數據庫沒有啟動起來。應用以下敕令檢查一下：
>ps aux | grep mysql
Shit，居然甚麼都沒有輸入。看來確切是數據庫沒有啟動起來。應用以下敕令啟動數據庫：
>sudo service mysql start
假如是須要啟動跳過認證的方法啟動，則應用以下敕令之一：
sudo mysqld_safe --skip-grant-tables &
假如提醒沒有mysqld_safe，則應用以下敕令：
>sudo mysqld --skip-grant-tables &
然後便可以正常登錄了。
關於這個成績，D瓜哥還想再多說兩句：這個毛病的基本緣由是沒有找到mysqld.sock文件，形成這個成績的緣由有兩種：一基本沒有創立這個文件，也就是沒有啟動數據庫，這也是D瓜哥在這裡引見的緣由；別的一個緣由也有能夠是創立的目次不在默許目次，或許銜接數據庫時指定的這個文件目次和現實發生的目次不符。D瓜哥在網上查材料時，也印著了這個猜想。部門網友的成績就是D瓜哥所說的第二個緣由形成的。所以，網上關於這個成績的處理計劃還存在別的一個辦法。由於D瓜哥沒有碰到，並且情形又比擬多，D瓜哥這裡就不再過量引見了。請碰到這個成績的同伙自行查材料處理。
ERROR 2003 (HY000)毛病的緣由和處理方法。
$ mysql -h192.168.1.113 -uroot -p123456
Warning: Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.113' (111)
是措辭，湧現這個成績，D瓜哥也很蛋疼。不知這又是怎樣弄的！不外，好在有毛病代碼（ERROR 2003 (HY000)），有了這個就有了翻開處理辦法之門的鑰匙。處理辦法垂手可得。
用Google百度一下，以後在StackOverflow上查到了緣由：MySQL數據庫的設置裝備擺設文件/etc/mysql/my.cnf中的bind-address = 127.0.0.1沒有正文失落，招致MySQL只能吸收當地的拜訪。
曉得了緣由，處理辦法也就隨之而來，正文失落這行，然後重啟辦事器。詳細做法，參考本文開首部門。
ERROR 1130毛病的緣由和處理方法
D瓜哥在查材料的進程中，還碰到他人提到的一個毛病。日記以下：
ERROR 1130: Host '192.168.1.3' is not allowed to connect to this MySQL server
給的解答是“所用主機的IP地址不在被許可登錄的IP以內”。
D瓜哥也測試了一下這個毛病。方才開端測試的時刻，這個毛病沒有重現，還認為我測試有成績。後來，重啟了一下數據庫，再次測試發明勝利了。確切有這個毛病。別的，依據D瓜哥小我測試經歷，好心提示一句，對mysql.user表停止修正後，記得履行一下flush privileges或許重啟一下數據庫。
關於mysqld_safe的簡介
在此次處理這些成績的進程中，D瓜哥檢查了一下MySQL的過程。敕令和前往值以下：
>ps aux | grep mysql
root 1231 0.0 0.0 4444 740 ? S 15:09 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 1604 0.9 23.0 1134700 471332 ? Sl 15:09 0:23 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root 1605 0.0 0.0 4340 644 ? S 15:09 0:00 logger -t mysqld -p daemon.error
vagrant 3942 0.0 0.0 12140 928 pts/0 S+ 15:51 0:00 grep --color mysql
嗯？！有木有發明一個方才解釋的熟習的東東：mysqld_safe。這個東東怎樣啟動起來呢？剛開端D瓜哥認為這個器械不該該啟動，乃至還能夠招致長途登錄數據庫不勝利。（由於其時確切有這個成績。並且，在下面跳過認證校驗的啟動時，用到這個敕令了。所以，D瓜哥以為它不該該被啟動。）經由和仇敵（你曉得，這確定是這裡提到的一些成績）“艱難卓絕”奮斗後，發明成績不是這個東東形成的。幸虧多思慮了一點，不然D瓜哥晚節不保啊！哈哈
由於方才認為這是個成績。所以，就把這個參加到了成績列內外。經由D瓜哥的懂得，發明這不是個成績，然則關於D瓜哥來講，這確切處理了D瓜哥的一個疑問，也暫且算是成績吧。為了便利有異樣成績的小同伴，D瓜哥認為有需要把mysqld_safe給具體解釋一下。
關於mysqld_safe的引見，最威望的材料天然是官方文檔，因為D瓜哥應用的是MySQL 5.6版。所以，這裡參考MySQL :: MySQL 5.6 Reference Manual :: 4.3.2 mysqld_safe — MySQL Server Startup Script來停止解釋。以下內容翻譯自官方文檔的解釋。
官方文檔中，關於mysqld_safe部門的題目，便可以很好地解釋mysqld_safe的定位：MySQL辦事器的啟動劇本。注釋內容還說到，在Unix下，mysqld_safe是推舉的MySQL辦事器的啟動方法。mysqld_safe可以增長一些平安特征，好比當辦事器產生毛病時，重啟數據庫辦事器，而且將運轉信息記載到毛病日記文件中。
更多信息，還請列位同伙自行查閱MySQL :: MySQL 5.6 Reference Manual :: 4.3.2 mysqld_safe — MySQL Server Startup Script。不外，這裡沒有講到我們方才應用的參數--skip-grant-tables，關於這個參數，在MySQL :: MySQL 5.6 Reference Manual :: 5.1.3 Server Command Options中做了引見。
flush privileges的說明解釋
好吧，D瓜哥認可這是一個不是成績的成績。然則，關於D瓜哥來講，這照樣一個困惑，或許說，D瓜哥想曉得這句話切實其實切寄義。
從字面意思來講，flush privileges可以翻譯為“刷新權限”。這個也確切是flush privileges的一個功效：從數據庫msql中的受權表中，從新加載權限成果。
mysql新設置用戶或更改暗碼後需用flush privileges刷新mysql的體系權限相干表，不然會湧現謝絕拜訪；還有一種辦法，就是從新啟動mysql數據庫，來使新設置失效。
除此以外，flush privileges還可以釋放內存的功效。mysql會緩存grant，create user，create server和install plugin語句的成果。這些內存直到履行revoke，drop user，drop server和uninstall plugin才會釋放。所以，假如數據庫履行了許多後面的語句，則會增長內存開支。履行flush privileges就會釋放這部門的內存。
