㈠ MYsql問題
根據提示信息，您的SQL出現了一個錯誤，導致用戶無法登錄。具體錯誤信息為「指定為定義者的用戶（root'e' loc alhos t'）不存在」，這意味著在嘗試使用這個用戶名登錄時，SQL無法找到這個用戶。
這可能是由於以下幾種情況之一引起的：
用戶名拼寫錯誤：請檢查您使用的用戶名是否正確拼寫。
用戶不存在：請確保您嘗試登錄的用戶在SQL中已經被正確創建。
資料庫配置錯誤：可能存在配置錯誤，導致SQL無法識別正確的用戶名。
檢查用戶名是否正確：請檢查您使用的用戶名是否正確拼寫，並且確保用戶名在SQL中存在。
重新創建用戶：如果您確定用戶名已經正確拼寫並且在SQL中不存在，請嘗試重新創建一個新的用戶並授權其訪問許可權。
檢查資料庫配置：請確保您的SQL配置正確，並且用戶名在資料庫中存在。您還可以嘗試使用root用戶登錄並檢查資料庫中的用戶列表。
針對這個問題，您可以嘗試以下幾種解決方案：
如果這些方法都無法解決問題，建議您聯系專業的SQL技術支持人員或管理員進行咨詢和幫助。
㈡ 為什麼我mysql的表添加了1000條記錄之後就存不進去數據了,客戶端也沒報錯
因為navicat分頁，導致默認一頁只能顯示1000行，超出1000行就在下一頁顯示了，並不是存不進去數據，只是分頁顯示了，其實第一次已經添加成功了，點擊右下方下一頁就能看到添加的其他數據了。
為了防止之後出現類似問題，可以按如下圖所示將限制行的對勾去掉即可。
(2)mysql資料庫常見問題擴展閱讀
MySQL資料庫特性：
1． mySQL使用 C和 C++編寫，並使用了多種編譯器進行測試，保證了源代碼的可移植性。
2．支持 AIX、FreeBSD、HP-UX、Linux、Mac OS、NovellNetware、OpenBSD、OS/2 Wrap、Solaris、Windows等多種操作系統。
3．為多種編程語言提供了 API。這些編程語言包括 C、C++、Python、Java、Perl、PHP、Eiffel、Ruby,.NET和 Tcl 等。
4．支持多線程，充分利用 CPU 資源。
5．優化的 SQL查詢演算法，有效地提高查詢速度。
6．既能夠作為一個單獨的應用程序應用在客戶端伺服器網路環境中，也能夠作為一個庫而嵌入到其他的軟體中。
7．提供多語言支持，常見的編碼如中文的 GB 2312、BIG5，日文的 Shift_JIS等都可以用作數據表名和數據列名。
8．提供 TCP/IP、ODBC 和 JDBC等多種資料庫連接途徑。
9．提供用於管理、檢查、優化資料庫操作的管理工具。
10．支持大型的資料庫。可以處理擁有上千萬條記錄的大型資料庫。
㈢ mysql連接資料庫失敗，請確定資料庫用戶名，密碼設置正確
現象
一線的工程師反映了一個奇怪的現象，剛剛從 MySQL 官網上下載了一個 MySQL 5.7.31。安裝完成後，發現使用任何密碼都能登陸 MySQL，修改密碼也不管用，重新啟動 MySQL 也不能解決。
分析
懷疑使用了 --skip-grant-tables 使用 mysqld --print-defaults 檢查，沒有發現。
檢查登陸用戶，都是 root@localhost，說明和 proxy user 沒有關系。
使用 mysql --print-defaults 檢查客戶端是否設置默認的用戶和密碼，沒有發現。
檢查資料庫中的用戶和密碼的相關欄位：
發現一切都正常，再檢查 plugin 欄位，發現只有 root 用戶是 auth_socket ，其它的用戶都是 mysql_native_password，問題可能就出在這兒。
對 auth_socket 驗證插件不了解，感覺是這個插件不安全，使用下面的命令修改後，問題解決：
update user set plugin="mysql_native_password" where user='root';
auth_socket 驗證插件的使用場景
問題解決後，又仔細研究了一下 auth_socket 這個插件，發現這種驗證方式有以下特點：
首先，這種驗證方式不要求輸入密碼，即使輸入了密碼也不驗證。這個特點讓很多人覺得很不安全，實際仔細研究一下這種方式，發現還是相當安全的，因為它有另外兩個限制；
只能用 UNIX 的 socket 方式登陸，這就保證了只能本地登陸，用戶在使用這種登陸方式時已經通過了操作系統的安全驗證；
操作系統的用戶和 MySQL 資料庫的用戶名必須一致，例如你要登陸MySQL 的 root 用戶，必須用操作系統的 root用戶登陸。
auth_socket 這個插件因為有這些特點，它很適合我們在系統投產前進行安裝調試的時候使用，而且也有相當的安全性，因為系統投產前通常經常同時使用操作系統的 root 用戶和 MySQL 的 root 用戶。當我們在系統投產後，操作系統的 root 用戶和 MySQL 的 root 用戶就不能隨便使用了，這時可以換成其它的驗證方式，可以使用下面的命令進行切換：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'test';
㈣ MySQL資料庫表被鎖、解鎖，刪除事務
在程序員的職業生涯中，總會遇到資料庫表被鎖的情況，前些天就又撞見一次。由於業務突發需求，各個部門都在批量操作、導出數據，而資料庫又未做讀寫分離，結果就是：資料庫的某張表被鎖了！
用戶反饋系統部分功能無法使用，緊急排查，定位是資料庫表被鎖，然後進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點贊收藏，以備不時之需。
用戶反饋某功能頁面報502錯誤，於是第一時間看服務是否正常，資料庫是否正常。在控制台看到資料庫CPU飆升，堆積大量未提交事務，部分事務已經阻塞了很長時間，基本定位是資料庫層出現問題了。
查看阻塞事務列表，發現其中有鎖表現象，本想利用控制台直接結束掉阻塞的事務，但控制台賬號許可權有限，於是通過客戶端登錄對應賬號將鎖表事務kill掉，才避免了情況惡化。
下面就聊聊，如果當突然面對類似的情況，我們該如何緊急響應？
想像一個場景，當然也是軟體工程師職業生涯中會遇到的一種場景：原本運行正常的程序，某一天突然資料庫的表被鎖了，業務無法正常運轉，那麼我們該如何快速定位是哪個事務鎖了表，如何結束對應的事物？
首先最簡單粗暴的方式就是：重啟MySQL。對的，網管解決問題的神器——「重啟」。至於後果如何，你能不能跑了，要你自己三思而後行了！
重啟是可以解決表被鎖的問題的，但針對線上業務很顯然不太具有可行性。
下面來看看不用跑路的解決方案：
遇到資料庫阻塞問題，首先要查詢一下表是否在使用。
如果查詢結果為空，那麼說明表沒在使用，說明不是鎖表的問題。
如果查詢結果不為空，比如出現如下結果：
則說明表（test）正在被使用，此時需要進一步排查。
查看資料庫當前的進程，看看是否有慢SQL或被阻塞的線程。
執行命令：
該命令只顯示當前用戶正在運行的線程，當然，如果是root用戶是能看到所有的。
在上述實踐中，阿里雲控制台之所以能夠查看到所有的線程，猜測應該使用的就是root用戶，而筆者去kill的時候，無法kill掉，是因為登錄的用戶非root的資料庫賬號，無法操作另外一個用戶的線程。
如果情況緊急，此步驟可以跳過，主要用來查看核對：
如果情況緊急，此步驟可以跳過，主要用來查看核對：
看事務表INNODB_TRX中是否有正在鎖定的事務線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個sleep的線程事務一直沒有commit或者rollback，而是卡住了，需要手動kill掉。
搜索的結果中，如果在事務表發現了很多任務，最好都kill掉。
執行kill命令：
對應的線程都執行完kill命令之後，後續事務便可正常處理。
針對緊急情況，通常也會直接操作第一、第二、第六步。
這里再補充一些MySQL鎖相關的知識點：資料庫鎖設計的初衷是處理並發問題，作為多用戶共享的資源，當出現並發訪問的時候，資料庫需要合理地控制資源的訪問規則，而鎖就是用來實現這些訪問規則的重要數據結構。
根據加鎖的范圍，MySQL裡面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（metadata lock，MDL)。
表鎖是在Server層實現的，ALTER TABLE之類的語句會使用表鎖，忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現，而對於InnoDB來說，一般會採用行級鎖。畢竟鎖住整張表影響范圍太大了。
另外一個表級鎖是MDL（metadata lock），用於並發情況下維護數據的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時會被自動加上。
常見的一種鎖表場景就是有事務操作處於：Waiting for table metadata lock狀態。
MySQL在進行alter table等DDL操作時，有時會出現Waiting for table metadata lock的等待場景。
一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態，後續對該表的任何操作（包括讀）都無法進行，因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現了鎖等待隊列，就會造成災難性的後果。
通過show processlist可以看到表上有正在進行的操作（包括讀），此時alter table語句無法獲取到metadata 獨占鎖，會進行等待。
通過show processlist看不到表上有任何操作，但實際上存在有未提交的事務，可以在information_schema.innodb_trx中查看到。在事務沒有完成之前，表上的鎖不會釋放，alter table同樣獲取不到metadata的獨占鎖。
處理方法：通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然後kill掉，讓其回滾。
通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進行中的事務。很可能是因為在一個顯式的事務中，對表進行了一個失敗的操作（比如查詢了一個不存在的欄位），這時事務沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。
處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。
總之，alter table的語句是很危險的（核心是未提交事務或者長事務導致的），在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務、也沒有顯式事務中的報錯語句。
如果有alter table的維護任務，在無人監管的時候運行，最好通過lock_wait_timeout設置好超時時間，避免長時間的metedata鎖等待。
關於MySQL的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。