I Failed the Turing Test

Machine Learning glossary 常見名詞解釋

2017-01-232026-02-18VintaAI

Anomaly Detection 異常偵測

把一些異常值從 dataset 中挑出來

Anscombe's Quartet 安斯庫姆四重奏

四張圖表表示四組基本的統計特性一致的數據，但是各自畫出來的圖表完全不同
主要是在說統計方法有其侷限和離群值對統計的影響之大
還有就是分析數據前應該要先畫圖表

ref:
https://www.wikiwand.com/zh-tw/%E5%AE%89%E6%96%AF%E5%BA%93%E5%A7%86%E5%9B%9B%E9%87%8D%E5%A5%8F

Association Rule 關聯規則

找出資料之間的隱含關係
例如知名的啤酒與尿布

Best Subset Selection

是一種 model selection 的方法

Cost Function / Loss Function 損失函數

大部分的 machine learning 模型都是在計算 cost function
想辦法求出讓 cost function 最小化或最大化的各項參數
常用的 cost function 有 Mean Squared Error (MSE), Root Mean Squared Error (RMSE) 等

ref:
https://ml.berkeley.edu/blog/2016/11/06/tutorial-1/

Cross-validation 交叉驗證

cross-validation 常常用來做 hyperparameter tuning
最主流的方式是 k-fold
假設 k 是 3
你先把整個 dataset 拆分成 training set 和 test set
通常你會有很多組想要測試的超參數
則每一組超參數都會經歷以下過程：

把 training set 分成三等份
先用 1 + 2 訓練模型，用 3 來評估
再用 1 + 3 訓練模型，用 2 來評估
再用 2 + 3 訓練模型，用 1 來評估
然後對三組評估結果取平均作為這組超參數的分數

等到測試過所有超參數的組合之後
用表現最好的那一組超參數對整個 training set 再訓練一次
得到最終的模型
這時候再用 test set 來做最終模型的評估

ref:
https://spark.apache.org/docs/latest/ml-tuning.html#cross-validation

不過如果你的 dataset 真的沒那麼大
也是可以對整個 dataset 對 cross-validation
就不要先拆分 training set 和 test set 了

ref:
https://stats.stackexchange.com/questions/148688/cross-validation-with-test-data-set

還有一種方式是 leave-one-out 或 leave-n-out
每次只用一個 sample 來驗證
其餘的都用來訓練模型
直到每個 sample 都被用來驗證過

Curse of Dimensionality 維度災難

當數據的維度（feature 數）超過某個程度之後
導致計算的時間過久、記憶體用量過大（因為是指數型增加）
也必然會造成數據稀疏
特徵越多也可能造成 overfitting

ref:
https://www.quora.com/What-is-the-curse-of-dimensionality
http://stats.stackexchange.com/questions/169156/explain-curse-of-dimensionality-to-a-child

Decision Boundary 決策邊界

A smoother boundary corresponds to a simpler model.

每個特徵表示為一個維度
decision boundary 就是能夠把整個特徵空間裡的 dataset 正確劃分的一條邊界
這個邊界可能是 linear 或 non-linear

Dimensionality Reduction 降維

算是 unsupervised learning 的一種（transformations of the dataset）
可以分成 feature selection 和 feature extraction
在不喪失太多資訊的前提下減少 features 的維度
換個說法是嘗試用更少的維度來表示這個 dataset
維度減少的好處是提升計算效率和更容易進行 visualization

ref:
https://www.wikiwand.com/en/Dimensionality_reduction

從一堆 features 中選擇最有用的 features
稱為 feature selection
常見的方法有 Greedy forward selection

把原本高維度的 features 轉換成較少維度的 features
稱為 feature extraction
轉換之後已經不是原本的那些 features 了
常見的方法有 Principal Component Analysis (PCA)、Non-negative Matrix Factorization (NMF)

ref:
https://www.wikiwand.com/en/Feature_engineering
https://www.wikiwand.com/en/Feature_selection

Ensemble Learning 組合式學習

就是指結合多種演算法的 machine learning
例如 Random Forest（decision trees + bagging）

常見的 ensemble methods 有：
bagging (aka bootstrap aggregating)
boosting

Error 誤差 / Bias 偏差 / Variance 方差

Error = Bias + Variance 是指整個模型的準確度

Bias 是指預測值和真實值之間的差距，表示模型的精準度（反映的是模型在樣本上的輸出與真實值之間的誤差）
偏差越大，越偏離真實數據
因為模型太簡單而帶來的預測不準確 >> high bias

Variance 是指預測值的變化範圍，表示模型的穩定性（反映的是模型每一次輸出結果與模型輸出期望之間的誤差）
方差越大，數據的分佈越分散
因為模型太複雜而帶來的更大的空間變化和不確定性 >> high variance

ref:
https://www.zhihu.com/question/20448464 有圖
https://www.zhihu.com/question/27068705

Feature Engineering 特徵工程

就是找出（或是創造出）能夠讓演算法運作得更好的 features 的過程
也可能是整合、轉換多個相關的 features 變成一個新的 feature
通常會避免使用過多的 features 餵給演算法

Forward Stepwise Selection

一次增加一個 feature 來訓練 model
每次都計算準確率
直到所有 features 都用到

Backwards Stepwise Selection 就是反過來

Generalization 泛化

If a model is able to make accurate predictions on unseen data, we say it is able to generalize from the training set to the test set.

就是指 model 預測 unseen data 的能力
例如一個 overfitting 的 model，它的泛化能力就不好

ref:
https://www.quora.com/What-is-generalization-in-machine-learning

Gradient Descent 梯度下降

是一種找出最小的 cost function 的演算法
也就是找出最好的 model parameters

Greedy Feature Selection

一次只用一個 feature 來訓練 model

In greedy feature selection we choose one feature, train a model and evaluate the performance of the model on a fixed evaluation metric. We keep adding and removing features one-by-one and record performance of the model at every step. We then select the features which have the best evaluation score.

Hyperparameter 超參數

就是在訓練 model 時輸入的參數，那些 model 沒辦法自己學到，必須人工指定的參數。通常會透過 grid search 和 cross-validation 的方式選出最合適的參數。

Kernel Methods

kernel function 會是一個距離函數

linear kernel 是最簡單的一種 kernel function
其實就是兩個 input 的 dot product

ref:
https://www.zhihu.com/question/30371867

Linear Separability 線性可分

當你有一堆 data points
你能夠畫出一條「直線」來區分這些點時
就可以說是 linearly separable
反而則是 linearly inseparable

Logistic Curve

就是一條長得像頭尾被拉長拉扁的 S 的曲線

ref:
https://www.stat.ubc.ca/~rollin/teach/643w04/lec/node46.html

Missing Value Imputation（缺失值填充）

針對那些沒有值的欄位，可能是用中位數、平均值或是最常見的值之類的資料填進去
也稱為 interpolation

Manifold Learning

是一種 non-linear dimensionality reduction 的方式
可以用在把高維度的 dataset 變成較低維度
主要用來做 visualization
常用的有 t-SNE

manifold learning 通常用在 exploratory data analysis
不像 PCA 那樣，會把結果用於 supervised learning 的輸入

ref:
http://scikit-learn.org/stable/modules/manifold.html
https://www.wikiwand.com/en/Nonlinear_dimensionality_reduction

Normalization 歸一化、Standarization 標準化

屬於 preprocessing 的一部分
統一各個特徵的數值範圍
對很多演算法來說這個步驟是必要的

例如：
特徵一是距離，單位是公尺，值的範圍是 10 ~ 3000
特徵二是樓層，值的範圍是 1 ~ 14
為了避免尺度不同造成誤導
需要 rescaling
把各種尺度的數值統一表示成 0 ~ 1 之間的數字
稱為 normalization 歸一化

還有另一種統計學常用的方法，是把數值轉換成 z-scores
使所有數據的平均值為 0、標準差為 1
稱為 standarization 標準化

ref:
https://www.quora.com/What-is-the-difference-between-normalization-standardization-and-regularization-for-data
http://sobuhu.com/ml/2012/12/29/normalization-regularization.html

Predictors

就是 features

Principal component analysis (PCA) 主成份分析

主成分分析，是一种分析、简化数据集的技术。用于减少数据集的维数，同时保持数据集中的对方差贡献最大的特征。

用來 reduce dimensionality（減少 dataset 的維度數）
可以找出對 Variance 貢獻最大的特徵

Overfitting 過度擬合（過擬合）/ Underfitting 擬合不足（欠擬合）

overfitting 常常發生在 model 很複雜、有很多參數的時候
或是 dataset 裡有很多 noise 或 outlier
表現為在 training set 的準確率很高，但是在 testing set 的準確率卻很低
複雜模型 >> high variance / low bias >> overfitting

underfitting 通常發生在 model 太簡單的時候
表現為就算是在 training set 上的錯誤率就很高
簡單模型 >> high bias / low variance >> underfitting

ref:
http://www.csuldw.com/2016/02/26/2016-02-26-choosing-a-machine-learning-classifier/

Regularization 正規化、正則化

Regularization means explicitly restricting a model to avoid overfitting.

是一種防止 overfitting 的技巧
regularization 保留所有 features
但是降低或懲罰某些 features 對 model 預測值的影響
常見的方法有 L1 和 L2

L1 正則化是指權重向量 w 中各個元素的絕對值之和

L2
正則化是指權重向量 w 中各個元素的平方和然後再求平方根

ref:
https://zhuanlan.zhihu.com/p/25707761
http://blog.csdn.net/jinping_shi/article/details/52433975
http://blog.csdn.net/zouxy09/article/details/24971995

Resampling

在 classification 問題中
每一種 class 的數量差距很大
例如正樣本佔了 98%、負樣本佔了 2%
這就是所謂的不平衡的 dataset
解決的辦法之一是 resampling
主要可以分成 oversampling 和 undersampling（過採樣和欠採樣）

undersampling 是指減少多數類樣本的數量
例如隨機拿掉部分多數類樣本
直到正負樣本的數量相同
缺點是你可能也拿掉了 dataset 裡潛在的資訊

oversampling 指的是增加少數類樣本的數量
例如複製少數類樣本
讓正負樣本的數量盡可能相同
缺點顯而易見就是容易 overfitting
其他 oversampling 的方法還有 SMOTE (Synthetic Minority Over-sampling Technique)
合成新的少數類樣本
合成的策略是對每個少數類樣本 a
從它的最近鄰中隨機選一個樣本 b
然後在 a、b 之間的連線上隨機選一點作為新合成的少數類樣本

ref:
http://www.jiqizhixin.com/article/2499
http://www.algorithmdog.com/unbalance
https://en.wikipedia.org/wiki/Oversampling_and_undersampling_in_data_analysis

Training set / Test set

把 dataset 分成 training set 和 test set
用 training set 來訓練模型
用 test set 來評估結果
這兩組數據必須是從原始的 dataset 裡「均勻取樣」（隨機）
常見的比例是 70/30
這種方式稱為 holdout

也可以分成 training set、validation set、test set
training set 用來訓練模型，validation set 用來選擇模型（調整超參數），testing set 用在最終模型的評估
常見的比例是 50/25/25

基本上你的 test set 只能用來評估最終模型
不能用 test set 去訓練模型或是交叉驗證
對你的 model 來說 test set 就是一組 unseen 的資料
所以 test set 的評估結果才可以視為 model 上線後對真實資料的預測能力
如果你的 model 在 validation set 表現不錯
但是在 test set 的表現很差
那就是 overfitting 了

ref:
https://stats.stackexchange.com/questions/19048/what-is-the-difference-between-test-set-and-validation-set
https://www.jiqizhixin.com/articles/a62fc871-6366-402b-b32f-f9a3f17a566b
https://mp.weixin.qq.com/s/W7wpxHoC2F5DHCUO7ES1cw

Convert utf8 tables to utf8mb4 in MySQL

2017-01-232026-02-18VintaDatabase

Change Schema

# For each database:
ALTER DATABASE
    database_name
    CHARACTER SET = utf8mb4
    COLLATE = utf8mb4_unicode_ci;

# For each table:
ALTER TABLE
    table_name
    CONVERT TO CHARACTER SET utf8mb4
    COLLATE utf8mb4_unicode_ci;

# For each column:
ALTER TABLE
    table_name
    CHANGE column_name column_name
    VARCHAR(191)
    CHARACTER SET utf8mb4
    COLLATE utf8mb4_unicode_ci;

ALTER TABLE
    svcomments_svcomment
    CHANGE comment comment 
    longtext
    CHARACTER SET utf8mb4
    COLLATE utf8_general_ci;

SHOW VARIABLES WHERE Variable_name LIKE 'character%' OR Variable_name LIKE 'collation%';

# Don’t blindly copy-paste this!
# The exact statement depends on the column type, maximum length, and other properties.
# The above line is just an example for a VARCHAR column.

ref:
https://coderwall.com/p/pns4pa/setting-up-unicode-defaults-for-mariadb-or-mysql
https://mathiasbynens.be/notes/mysql-utf8mb4
http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci
http://dba.stackexchange.com/questions/8239/how-to-easily-convert-utf8-tables-to-utf8mb4-in-mysql-5-5

Application Settings

Take a Django project as an example.

in settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        ...
        'OPTIONS': {
            'charset': 'utf8mb4',
        },
        'TEST': {
            'CHARSET': 'utf8mb4',
            'COLLATION': 'utf8mb4_general_ci',
        },
    },
}

ref:
https://tzangms.com/use-emoji-in-mysql-with-django/

Create a custom migration in Django

2017-01-232026-02-18VintaDatabase, Python

# create an empty migration file
$ ./manage.py makemigrations --empty --name convert_to_utf8mb4 your_app

in your_app/migrations/0002_convert_to_utf8mb4.py

from __future__ import unicode_literals

from django.db import migrations

class Migration(migrations.Migration):

    dependencies = [
        ('your_app', '0001_initial'),
    ]

    operations = [
        migrations.RunSQL(
            'ALTER TABLE app_repostarring CHANGE repo_description repo_description VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;'
        ),
    ]

ref:
https://docs.djangoproject.com/en/dev/ref/migration-operations/#runsql

Locking and MVCC in MySQL InnoDB 鎖機制與多版本並發控制

2017-01-102026-02-18VintaDatabase

最近在研究 MySQL 5.6 / 5.7 InnoDB storage engine 的 Transaction、Locking 和 Multi-Version Concurrency Control (MVCC) 機制，基本上只討論 Isolation level 是 REPEATABLE READ 或 READ COMMITTED 的情況，這一篇是過程中記錄下來的筆記。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html

Transaction

Transaction Isolation Levels
https://vinta.ws/code/transaction-isolation-levels-in-databases.html

在 autocommit 啟用的情況下（默認），每一個 SQL 語句就是一個 transaction，但是你可以用 START TRANSACTION 或 BEGIN 來手動開啟一個 transaction，然後用 COMMIT 或 ROLLBACK 來結束。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-autocommit-commit-rollback.html

Pessimistic Locking 悲觀鎖 / Optimistic Locking 樂觀鎖

更準確一點的說法是 pessimistic concurrency control 和 optimistic concurrency control。

基本上悲觀鎖、樂觀鎖是一種方法論（或者說是策略），在不同的系統可能有不同的作法，不過這裡就只討論 MySQL。

悲觀鎖假設你在存取某個資料時，其他人同時修改同一份資料的機率很高，也就是對「資料會被修改」這件事持悲觀的態度，所以要在存取（無論讀寫）時就把該資料鎖住，不讓其他人有機會修改。悲觀鎖通常指的是資料庫本身提供的 locking 機制（在 application 層的鎖沒辦法保證不會被修改）。SELECT ... FOR UPDATE; 就是一種悲觀鎖。

樂觀鎖則是對「資料會被修改」這件事持樂觀的態度，通常會使用 version 版本號的方式來實作，在 InnoDB 裡就是指 Multi-Version Concurrency Control (MVCC)。

You can remember which is which by picturing it this way:

The pessimistic approach is a user thinking "I’m sure someone will try to update this row at the same time as I will, so I better ask the database server to not let anyone touch it until I’m done with it."
The optimistic approach is a user thinking "I’m sure it’s all good and there will be no conflicts, so I’m just going to remember this row to double-check later, but I’ll let the database server do whatever it wants with the row."

ref:
http://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking
https://blogs.msdn.microsoft.com/marcelolr/2010/07/16/optimistic-and-pessimistic-concurrency-a-simple-explanation/

Multi-Version Concurrency Control (MVCC)

在 InnoDB 裡是基本上是讀不加鎖，寫才加鎖，而且讀寫不互斥。

InnoDB 會把每個 row 的歷史版本儲存在 rollback segment 裡，rollback segment 的資料除了用在 transaction rollback 的 undo 操作外，會用被用在 consistent read，也就是 snapshot data。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html

在所有 InnoDB 的 tables 裡，每個 row 都會有三個隱藏的欄位 DB_ROW_ID、DB_TRX_ID 和 DB_ROLL_PTR：DB_TRX_ID 是建立這個版本的數據的那個 transaction id、DB_ROLL_PTR 就是 rollback data pointer 指向在 undo logs 裡的前一個版本的數據。

TODO:
多說一點細節
例如 SELECT、INSERT、UPDATE 和 DELETE 時的行為

Consistent (Nonlocking) Reads

所謂的 consistent read 是指 read 操作實際上是去讀 snapshot data（該 row 在不同時間點的數據、版本），所以 read 操作不會因為該 row 正在被其他 transaction 修改而被 block 住，snapshot data 就是當前數據的歷史版本。

如果 isolation level 是 REPEATABLE READ 或 READ COMMITTED 的話，SELECT 操作默認就是 consistent read，所以不會加上任何 lock。除非你顯式地加上 SELECT ... LOCK IN SHARE MODE 或 SELECT ... FOR UPDATE（稱為 locking reads）。

ref:
https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_consistent_read
https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_snapshot
https://blogs.oracle.com/mysqlinnodb/entry/repeatable_read_isolation_level_in

至於 INSERT、UPDATE 和 DELETE 操作，MySQL 則會自動對牽涉到的數據加上 lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-set.html

不同的 isolation level 在讀 snapshot data 的行為上是不同的。

REPEATABLE READ 在同一個 transaction 內，對同一個 row 的所有 consistent read 讀到的內容都會是第一個 consistent read 時建立的那個 snapshot data，即使其他 transaction 已經 commit 了新的資料，所以才叫 repeatable read。不過如果是在同一個 transaction 內所做的修改則還是會去讀那個修改過的內容，因為是去讀 snapshot。而且 MySQL 的 REPEATABLE READ 還額外地避免了 phantom read。

READ COMMITTED 在同一個 transaction 內，每次去讀同一個 row 都會建立並且讀最新的一份 snapshot data（當然只會讀已經 commit 的資料），先後的 read 可能會讀到不同的內容，所以才會有 non-repeatable read 的問題。

SERIALIZABLE 是讀加讀鎖，寫加寫鎖，而且讀寫互斥。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read
https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_read-committed
https://blog.gslin.org/archives/2015/09/27/6007/%E7%B9%BC%E7%BA%8C%E5%AD%B8-isolation/

雖然 MySQL 默認的 isolation level 是 REPEATABLE READ，但是如果你的專案其實不太需要 repeatable reads 的話，用 READ COMMITTED 可能更合適，至少 lock 會比較少。不過 REPEATABLE READ 和 READ COMMITTED 在效能上的差異似乎也沒有想像中那麼大就是了。

ref:
https://www.percona.com/blog/2015/01/14/mysql-performance-implications-of-innodb-isolation-modes/
https://smalldatum.blogspot.tw/2016/11/sysbench-innodb-transaction-isolation.html

Snapshot Read / Current Read

也有一種說法是把「讀」分成 snapshot read 和 current read，不過這種說法似乎只有在中國程序員寫的文章裡流傳，至少我沒有在官方的文件裡找到這兩個名詞。

snapshot read，就是去讀 snapshot data：

SELECT

current read，就是去讀最新版本的數據：

SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
INSERT
UPDATE
DELETE

ref:
http://hedengcheng.com/?p=771
http://tech.meituan.com/innodb-lock.html

Lock Modes

Shared Locks 共享鎖 / Exclusive Locks 排他鎖

shared lock (S lock)，也稱為「共享鎖」、「讀鎖」。被加上讀鎖的數據，其他 transaction 可以讀，也可以再加上讀鎖，但是不能寫（因為不能加上寫鎖）。

可以用 SELECT ... LOCK IN SHARE MODE; 顯式地加上 shared lock。MySQL 會對被 SELECT 到的每個 row 加上 shared lock，當然前提是這些 row 沒有被加上 exclusive lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_shared_lock

exclusive lock (X lock)，也稱為「排他鎖」、「寫鎖」。被加上寫鎖的數據，其他 transaction 可以讀（因為讀是讀 snapshot data），但是不能再加上任何鎖，所以不能寫（因為不能加上寫鎖），只有加上寫鎖的那個 transaction 才能寫。

可以用 SELECT ... FOR UPDATE; 顯式地加上 exclusive lock，MySQL 會對被 SELECT 到的每個 row 加上 exclusive lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_exclusive_lock

Intention Locks 意向鎖

分成 intention shared locks (IS) 和 intention exclusive locks (IX)，用來表示某個 transaction 打算對某個 table 裡的某個 row 加上 shared lock 或 exclusive lock。更明確地說，某個 transaction 必須先取得 table 的 intention lock，它才能對該 table 裡的 row 加上 shared lock 或 exclusive lock。

intention locks 是 MySQL 自動加的，你不需要也沒辦法自己加上這種鎖。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

另外還有一種 table-level locks，可以透過 LOCK TABLE 顯式地加上：

LOCK TABLES t1 READ;
LOCK TABLES t1 WRITE;

ref:
https://dev.mysql.com/doc/refman/5.7/en/lock-tables.html

Online DDL (Data Definition Language)

ALTER TABLE 操作可能也會有 table-level locks，在 ALTER TABLE 的過程中只能讀，寫則會被 block 直到 ALTER TABLE 完成。不過這點在 MySQL 5.6 / 5.7 以後改善了不少，例如可以用 ALTER TABLE ... ALGORITHM=INPLACE LOCK=NONE; 來指定不同的行為。

ref:
https://dev.mysql.com/doc/refman/5.7/en/alter-table.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html

Summary of Online Status for DDL Operations
https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html

Lock Types

Locks Set by Different SQL Statements in InnoDB
https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-set.html

Record Locks

record lock 就是加在 index 上的 lock，InnoDB 裡的 row-level lock 實際上是 index 的 record lock。使用 READ COMMITTED 的時候，locking read（即 LOCK IN SHARE MODE 和 FOR UPDATE）、UPDATE 和 DELETE 的 lock 都是 record lock。

TODO:
如果該 table 沒有任何 index

READ COMMITTED 只有 record lock，沒有 gap lock 和 next-key lock，不過 foreign-key constraint 和 duplicate-key 檢查還是會用到 gap lock。

REPEATABLE READ 有 record lock、gap lock 和 next-key lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks
https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_read-committed

Gap Locks

gap lock 是加在 index records 之間的 gap 上的 lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-gap-locks

Next-Key Locks

next-key lock 是 record lock + gap lock，next-key lock 可以用來避免 phantom read。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-next-key-locks
https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html

Insert Intention Locks

insert intention lock 是 gap lock 的一種，INSERT 之前會先加一個 insert intention lock，但是只要不是要 INSERT 到同一個位置上就不會 block 其他 transaction。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-insert-intention-locks

AUTO-INC Locks

auto-inc lock 是一種 table-level lock，不同種類的 insert-like 語句會有不同的行為。可以透過 innodb_autoinc_lock_mode 設定來改變這些行為。

在 innodb_autoinc_lock_mode = 1（預設值）的情況下，simple inserts（就是那種在執行之前就知道最後會產生幾筆新資料的 inserts）不會有 table-level 的 AUTO-INC lock，只有在取得 auto-increment 值的那瞬間會有 lock。

ref:
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-auto-inc-locks
https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_autoinc_lock_mode

Redirect Console Output: stdout and stderr

2017-01-022026-03-17VintaDevOps

File descriptors:

0: stdin
1: stdout
2: stderr

# redirect stdout to a file test.log
$ strace uptime > test.log
$ strace uptime 1> test.log

# redirect stderr to a file test.log
$ strace uptime 2> test.log

# redirect stderr to stdout
# &1 references the value of the file descriptor 1 (stdout)
$ sh /home/vinta/do_shit.sh > /tmp/do_shit.log 2>&1

# 2> 1 actually means that you redirect stderr to a file named 1
$ sh /home/vinta/do_shit.sh > /tmp/do_shit.log 2> 1
$ cat 1

# redirect both stderr and stdout to file test.log
$ strace uptime &> test.log

# run a command in background
$ long-running-command &

ref:
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html
https://www.cyberciti.biz/faq/redirecting-stderr-to-stdout/
https://www.brianstorti.com/understanding-shell-script-idiom-redirect/