服務端：mysqld 客戶端： mysql
常用管理命令：(注：所有要在服務端執行的命令都要以;結尾，以告訴服務器命令結束）
登陸： mysql –uuser –ppassword –hhost 分別指定用戶，密碼和mysql主機即可登陸，也可以在家目錄下創建個.my.cnf配置文件，把用戶名和密碼主機等配置在裏面：假定root的密碼是mypass
[root@node1 ~]# cat << 'EOF' > .my.cnf
> [client]
> user = root
> password = mypass
> host = localhost
> EOF當然如果在本機上登陸還是unix sock 的方式最快，消耗資源最小，因爲這是在內核底層實現的，如果用IP地址登陸則還需要先送到內核的TCP/IP協議棧處理。
給用戶加密碼：
在mysql命令行下執行 SET PASSWROD FOR ‘user’@’host’=PASSWORD(‘password’);
Shell下用mysqladm修改： mysqladm –uroot –hlocalhost password ‘mypass’ –predhat （把root@localhost的密碼由redhat改爲mypass)
直接修改mysql庫user表：UPDATE mysql.user SET PASSWORD=PASSWORD('redhat') WHERE User='root' AND Host='localhost';
創建和刪除用戶：
CREATE USER ‘root’@’172.16.100.100’ IDENTIFIED BY ‘mypass’;
DROP USER ‘root’@’172.16.100.100’;
忘記管理員密碼咋整：
停掉mysqld服務後，mysqld_safe –-skip-grant(跳過授權表） –-skip-networking（不允許遠程訪問mysql，以保證安全），此方式啓動後，無密碼登陸後修改密碼
用戶授權和取消授權：
GRANT SELECT,UPDATE ON db_name.tb_name TO ’user’@’host’ [IDENTIFIED BY PASSWORD ]; FLUSH PRIVILEGES;
REVOKE SELECT,UPDATE ON db_name.tb_name FROM USER;
查看已經授權用戶信息：SHOW GRANTS\G
查看mysql線程信息：SHOW PROCESSLIST;
查看錶索引信息：SHOW INDEXES FROM tb_name;
mysqld –help –verbose 可以查看mysql配置文件中可以使用的參數
各種秀：SHOW DATABASES; SHOW TABLES; DESC tb_name; SHOW ERRORS; SHOW STATUS; SHOW BINARY LOGS; SHOW BINLOG EVENTS;
查處某個庫中的表的詳細屬性信息：SHOW TABLE STATUS RLIKE ‘%user%’\G (用RLIKE可以匹配正則表達式、\G以縱向的方式顯示，當列比較多時候比較有效果，\g可以直接送到服務端，不用再加分號）
SHOW MASTER STATUS; 可查看當前二進制日誌的position
SHOW GLOBAL | SESSION VARIABLES LIKE | RLIKE ‘%log%’; 查看服務器變量信息
SET GLOBAL.var_name=VALUE;
SET @@GLOBAL.var_name=VALUE;
SELECT DATABASE(); SELECT LAST_INSERT_ID();
SHOW CREATE TABLE user; SHOW ENGINE INNODB STATUS;
HELP Contents; –> SHOW Administrations; ….
mysql> source /tmp/backup.sql | mysql –uroot –pmypass < /tmp/backup.sql
mysql -uroot -predhat -e 'SHOW DATABASES;'
Tips: 由於緩存是對查詢語句做哈希作爲鍵存儲的，而Hash是case-sensitive的，所以呢爲了提高緩存命中率，SQL語句要保持一定的風格，例如把所以命令關鍵字全部大寫。養成良好的編程習慣利人利已。
關於存儲引擎：mysql是插件式存儲引擎，可以按需隨時切換（存儲引擎可以理解爲數據庫的邏輯數據與磁盤上二進制數據的中間件，它完成兩種數據格式之間的相互轉換過程）
MyISAM: 是ISAM的改進版本，不支持熱備，支持溫備，支持B-tree indexes，不支持T-tree indexes 和Hash indexes，支持全文檢索（full-text search indexes：可以索引到一個字段上的所有數據上)等，和InnoDB最大的區別在於不支持事務（Transaction), 支持表級別的鎖，InnoDB支持行級別的鎖，支持延遲更新索引鍵（delay key update)
MyISAM數據文件存儲形式：db_name.MYI index文件， db_name.MYD data文件， db_name.frm framwork表定義文件，存放表結構信息等
適合數據倉庫、olap(online analytical processing)、寫入少，查詢多的場景，對大數據場景支持不好，數據庫很大（超過500G)時一旦崩潰，很難恢復，MariaDB 啓用aira引擎，是改良的myisam，提供了安全的崩潰恢復。
InnoDB: InnoDB公司開發的支持事務和外鍵的存儲引擎，也吸收了非死不可、谷哥等公司大牛的貢獻，後被假骨人收購後就走上了商業化的道路，不過這假骨頭的人也對innodb做了n多的改進和優化。
InnoDB支持的行級別的鎖並不是絕對的，當執行的語句所影響的行不確定時，是對全表進行鎖定的，例如 SELECT * FROM db_name.tb_name WHERE Name LIKE ‘%mysql%’;
innodb支持 外鍵、事務、MVCC(Multi-Version Concurrency Control) 多版本併發控制、聚簇索引（索引和表數據放在一起並按一定的順序排列，是有序數據，而myisam存儲的是堆數據，heap,不支持聚簇索引）、間隙鎖（Gap Lock:間隙鎖，鎖定一個範圍，但不包含記錄本身）、輔助索引、自適應hash索引、支持熱備、行級鎖
數據文件存放：ibdata1 表空間文件，建議開啓innodb_file_per_table = 1,每表一個表空間，tb_name.ibd,否則所有表放在一個文件中不便於管理，但是，單獨的表空間文件僅存儲該表的數據、索引和插入緩衝等信息，其餘信息還是存放在默認的表空間中。tb_name.frm 表定義文件
MEMORY 創建臨時表時用到，內存存儲引擎
BLACKHOLE 黑洞，在複製結構中，爲減少master壓力和二進制日誌複製次數，只複製一份到一個slave上，其他slave全部到此slave上覆制binlog, 而此slave並不存儲數據，只提供binlog源，應用relaylog時全部扔到BLACKHOLE去避免不必要的IO。
CSV 可以把數據導出爲csv文本格式，可以在不同數據庫之間交換數據
ARCHIVE 5.5後支持索引，適用於存儲日誌等按時間序列的數據採集，僅支持insert, select， 支持很好的壓縮功能
FEDRATED:
能夠訪問遠程服務器上的數據的存儲引擎，FedratedX
MRG_MYISAM merge MySQL已經支持表分區，這個用處就不大了
能夠合併多個MyISAM表的存儲引擎，
NDB：集羣存儲引擎，專用於MySQL Cluster
第三方存儲引擎，
OLTP類，在線事務處理
XtraDB, InnoDB的增強版
PBXT: 支持事務，社區不活躍，MariaDB 5.5.32後原生也不再支持
TokuDB 很牛逼，已經開源，MySQL插件，可以直接使用，支持分形樹索引結構，適用於需要插入大量數據的分析型場景
圖示數據庫，有着複雜連接的
列式數據庫，最適於存儲海量數據，
列式存儲引擎：
Infobright: 最著名，真正在生產環境中使用，數十TB, 支持壓縮，如果使用需要對mysql服務器定製
InfiniDB
MonetDB
LucidDB
社區存儲引擎
Aria
Groona: 全文索引引擎
QQGraph: 支持圖操作，Open query 研發
SphinxSE：獅身人面象，已經被Maria社區採用，MariaDB 5.5.32+
Spider：支持分片（sharding）
VPForMySQL：支持垂直分區，vertical partition, spider作者寫的
關於MySQL日誌：
二進制日誌：記錄會引起數據庫數據變化的語句：
SHOW BINARY | MASTER LOGS;
SHOW MASTER STATUS;
SHOW BINLOG EVENTS [IN ‘log_name’] [FROM position] [LIMIT n] 偏移n條語句
FLUSH LOGS; 一般只滾動binlog 和 relaylog, 每次mysql服務的重啓也會引起binlog滾動，日誌大小達到上限也會自動滾動，一般默認1G
清除binlog安全的方式：PURGE BINARY | MASTER LOGS TO ‘log_name’ | BEFORE ‘2012-10-10 12:09:09’;
log-bin = /path/to/some_log_file
expire_log_days = 100
sync_binlog 事務提交時，是否從cache刷寫到磁盤，建議開啓，對性能稍微有些影響，但是更可靠，worthful
mysqlbinlog –end-position=234 mysql_bin.000012 > /tmp/1.sql
mysql –uroot –pmypass < /tmp/1.sql
在用二進制恢復數據庫時，要把二進制日誌關掉，不然重複記錄操作，徒增二進制空間
innodb_flush_log_at_trx_commit = 0|1|2 日誌刷寫到磁盤頻率，0 --> 1秒一次，1 --> 每次事務提交就寫，2 --> 0+1
慢查詢日誌：建議開啓，記錄執行時間長的查詢過程以方便分析優化
slow_query_log 定義是否開啓慢查詢日誌
slow_query_log_file 定義慢查詢日誌文件存儲位置
long_query_time 定義查詢時長達到多少被認爲是慢查詢
慢查詢時長：從查詢啓動到查詢完成，中間無論什麼原因導致都計算在內，牆上掛鐘時間而非CPU時間
錯誤日誌
記錄服務器啓動和關閉過程中的信息
記錄服務器運行中的錯誤信息
事件調度器運行一個事件時產生的信息
在從服務器上啓動從服務器進程時產生的信息
查詢日誌：一般不建議開戶，消耗服務器資源，影響性能
事務日誌：把無序IO轉化爲有序IO,不宜過大，如果過大服務器從崩潰是恢復會消耗很大時長
中繼日誌：用於複製場景，slave從master複製過來的binlog先放到中繼日誌，然後再應用到本地
關於innodb,關於事務：(參考http://javabkb.iteye.com/blog/1441197內容）
事務自然要支持ACID
Atomicity 原子性：整個事務中的所有操作要麼全部完成，要麼全部不完成，如果執行過程中出現錯誤則回滾，數據和沒發生這個事務一樣
Consistency 一致性
Isolation 隔離性
Durability 持久性
重做日誌：實例和介質失敗，重做日誌文件就能派上用場，如數據庫掉電，InnoDB存儲引擎會使用重做日誌恢復到掉電前的時刻，以此來保證數據的完整性。參數innodb_log_file_size指定了重做日誌文件的大小；innodb_log_file_in_group指定了日誌文件組中重做日誌文件的數量，默認爲2，innodb_mirrored_log_groups指定了日誌鏡像文件組的數量，默認爲1，代表只有一個日誌文件組，沒有鏡像；innodb_log_group_home_dir指定了日誌文件組所在路徑，默認在數據庫路徑下。
二進制日誌和重做日誌的區別：首先，二進制日誌會記錄所有與Mysql有關的會引起數據變化的日誌記錄，包括InnoDB、MyISAM、Heap等其他存儲引擎的日誌。而InnoDB存儲引擎重做日誌只存儲有關其本身的事務日誌；其次內容不同，不管將二進制日誌文件記錄的格式設爲STATEMENT還是ROW，又或者是MIXED，其記錄的都是關於一個事務的具體操作內容。而InnoDB存儲引擎的重做日誌文件記錄的關於每個頁的更改的物理情況 。此外，寫入時間不同，二進制日誌文件是在事務提交前進行記錄的，而在事務進行的過程中，不斷有重做日誌條目被 寫入重做日誌文件中。
InnoDB 表結構
表空間：innodb存儲引擎邏輯結構的最高層
段：表空間由各個段組成，如數據段、索引段、回滾段等
區：64個連續的頁組成，每個頁16kb，即每個區1MB
頁：每頁16kb,且不能更改，數據頁、undo頁、系統頁、事務數據頁、插入緩衝位圖頁、插入緩衝空閒列表頁、未壓縮的二進制大對象頁、壓縮的二進制大對象頁
行：innodb存儲引擎是面向行的（row-oriented),每頁最多允許存放7992行數據
行記錄格式：常見兩種行記錄格式Compact和Redundant，mysql 5.1版本後，主要是Compact，此格式不管CHAR還是VARCHAR, null不佔存儲空間，對於Redudant, VARCHAR的null不佔空間，CHAR的null佔存儲空間。
鎖：
共享鎖(S Lock)：允許事務讀一行數據；
排他鎖(X Lock)：允許事務刪除或者更新一行數據。
當一個事務已經獲得了行r的共享鎖，那麼另外的事務可以立即獲得行r的共享鎖，因爲讀取沒有改變行r的數據，我們稱這種情況爲鎖兼容。但如果有事務想獲得行r的排他鎖，則它必須等待事務釋放行r上的共享鎖--這種情況稱爲鎖不兼容。在InnoDB Plugin之前，只能通過SHOW FULL PROCESSLIST，SHOW ENGINE INOODB STATUS等命令來查看當前的數據庫請求，然後再判斷當前事務中的鎖的情況。新版本的InnoDB Plugin中，在INFORMATION_SCHEMA架構下添加了INNODB_TRX、INNODB_LOCKS、InnoDB_LOCK_WAITS。通過這三張表，可以更簡單地監控當前的事務並分析可能存在的鎖的問題。
一致性的非鎖定讀：InnoDB存儲引擎通過行多版本控制的方式來讀取當前執行時間數據庫中行的數據。如果讀取的行正在執行Delete、update操作，這時讀取操作不會因此而會等待行上鎖的釋放，相反，InnoDB存儲引擎會去讀取行的一個快照數據。快照數據是指該行之前版本的數據，該實現是通過Undo段來實現。而Undo用來事務中回滾數據，因此快照本身是沒有額外開銷的。此外，快照數據是不需要上鎖的，因爲沒有必要對歷史的數據進行修改。一個行可能有不止一個快照數據，所以稱這種技術爲行多版本技術。由此帶來併發控制，稱之爲多版本併發控制(Multi VersionConcurrency Control, MVCC)。
鎖的算法：
Record Lock:單行記錄上的鎖
Gap Lock:間隙鎖，鎖定一個範圍，但不包含記錄本身
Next-Key Lock:Gap Lock + Record Lock，鎖定一個範圍，並且鎖定記錄本身。鎖的問題：
丟失更新：經典的數據庫問題，當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，會發生丟失更新問題。每個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所做的更新，這將導致數據丟失。
例:
事務A和事務B同時修改某行的值，
1.事務A將數值改爲1並提交
2.事務B將數值改爲2並提交。
這時數據的值爲2，事務A所做的更新將會丟失。
解決辦法：事務並行變串行操作，對更新操作加排他鎖髒讀：一個事務讀到另一個事務未提交的更新數據，即讀到髒數據。
例:
1.Mary的原工資爲1000, 財務人員將Mary的工資改爲了8000(但未提交事務)
2.Mary讀取自己的工資 ,發現自己的工資變爲了8000，歡天喜地！
3.而財務發現操作有誤，回滾了事務,Mary的工資又變爲了1000, 像這樣,Mary記取的工資數8000是一個髒數據。
解決辦法：髒讀只有在事務隔離級別是Read Uncommitted的情況下才會出現，innoDB默認隔離級別是Repeatable Read，所以生產環境下不會出現髒讀。不可重複讀：在同一個事務中,多次讀取同一數據,返回的結果有所不同。換句話說就是,後續讀取可以讀到另一個事務已提交的更新數據。相反"可重複讀"在同一事務多次讀取數據時,能夠保證所讀數據一樣,也就是後續讀取不能讀到另一事務已提交的更新數據。髒讀和不可重複讀的主要區別在於，髒讀是讀到未提交的數據，不可重複讀是讀到已提交的數據。
例:
1.在事務1中，Mary 讀取了自己的工資爲1000,操作並沒有完成
2.在事務2中，這時財務人員修改了Mary的工資爲2000,並提交了事務.
3.在事務1中，Mary 再次讀取自己的工資時，工資變爲了2000
解決辦法：讀到已提交的數據，一般數據庫是可接受的，因此事務隔離級別一般設爲Read Committed。Mysql InnoDB通過Next-Key Lock算法避免不可重複讀，默認隔離級別爲Repeatable Read。
事務的隔離級別：Read uncommitted、Read committed、Repeatable read、serializable。在Read Committed和Repeatable Read下，InnoDB存儲引擎使用非鎖定一致性讀。然而，對於快照的定義卻不同。在Read Committed事務隔離級別下，對於快照數據，非一致性讀總是讀取被鎖定行的最新一份快照數據。在Repeatable事務隔離級別下，對於快照數據，非一致性讀總是讀取事務開始時的行數據版本。