mysql日誌，事務學習（一）

MySQL查詢字段區不區分大小寫？

答案是：不區分

如何解決須要區分英文大小寫的場景

例如登陸用戶爲admin，此時填寫ADMIN也能登陸，若是用戶名須要區分大小寫，你的作法是什麼？

解決方案一

MySQL默認的字符檢索策略：utf8_general_ci，表示不區分大小寫。

可使用utf8_general_cs，表示區分大小寫，也可使用utf8_bin，表示二進制比較，一樣也區分大小寫 。

注意：在Mysql5.6.10版本中，不支持utf8_genral_cs

建立表時，直接設置表的collate屬性爲utf8_general_cs或者utf8_bin；

若是已經建立表，則直接修改字段的Collation屬性爲utf8_general_cs或者utf8_bin。

-- 建立表：
CREATE TABLE testt(
id INT PRIMARY KEY,
name VARCHAR(32) NOT NULL
) ENGINE = INNODB COLLATE =utf8_bin;

-- 修改表結構的Collation屬性
ALTER TABLE TABLENAME MODIFY COLUMN COLUMNNAME VARCHAR(50) BINARY CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL;

==============================================

解決方案二

直接修改sql語句，在要查詢的字段前面加上binary關鍵字

-- 在每個條件前加上binary關鍵字
select * from user where binary username = 'admin' and binary password = 'admin';

-- 將參數以binary('')包圍
select * from user where username like binary('admin') and password like binary('admin');

MySQL innodb的事務與日誌的實現方式

有多少種日誌

• 錯誤日誌：記錄出錯信息，也記錄一些警告信息或者正確的信息。

• 查詢日誌：記錄全部對數據庫請求的信息，不論這些請求是否獲得了正確的執行。

• 慢查詢日誌：設置一個閾值，將運行時間超過該值的全部SQL語句都記錄到慢查詢的日誌文件中。

• 二進制日誌：記錄對數據庫執行更改的全部操做。

• 中繼日誌：中繼日誌也是二進制日誌，用來給slave 庫恢復

• 事務日誌：重作日誌redo和回滾日誌undo

事物的4種隔離級別

• 讀未提交(RU)

• 讀已提交(RC)

• 可重複讀(RR)

• 串行

事務是如何經過日誌來實現的，說得越深刻越好

事務日誌是經過redo和innodb的存儲引擎日誌緩衝（Innodb log buffer）來實現的，當開始一個事務的時候，會記錄該事務的lsn(log sequence number)號;

當事務執行時，會往InnoDB存儲引擎的日誌的日誌緩存裏面插入事務日誌；

當事務提交時，必須將存儲引擎的日誌緩衝寫入磁盤（經過innodb_flush_log_at_trx_commit來控制），也就是寫數據前，須要先寫日誌。這種方式稱爲「預寫日誌方式」

MySQL binlog的幾種日誌錄入格式以及區別

Statement：每一條會修改數據的sql都會記錄在binlog中。

優勢：不須要記錄每一行的變化，減小了binlog日誌量，節約了IO，提升性能。

相比row能節約多少性能 與日誌量，這個取決於應用的SQL狀況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，可是考慮到若是帶條件的update操做，以及整表刪除，alter表等操做，ROW格式會產生大量日誌，所以在考慮是否使用ROW格式日誌時應該根據應用的實際狀況，其所 產生的日誌量會增長多少，以及帶來的IO性能問題。

缺點：因爲記錄的只是執行語句，爲了這些語句能在slave上正確運行，所以還必須記錄每條語句在執行的時候的一些相關信息，以保證全部語句能在slave獲得和在master端執行時候相同的結果。

另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有不少相關問題(如sleep()函數， last_insert_id()，以及user-defined functions(udf)會出現問題).

使用如下函數的語句也沒法被複制：

• LOAD_FILE()

• UUID()

• USER()

• FOUND_ROWS()

• SYSDATE() (除非啓動時啓用了 --sysdate-is-now 選項)

同時在INSERT …SELECT 會產生比 RBR 更多的行級鎖

Row:不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。

優勢：binlog中能夠不記錄執行的sql語句的上下文相關的信息，僅須要記錄那一條記錄被修改爲什麼了。

因此rowlevel的日誌內容會很是清楚的記錄下 每一行數據修改的細節。並且不會出現某些特定狀況下的存儲過程，或function，以及trigger的調用和觸發沒法被正確複製的問題

缺點：全部的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。

好比一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣形成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，因爲表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。

Mixedlevel: 以上兩種level的混合使用。

通常的語句修改使用statment格式保存binlog，如一些函數，statement沒法完成主從複製的操做，則採用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。

新版本的MySQL中對row level模式也被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句，仍是會記錄全部行的變動。