MySQL

information_schema資料庫是MySQL內建的，它提供了訪問資料庫中繼資料的方式。中繼資料是關於資料的資料，如資料庫名或表名，列的資料類型，或存取權限等。有些時候用於表述該資訊的其他術語包括“資料詞典”和“系統目錄”。在 MySQL中，把 information_schema 看作是一個資料庫，確切說是資訊資料庫。其中儲存著關於MySQL伺服器所維護的所有其他資料庫的資訊。如資料庫名，資料庫的表，表欄的資料類型與訪問權

1.可能是/var/run/mysqld/mysql.pid檔案沒有寫的許可權解決方案 ：給予許可權，執行 “chown -R mysql:mysql /database” “chmod -R 755 /var/run/mysqld”  然後重新啟動mysqld！2.可能進程裡已經存在mysql進程解決方案：用命令“ps -ef|grep mysqld”查看是否有mysqld進程，如果有使用“kill

現在全身心投入到MySQL中。項目要求：將開發環境中的資料庫的修改同步至線上環境。開發人員給出的解決辦法是：利用像Python

Percona 中的 xtrabackup 真是個好工具， 簡單的介紹的他的功能：1、建立熱備份（主要依靠innodb的 crash recovery 功能）2、增量備份3、直接對備份檔案壓縮打包4、負載小在測試最新版本2.0時，發現問題：importing  and   exporing  individual tables中這個工具對Oracle

MySQL的效能從查看日誌開始。硬體設定低常常導致這樣的問題，但事實上大多數情況並不在這裡。某些“慢"SQL阻塞了其他語句的執行，最佳化查詢是第一步需要做的。“工欲善其事必先利其器”，MySQL自身的一款mysqldumpslow 查詢日誌分析器，該工具不但陳舊，驗證規範不準確。今天要說的是Percona

MySQL基於行的複製可以最大化保證主從複製的一致性，對於RBR（基於行複製） 和SBR（基於語句複製），相信大家已經很熟知，下面記錄的是行複製在二進位日誌總記錄的情況。基於行的複製是與位置相關的，binlog裡面只記錄相關表發生改變的列的資料。其中引入了四個新的事件： Table_map, Write_rows，Delete_rows,Update_rows.一條語句執行後，在binlog裡面，Table_map事件中包含表ID，和列的類型（沒有列名,slave

在保證資料庫效能的前提下，怎麼保證資料的一致性呢？在MySQL 5.5版本中即支援非同步複製又支援半同步複製。1、當slave 串連master的時候，它會指出它是否支援半同步複製。2、當master啟用 semisynchronous

在MySQL主從複製過程中，常常需要對某些重要的表進行一致性檢查。由於主從資料在同步時存在一定的延遲，因此直接讀取伺服器資料的方式無法嚴格保證資訊的一致性。在資料在同步完全結束之前，一直處於不斷變化且並不完整的狀態下。鎖表的可能實現這個問題，但是效能又是需要考慮的。能對資料驗證是最好的。MySQL的CHECKSUM

MySQL準備語句(Prepared Statements), 使用增強二進位用戶端/伺服器協議在用戶端和伺服器之間高效的發送資料，可以通過支援這種行協議的編程庫來訪問準備語句。建立準備語句時，用戶端庫會像伺服器發送一個實際查詢的原型，然後伺服器對該原型進行解析和處理，將部分最佳化過的原型儲存起來，並且給用戶端返回一個狀態控制代碼(State Handle)

innodb_flush_log_at_trx_commit 決定了交易記錄何時write,flushinnodb_flush_method確定了日誌及資料檔案如何write、flush。“show   variables”顯示該變數為空白，那說明被設定了預設值（fdatasync）下面我們先從Linux

在mysql的複製中，相對於主主複製，主從架構的穩定性更好，而主主總是會有些問題存在，故不推薦。在大型架構中建議使用基於讀寫分離的主從複製本文不涉及讀寫分離的內容，只是簡單實現mysql的主從複製的實現。整個過程在理解複製的原理後就非常的簡單，所以先簡單介紹下原理。mysql的主從複製的基本原理：在主伺服器上傳送二進位日誌到從伺服器，在從伺服器上讀取收到的中繼日誌，執行日誌中的sql語句，實現資料同步。整個實現過程如下圖所示，通過圖片能很容易的看出整個流程對於主從之間使用非同步傳輸還是同步傳輸，

環境：Navicatfor Mysql 8.2 + MySQL Sever 5.1問題：通過MySQL命令列不能串連，輸入密碼後 無反應，過一段時間出現系統提示音，命令列視窗一閃而過，而且通過Navicat for Mysql 8.2也連不上，出 現如下錯誤：2003 - can's connect to MySQL server on 'localhost' 10060解決：關閉防火牆， 重新串連即可。如果出現10061錯誤，可以參考此文：Navicat for Mysql 出現2003 -

環境：NavicatforMysql 8.2 + MySQL Sever 5.1問題：NavicatforMysql中添加外鍵解 決：方法一：使用SQL語句建立外鍵：alter table 外鍵表 add constraint 約束名 foreign key(欄位名) references 參照表(外鍵欄位名) on delete restrict/set null/cascade on update restrict/set null/

這裡介紹的記錄檔都是MySQL資料庫本身的檔案，和具體用什麼儲存引擎無關。錯誤記錄檔MySQL的錯誤記錄檔類似於Oracle的alert.log，預設情況下以.err結尾，DBA在遇到問題時，首先應該查詢 該日誌獲得錯誤資訊。查詢日誌查詢日誌記錄了所有的資料庫請求，即時這些請求沒有得到正確 的執行。慢查詢日誌慢查詢日誌用於記錄已耗用時間比較長的SQL語句，可以通過參數

vmstat：顯示虛擬記憶體的統計資訊，還可以報告關於進程、記憶體、I/O等系統整體運行狀態。選項：-a：顯示記憶體活動-f：顯示啟動後建立的進程總數-s：以表格方式顯示時間計數器和記憶體狀態，不能重新整理顯示-d：顯示磁碟狀態-p：顯示指定的分區狀態-S：指定輸出資訊的單位-n：狀態資訊重新整理的時間間隔和次數執行個體：[root@master~]# vmstatprocs ----------memory------------- --swap--  ---io---  

環境介紹：使用yum安裝了一個mysql，因版本不符合需求，使用rpm卸載，又用rpm安裝了一個版本的Mysql。報錯提示：Mysql安裝完畢後，錯誤記錄檔中報錯：[ERROR] Native table 'performance_schema'.'xxxxx' hasthe wrong structure解決方案：在作業系統層級，執行mysql_upgrade報錯原因：當前performance_schema的資訊與mysql實際的情況不一致。參考：If you install MySQL

【MySQL案例】mysql-libs-5.1.73-3.el6_5.x86_64 conflicts with file from package Percona-Server-server如果遇到mysql-libs-5.1.73-3.el6_5.x86_64 conflicts with file from package Percona-Server-server報錯，有兩種情況導致這個問題：1）卸載作業系統預裝的mysql-libs包rpm -qa | grep -i libs |

1.1.1. ERROR 1665 (HY000)【環境描述】msyql5.6.14【報錯資訊】執行SQL語句的時候報錯：ERROR 1665 (HY000): Cannot executestatement: impossible to write to binary log since BINLOG_FORMAT = STATEMENTand at least one table uses a storage engine limited to row-based

1.1.1. ERROR 1786 (HY000)【環境描述】msyql5.6.14【報錯資訊】執行create table ... select的時候遇到報錯：db1 [test] [23:01:58]> create tablelgmnr_bak select * from lgmnr;ERROR 1786 (HY000): CREATE TABLE ... SELECTis forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY =

1.1.1. HA: GTID_MODE配置不一致【環境描述】msyql5.6.14【報錯資訊】初始狀態Master和Slave都開啟了enforce-gtid-consistency和gtid-mode，然後在Master上把它倆都修改成了off關閉狀態，這時，Slave發生報錯：Last_IO_Error: The slave IO thread stopsbecause the master has @@GLOBAL.GTID_MODE OFF and this server