目录 MySQL slave 延迟 外键检查和自增加锁 一、现象 二、pscak 采样 三、自增锁获取逻辑 四、方案 MySQL slave 延迟 外键检查和自增加锁 一、现象 延迟大，大事物。 表结构 无IO SQL THREAD占用
目录MySQL slave 延迟 外键检查和自增加锁一、现象二、pscak 采样三、自增锁获取逻辑四、方案
MySQL slave 延迟 外键检查和自增加锁
一、现象
延迟大，大事物。
表结构
无IO
SQL THREAD占用CPU 100%
二、pscak 采样
采样30个点
外键检查 占70%
自增锁获取 占30%
三、自增锁获取逻辑
逻辑如下其实也是innodb_autoinc_lock_mode参数的作用
switch (lock_mode) {
case AUTOINC_NO_LOCKING://innodb_autoinc_lock_mode=2
/* Acquire only the AUTOINC mutex. */
dict_table_autoinc_lock(m_prebuilt->table);
break;
case AUTOINC_NEW_STYLE_LOCKING: // innodb_autoinc_lock_mode=1 注意这里没有break 巧妙的完成了逻辑
/* For simple (single/multi) row INSERTs, we fallback to the
old style only if another transaction has already acquired
the AUTOINC lock on behalf of a LOAD FILE or INSERT ... SELECT
etc. type of statement. */
if (thd_sql_command(m_user_thd) == SQLCOM_INSERT
|| thd_sql_command(m_user_thd) == SQLCOM_REPLACE) {
dict_table_t* ib_table = m_prebuilt->table;
/* Acquire the AUTOINC mutex. */
dict_table_autoinc_lock(ib_table);
/* We need to check that another transaction isn't
already holding the AUTOINC lock on the table. */
if (ib_table->n_waiting_or_granted_auto_inc_locks) {
/* Release the mutex to avoid deadlocks. */
dict_table_autoinc_unlock(ib_table);
} else {
break;
}
}
/* Fall through to old style locking. */
case AUTOINC_OLD_STYLE_LOCKING://innodb_autoinc_lock_mode=0 触发
DBUG_EXECUTE_IF("die_if_autoinc_old_lock_style_used",
ut_ad(0););
error = row_lock_table_autoinc_for_mysql(m_prebuilt); //这个函数上表上的自增锁
if (error == DB_SUCCESS) {
/* Acquire the AUTOINC mutex. */
dict_table_autoinc_lock(m_prebuilt->table);
}
break;
default:
ut_error;
}
binlog row格式，innodb_autoinc_lock_mode=1 按理说不会触发row_lock_table_autoinc_for_mysql加自增锁。不知道什么原因。当前知道：
如果主库语句模式，从库innodb_autoinc_lock_mode=1 ，insert select 肯定会触发。
如果从库 innodb_autoinc_lock_mode=0 肯定会触发。
但是都不满足。疑惑。
四、方案
删除外键
innodb_autoinc_lock_mode设置为2，从逻辑来看肯定不会做row_lock_table_autoinc_for_mysql了。
到此这篇关于MySQL slave 延迟一列 外键检查和自增加锁的文章就介绍到这了,更多相关MySQL slave 延迟 外键检查和自增加锁内容请搜索每日运维以前的文章或继续浏览下面的相关文章希望大家以后多多支持每日运维！
