线上一个实例报错The total number of locks exceeds the lock table size异常，导致复制中断，而当时的SQL是一条insert into select xxx语句，结果集比较大，从提示信息看是当前事务的lock size超过了lock table size,那么当前事务需要多大的lock size，而系统的lock table size又是多大呢。
从show innodb status 可以看出当前事务的lock size大小：
---TRANSACTION 65CEAB, ACTIVE 5492 sec, process no 10782, OS thread id 140449790605056 inserting
mysql tables in use 2, locked 2
9339476 lock struct(s), heap size 831633848, 49142856 row lock(s), undo log entries 12491866
MySQL thread id 910089, query id 14148540 Sending data
INSERT IGNORE INTO
T_XXX_TMP(
FID,
FSOURCE_NAME,
FUNIQUE,
FTITLE,
FCONTENT,
FLINK,
FSOURCE_IMG_URL,
FIMG_URL,
FPUSH_PATH,
FPUTDATE,
FSTATUS,
FTYPE,
FAUTHOR,
FLMODIFY,
FPOSTTIME,
FKEYWORDS,
FPV,
FRECOMMEND,
FRESOURCE_TYPE,
FLABEL,
FCOMMENT_COUNT,
FSHARE_COUNT,
FCOLLECT_COUNT,
FBIG_IMG_URL,
FCATEGORY,
FCP_CHANNEL_ID,
FPIC_SHOW_TYPE,
FTHUMBNAILS,
heap size831633848 ,800M之多，而当前实例的buffer pool大小只有1191M。还要分配给各个block list。buffer pool不仅仅包含各个block list（free list,lru list,flush list...），还有adaptive hash index ,lock heap 等都是从buffer pool这种分配的。在事务执行insert update,delete操作时,会先执行下面函数检查buffer pool用于block list的空间是否足够（也就是检查AHI,heap locksize是否占用过多的buffer pool空间）
/******************************************************************//**
Returns TRUE if less than 25 % of the buffer pool in any instance is
available. This can be used in heuristics to prevent huge transactions
eating up the whole buffer pool for their locks.
@return TRUE if less than 25 % of buffer pool left */
UNIV_INTERN
ibool
buf_LRU_buf_pool_running_out(void) 检查各个buffer pool中可用的空间小于25%
/*==============================*/
{
ulint i;
ibool ret = FALSE;
for (i = 0; i < srv_buf_pool_instances && !ret; i++) {
buf_pool_t* buf_pool;
buf_pool = buf_pool_from_array(i);
buf_pool_mutex_enter(buf_pool);
if (!recv_recovery_on
&& UT_LIST_GET_LEN(buf_pool->free) free list 长度
+ UT_LIST_GET_LEN(buf_pool->LRU) lru list长度
< buf_pool->curr_size / 4) { 这里是判断free list + lru list的长度是否小于buffer pool size 的 25%
ret = TRUE;
}
buf_pool_mutex_exit(buf_pool);
}
return(ret);
}
更新，插入记录到索引中，或者插入记录到一个已删除的记录位置都会调用该函数检查buffer pool空间，如果不足25%,则返回DB_LOCK_TABLE_FULL ，在mysql层会检测到该返回值，然后返回给客户端对应的异常信息。也就是标题的异常。
同样select在一些情况下也会调用该函数，在查询需要加锁的情况下，会调用该函数获取buffer pool剩余空间：
Sets a lock on a record.
@return DB_SUCCESS, DB_SUCCESS_LOCKED_REC, or error code */
UNIV_INLINE
dberr_t
sel_set_rec_lock(
/*=============*/
btr_pcur_t* pcur, /*!< in: cursor */
const rec_t* rec, /*!< in: record */
dict_index_t* index, /*!< in: index */
const ulint* offsets,/*!< in: rec_get_offsets(rec, index) */
ulint mode, /*!< in: lock mode */
ulint type, /*!< in: LOCK_ORDINARY, LOCK_GAP, or
LOC_REC_NOT_GAP */
que_thr_t* thr, /*!< in: query thread */
mtr_t* mtr) /*!< in: mtr */
{
trx_t* trx;
dberr_t err = DB_SUCCESS;
const buf_block_t* block;
block = btr_pcur_get_block(pcur);
trx = thr_get_trx(thr);
if (UT_LIST_GET_LEN(trx->lock.trx_locks) > 10000) { 如果该事务上锁的数量比较多， 大于10000，则需要进行判断。
if (buf_LRU_buf_pool_running_out()) { 此时说明加锁操作已经消耗了很多buffer pool空间，剩余空间不足以支撑该事务继续执行下去。
return(DB_LOCK_TABLE_FULL);
}
}
。。。
}
在这个案例中，执行的语句insert into ,xxxx select xxxx 操作，为例保持数据的一致性，innodb会对select 语句中的记录进行x-lock操作，当select的记录比较多的时候，加锁所需的heap size越大。从show engine innodb status可以看出：
9339476 lock struct(s), heap size 831633848, 49142856 row lock(s), undo log entries 12491866。
49142856 把行锁，需要831633848 大小的内存空间，当然这还仅仅是语句执行过程中的状态，实际上比这个还要多。回到上面的问题，那么当前事务需要多大的lock size，而系统的lock table size又是多大呢？
这里至少需要800M，而系统的lock table size 可以认为是buffer pool的75%，对于可用的block list,需要大于buffer pool size的25%才能继续执行当前事务。如果解决该问题，很简单，调大innod buffer pool size即可，
这里从1191M调整到5191M，start slave sql_thread，一段时间之后，顺利通过了。
还有哪些场景会导致该问题? delete一个大表，insert xxx select xxxx 记录数较大，update 一个大表，select xxx for update，select xxx in share mode 这些大事务都有可能导致该问题，影响的记录数越多，lock heap size约大。
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT count(*) FROM `test`.`T_XXX_ARTICLE_TMP` WHERE (`FID` >= 168666823 AND `FID` < 172310087) for update ;
+----------+
| count(*) |
+----------+
| 3112193 |
+----------+
1 row in set (3 min 1.56 sec)
show engine innodb status:
---TRANSACTION 691281, ACTIVE 226 sec, process no 1249, OS thread id 140670129358592
746334 lock struct(s), heap size 66468280, 3858526 row lock(s)
MySQL thread id 5802, query id 367184 localhost root
可以看出300W记录，需要heap size66468280 bytes = 63M。线上故障影响的记录是5kw，需要800M heap size。其实也能看出，加锁所需的内存和记录数有直接关系。
那么我们可以将大事务拆小，来降低每次事务加锁需要的heap size大小。
这同时也说明，如果一个实例中有大表，那么buffer pool应当尽可能大一下，buffer pool太小，则一旦遇上大事务就会导致该问题出现。我们线上是单机跑了多个实例，每个实例的buffer pool设置有限，
而该实例的数据大小达到了700G，出问题的大表有117G，遇到大事务碰到该问题则是必然的。解决办法：
1.调大innodb buffer pool size
2.将大事务拆小
如果仅仅是查询大表，即使影响的记录数很多，也是不会加锁的，也就不存在上面的问题。