Do you really know how mybatis executes the select statement?, Detailed explanation of Linux kernel source code

really know mybatis executes select

select * from user_info where status=1

and user_id in


  • Unit tests are as follows :


void contextLoads() {

List userInfos = userMapper.selectList(Arrays.asList(“192”,“198”));



DEBUG Walk up

  • Where to make a breakpoint , As mentioned in the last article , I'm not going to repeat that .

  • because SpringBoot And Mybatis After integration , What is automatically injected is SqlSessionTemplate, So the code goes to org.mybatis.spring.SqlSessionTemplate#selectList(java.lang.String, java.lang.Object), Such as chart 1

  • You can see from the source code , What is actually called is DefaultSqlSession Medium selectList Method . as follows chart 2

  • 「 The specific logic is as follows 」

  1. according to Mapper Methodical Full class name from Mybatis Get this from the configuration of SQL Details of , such as paramterType,resultMap wait .

  2. Now that the L2 cache is enabled , Must first judge this SQL Cached , So what is actually called is CachingExecutor This cache executor .

  • DefaultSqlSession Just a simple acquisition SQL Detailed configuration of , Finally, the task was handed over to Executor( Of course, the second level cache is used here , So it's left to the cache executor ). below DEBUG Go to the CachingExecutor#query(MappedStatement, java.lang.Object, RowBounds,ResultHandler), Source code is as follows chart 3

  • In the picture above query The method actually does two things , The query actually executed is also the overloaded method List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql), as follows chart 4

  • According to the analysis of the source code in the figure above , Actually CachingExecutor The logic of execution is not very difficult , On the contrary, it's easy to understand ,「 The specific logic is as follows 」

  1. If the second level cache is turned on , First, according to cacheKey Query from L2 cache , If the query is found, it directly returns

  2. If L2 cache is not enabled , Re execution BaseExecutor Medium query Method to query from the L1 cache .

  3. If no data is queried in the L2 cache , Re execution BaseExecutor Medium query Method to query from the L1 cache .

  4. Store the query results into the L2 cache .

  • BaseExecutor Medium query The method is nothing more than fetching data from the L1 cache , No more data from the database , The L1 cache is actually a Map structure , I won't go into details here , True execution SQL What gets data from the database is SimpleExecutor Medium public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) Method , Source code is as follows chart 5

  • You can also know from the source code above , In real execution SQL Before , Is to call prepareStatement(handler, ms.getStatementLog()) Method to preprocess some parameters , It involves the other two of the six swordsmen , Namely ParameterHandler and TypeHandler, Source code such as chart 6

  • From the above figure, you can know the settings SQL The real method of parameters is handler.parameterize(stmt), Here's what it actually does DefaultParameterHandler Medium setParameters Method , Because of the long space , Simply say the idea :

  1. Get the mapping of all parameters

  2. Loop traversal , Get the value of the parameter , Use the corresponding TypeHandler Convert it to a parameter of the corresponding type .

  3. The real way to set parameters is TypeHandler in setParameter Method

  • continue chart 6 The logic of , The parameters have been set , It's time to execute SQL 了 , True execution SQL Yes. PreparedStatementHandler Medium ` List query(

《 A big factory Java Analysis of interview questions + Back end development learning notes + The latest architecture explanation video + Practical project source code handout 》

【】 Full content open source sharing

Statement statement, ResultHandler resultHandler) Method , Source code is as follows chart 7`:

  • The logic in the figure above is actually very simple , One is JDBC perform SQL sentence , One is to call one of the six swordsmen ResultSetHandler Process the results .

  • What really handles the results is DefaultResultSetHandler Medium handleResultSets Method , The source code is more complex , It's not going to show , The specific logic is as follows :

  1. Get the result map (resultMap), If not specified , Use the built-in result mapping

  2. Traversal result set , Yes SQL Each result returned is passed through the result set and TypeHandler Mapping results .

  3. Return results

  • ResultSetHandler After processing the result, it will return . So far, one selectList() I'm probably sure how to implement it , Other updates , Deletion is much the same .


  • Mybatis The source code of is relatively simple among several common frameworks , All around six components , Just understand what role each component is , What's the role , It's going to be easy .

  • One select The logic for the simple execution of the statement is summarized as follows ( Premise :「 The default configuration 」):

  1. 「SqlSesion」#SqlSessionTemplate.selectList() The actual call #DefaultSqlSession.selectList()

  2. 「Executor」#DefaultSqlSession.quer() What's actually called is #CachingExecutor().query(), If there is a direct return in the L2 cache , Call does not exist #BaseExecutor.quer() Query level 1 Cache , If there is a direct return in the L1 cache . Call does not exist #SimpleExecutor.doQuery() Methods query the database .

copyright:author[m0_ sixty-four million eight hundred and sixty-seven thousand t],Please bring the original link to reprint, thank you.