我的mysql怎么用不了

很明顯時(shí)你創(chuàng)建表的語(yǔ)句出錯(cuò)了。你把創(chuàng)建表的語(yǔ)句發(fā)出來，即使大家看見了也不會(huì)暴露你的機(jī)密的，但是大家必須得看見才知道錯(cuò)誤在那里。

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)化州免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了1000+企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

另外你隨便找個(gè)翻譯軟件翻譯一下就知道了，這段英語(yǔ)說的是你語(yǔ)句錯(cuò)誤，不是MYSQL錯(cuò)誤。

mysql剛裝好時(shí)有用。能啟動(dòng)，然后注銷一下，或重啟一下就沒用了，1067錯(cuò)誤。

方法一：1、打開my.ini文件，找到default-storage-engine=InnoDB這一行，把它改成default-storage-engine=MyISAM。2、刪除在MySQL安裝目錄下的Data目錄中的ib_logfile0和ib_logfile13。找到在配置MySQL服務(wù)器時(shí)指定的InfoDB目錄刪除掉ibdata1根據(jù)my.ini文件中：#***INNODBSpecificoptions***innodb_data_home_dir="D:/"。4。重新啟動(dòng)MySQL的Service方法二：重裝mysql時(shí)，一直提示“無法啟動(dòng)MYSQL服務(wù)，錯(cuò)誤1067進(jìn)程意外終止重啟，修復(fù)注冊(cè)表都沒什么用，網(wǎng)上查了，改什么basedir,也沒用我用的是mysql5.8,找來找去，想起之前裝了wampserver,pc_webserver等集成環(huán)境，此些軟件會(huì)把my.ini,php.ini寫入C:WINDOWS目錄下，并設(shè)為只讀解決方法：把windows目錄下，my.ini文件刪除，重裝mysql,服務(wù)啟動(dòng)成功

mysql5.0安裝了怎么不能使用

方法/步驟

1

下載最新MYSQL數(shù)據(jù)庫(kù)安裝文件，打開下載的mysql安裝文件mysql-5.0.27-win32.zip，雙擊解壓縮，運(yùn)行“setup.exe”，出現(xiàn)如下界面：然后按“Next”繼續(xù)，選擇安裝類型，有“Typical（默認(rèn)）”、“Complete（完全）”、“Custom（用戶自定義）”三個(gè)選項(xiàng)，我們選擇“Typical”，以簡(jiǎn)化安裝過程。點(diǎn)擊“Next”進(jìn)行下一步，可根據(jù)自己的需要點(diǎn)擊“Change”來自定義安裝目錄

2

點(diǎn)擊“Next”進(jìn)行下一步，確認(rèn)一下先前的設(shè)置，如果有誤，按“Back”返回重做。按“Install”開始安裝；現(xiàn)在軟件安裝完成了，出現(xiàn)上面的界面，這里有一個(gè)很好的功能，mysql配置向?qū)?，不用向以前一樣，自己手?dòng)亂七八糟的配置my.ini了，將 “Configure the Mysql Server now”前面的勾打上，點(diǎn)“Finish”結(jié)束軟件的安裝并啟動(dòng)mysql配置向?qū)В?/p>

3

啟動(dòng)MYSQL配置向?qū)?，然后選擇配置方式，“Detailed Configuration（手動(dòng)精確配置）”、“Standard Configuration（標(biāo)準(zhǔn)配置）”，我們選擇“Standard Configuration”，以簡(jiǎn)化配置過程。選擇服務(wù)器類型，“Developer Machine（開發(fā)測(cè)試類，mysql占用很少資源）”、“Server Machine（服務(wù)器類型，mysql占用較多資源）”、“Dedicated MySQL Server Machine（專門的數(shù)據(jù)庫(kù)服務(wù)器，mysql占用所有可用資源）”，建議選擇“Server Machine”

4

選擇mysql數(shù)據(jù)庫(kù)的大致用途，“Multifunctional Database（通用多功能型，好）”、“Transactional Database Only（服務(wù)器類型，專注于事務(wù)處理，一般）”、“Non-Transactional Database Only（非事務(wù)處理型，較簡(jiǎn)單，主要做一些監(jiān)控、記數(shù)用，對(duì)MyISAM數(shù)據(jù)類型的支持僅限于non-transactional），建議選擇“Multifunctional Database”， 按“Next”繼續(xù)。 對(duì)InnoDB Tablespace進(jìn)行配置，就是為InnoDB 數(shù)據(jù)庫(kù)文件選擇一個(gè)存儲(chǔ)空間，如果修改了，要記住位置，重裝的時(shí)候要選擇一樣的地方，否則可能會(huì)造成數(shù)據(jù)庫(kù)損壞，當(dāng)然，對(duì)數(shù)據(jù)庫(kù)做個(gè)備份就沒問題了，這里不詳述。我這里沒有修改，使用用默認(rèn)位置，直接按“Next”繼續(xù)

5

選擇您的數(shù)據(jù)庫(kù)mysql訪問量，同時(shí)連接的數(shù)目，“Decision Support(DSS)/OLAP（20個(gè)左右）”、“Online Transaction Processing(OLTP)（500個(gè)左右）”、“Manual Setting（手動(dòng)設(shè)置，自己輸一個(gè)數(shù)）”，按“Next”繼續(xù)； 選擇是否啟用TCP/IP連接，設(shè)定端口，如果不啟用，就只能在自己的機(jī)器上訪問mysql數(shù)據(jù)庫(kù)了，我這里啟用，把前面的勾打上，Port Number：3306，在這個(gè)頁(yè)面上，您還可以選擇“啟用標(biāo)準(zhǔn)模式”（Enable Strict Mode），按“Next”繼續(xù)。 對(duì)mysql默認(rèn)數(shù)據(jù)庫(kù)語(yǔ)言編碼進(jìn)行設(shè)置，第一個(gè)是西文編碼，第二個(gè)是多字節(jié)的通用utf8編碼，都不是我們通用的編碼，這里選擇第三個(gè)，然后在Character Set那里選擇或填入“gbk” 選擇是否將mysql安裝為windows服務(wù)，還可以指定Service Name（服務(wù)標(biāo)識(shí)名稱），是否將mysql的bin目錄加入到Windows PATH（加入后，就可以直接使用bin下的文件，而不用指出目錄名，比如連接，“mysql.exe -uusername -ppassword;”就可以了，不用指出mysql.exe的完整地址，很方便），我這里全部打上了勾，Service Name不變。按“Next”繼續(xù)。

6

這一步詢問是否要修改默認(rèn)root用戶（超級(jí)管理）的密碼（默認(rèn)為空），“New root password”如果要修改，就在此填入新密碼，請(qǐng)記好此密碼，在配置博一短信平臺(tái)數(shù)據(jù)庫(kù)連接時(shí)需要用到這個(gè)密碼；“Enable root access from remote machines（是否允許root用戶在其它的機(jī)器上登陸，為了安全，建議不要勾上，“Create An Anonymous Account（新建一個(gè)匿名用戶，匿名用戶可以連接數(shù)據(jù)庫(kù)，不能操作數(shù)據(jù)，包括查詢）”，一般就不用勾了，設(shè)置完畢，按“Next”繼續(xù)； 確認(rèn)設(shè)置無誤，如果有誤，按“Back”返回檢查。按“Execute”使設(shè)置生效。設(shè)置完畢，按“Finish”結(jié)束mysql的安裝與配置

阿里四面：為何MySQL沒有使用建立的索引？

MySQL選了個(gè)不恰當(dāng)索引而導(dǎo)致的慢查詢。

某晚收到了線上數(shù)據(jù)庫(kù)的頻繁報(bào)警，數(shù)據(jù)庫(kù)突然大量慢查詢，導(dǎo)致每個(gè)數(shù)據(jù)庫(kù)連接執(zhí)行一個(gè)慢查詢都要耗費(fèi)很久。這還導(dǎo)致突然過來的很多查詢需要讓MySQL開辟更多連接，因此報(bào)警也告訴我們，數(shù)據(jù)庫(kù)的連接劇增，而且每個(gè)連接都打滿，每個(gè)連接都要執(zhí)行一個(gè)慢查詢。

接著DB的連接全部打滿，無法開辟新連接，但還持續(xù)的有新的查詢請(qǐng)求，導(dǎo)致DB無法處理新查詢，很多查詢發(fā)到DB直接就阻塞然后超時(shí)，導(dǎo)致商品系統(tǒng)頻繁的報(bào)警，出現(xiàn)大量DB查詢超時(shí)報(bào)錯(cuò)的異常。

這意味著商品數(shù)據(jù)庫(kù)及商品系統(tǒng)瀕臨崩潰，大量慢查詢耗盡DB連接資源，而且一直阻塞在數(shù)據(jù)庫(kù)里執(zhí)行，數(shù)據(jù)庫(kù)沒法執(zhí)行新的查詢，商品數(shù)據(jù)庫(kù)無法執(zhí)行查詢，用戶沒法使用商品系統(tǒng)，也就沒法查詢和篩選電商網(wǎng)站里的商品了。

報(bào)警時(shí)機(jī)又正是晚高峰，雖說商品數(shù)據(jù)有多級(jí)緩存架構(gòu)，但下單過程中，還是會(huì)大量請(qǐng)求商品系統(tǒng)，所以晚高峰時(shí)，商品系統(tǒng)本身TPS大致幾千。因此發(fā)現(xiàn)數(shù)據(jù)庫(kù)的監(jiān)控里顯示每min的慢查詢超過10w+：商品系統(tǒng)大量的查詢都變成了慢查詢。

慢查詢主要就是如下語(yǔ)句：

該語(yǔ)句執(zhí)行的商品表里大致1億左右數(shù)據(jù)量，該量級(jí)已穩(wěn)定很長(zhǎng)時(shí)間，主要也就是這么多商品，但上面語(yǔ)句居然一執(zhí)行就是幾十s！基本上數(shù)據(jù)庫(kù)的連接全部被慢查詢打滿，一個(gè)連接要執(zhí)行幾十s的SQL，然后才能執(zhí)行下一個(gè)SQL，此時(shí)數(shù)據(jù)庫(kù)基本就廢了，沒法執(zhí)行什么查詢。所以商品系統(tǒng)本身也報(bào)警查詢數(shù)據(jù)庫(kù)的超時(shí)異常。

經(jīng)常用到的查詢字段肯定都建了索引，即index_category(catetory,sub_category)肯定存在。因?yàn)槿绻阋坏┯蒙狭似奉愃饕雌奉惡妥宇惾ピ谒饕锖Y選：

理論上執(zhí)行速度很快，即使表有億級(jí)數(shù)據(jù)，但也不應(yīng)超過1s。但跑了幾十秒，說明肯定沒用那個(gè)索引，看執(zhí)行計(jì)劃：

possible_keys=index_category的，key=PRIMARY，Extra=Using where

就是在掃描主鍵索引，還用where條件里的兩個(gè)字段做篩選，所以這么掃描就會(huì)耗費(fèi)幾十s。

為快速解決問題，使用force index語(yǔ)法，強(qiáng)制改變MySQL自動(dòng)選擇不恰當(dāng)聚簇索引進(jìn)行掃描的行為：

再次執(zhí)行SQL，僅耗費(fèi)100多ms。

所以若MySQL使用了錯(cuò)誤的執(zhí)行計(jì)劃，那就force index語(yǔ)法改變它。

但案例還有問題：

該表是個(gè)億級(jí)數(shù)據(jù)量大表，那index_category二級(jí)索引也比較大，所以此時(shí)MySQL覺得如果從index_category二級(jí)索引查找符合where條件的一波數(shù)據(jù)，接著還得回表。因?yàn)橐猻elect *，所以必然涉及回表，但在回表前，必然要做完order by id desc limit xx,xx操作。

舉個(gè)例子，根據(jù)where category='xx' and sub_category='xx'，從index_category二級(jí)索引里查找出一波數(shù)據(jù)，假設(shè)幾萬條，

因?yàn)槎?jí)索引包含主鍵id，就得按order by id desc，對(duì)這幾萬條數(shù)據(jù)基于臨時(shí)磁盤文件進(jìn)行?lesort磁盤排序，排序后，再按limit xx,xx語(yǔ)法將指定位置的幾條數(shù)據(jù)拿出來，假設(shè)limit 0,10，那么就是把10條數(shù)據(jù)拿出來。拿出來10條數(shù)據(jù)之后，再回到聚簇索引根據(jù)id查，把這10條數(shù)據(jù)的完整字段都查出來，這就是MySQL認(rèn)為如果你使用index_category的話，可能會(huì)發(fā)生的一個(gè)情況。

所以他擔(dān)心，你根據(jù)

從index_category二級(jí)索引里查出來的數(shù)據(jù)太多了，還得在臨時(shí)磁盤里排序，可能性能很差，因此MySQL就把這種方式判定不太好。

因此他選擇直接掃描主鍵的聚簇索引，因?yàn)榫鄞厮饕磇d值有序，所以掃描時(shí)，直接按order by id desc倒序得順序掃描即可，然后因?yàn)樗滥闶?/p>

也就知道你僅僅只要拿到10條數(shù)據(jù)就行了。所以他在按序掃描聚簇索引時(shí)，就會(huì)對(duì)每條數(shù)據(jù)都采用Using where，跟

條件進(jìn)行比對(duì)，符合條件的就直接放入結(jié)果集里去，最多就是放10條數(shù)據(jù)進(jìn)去就可以返回了。

此時(shí)MySQL認(rèn)為，按順序掃描聚簇索引，拿到10條符合where條件的數(shù)據(jù)，應(yīng)該很快，很可能比使用index_category二級(jí)索引更快，因此此時(shí)他就采用了掃描聚簇索引的這種方式。

這SQL之前在線上系統(tǒng)運(yùn)行一直沒問題，即之前在線上系統(tǒng)而言，即使采用掃描聚簇索引，該SQL也確實(shí)運(yùn)行不慢，最起碼是不會(huì)超過1s。

為何突然大量報(bào)慢查詢，耗時(shí)幾十s？因?yàn)橹?/p>

條件通常有返回值，即根據(jù)條件里的取值，掃描聚簇索引，通常都是很快就能找到符合條件的值并返回，所以之前其實(shí)性能也沒啥問題。

但后來可能是商品系統(tǒng)里的運(yùn)營(yíng)人員，在商品管理的時(shí)候加了幾種商品分類和子類，但是這幾種分類和子類的組合其實(shí)沒有對(duì)應(yīng)的商品，導(dǎo)致很多用戶使用這種分類和子類去篩選商品

條件實(shí)際上是查不到任何數(shù)據(jù)的！所以掃描聚簇索引時(shí)，怎么都掃不到符合條件的結(jié)果，一下就把聚簇索引全部掃了一遍，等于上億數(shù)據(jù)全表掃描一遍，都沒找到符合where category='新分類' and sub_category='新子類'這個(gè)條件的數(shù)據(jù)。

正因如此，才導(dǎo)致這個(gè)SQL語(yǔ)句頻繁的出現(xiàn)幾十秒的慢查詢，進(jìn)而導(dǎo)致MySQL連接資源打滿，商品系統(tǒng)崩潰！

SQL調(diào)優(yōu)并不太難，核心是看懂SQL執(zhí)行計(jì)劃，理解慢的原因，然后想法解決，本案例就得通過force index語(yǔ)法來強(qiáng)制某個(gè)SQL用我們指定的索引。

我的Mysql 怎么用不了！

開始--運(yùn)行--cmd--cd到命令所在目錄--輸入mysql.exe

再登錄看看、這樣就可以看到錯(cuò)誤提示了。

要先確認(rèn)：mysql服務(wù)是否開啟，端口是否開放，root默認(rèn)密碼是否修改了一下。