MySQL prepare 原理

时间 2019-11-11

原文原文链接

Prepare的好处

Prepare SQL产生的缘由。首先从mysql服务器执行sql的过程开始讲起，SQL执行过程包括如下阶段词法分析->语法分析->语义分析->执行计划优化->执行。词法分析->语法分析这两个阶段咱们称之为硬解析。词法分析识别sql中每一个词，语法分析解析SQL语句是否符合sql语法，并获得一棵语法树（Lex）。对于只是参数不一样，其余均相同的sql，它们执行时间不一样但硬解析的时间是相同的。而同一SQL随着查询数据的变化，屡次查询执行时间可能不一样，但硬解析的时间是不变的。对于sql执行时间较短，sql硬解析的时间占总执行时间的比率越高。而对于淘宝应用的绝大多数事务型SQL，查询都会走索引，执行时间都比较短。所以淘宝应用db sql硬解析占的比重较大。 html

Prepare的出现就是为了优化硬解析的问题。Prepare在服务器端的执行过程以下java

1） Prepare 接收客户端带”?”的sql, 硬解析获得语法树(stmt->Lex), 缓存在线程所在的preparestatement cache中。此cache是一个HASH MAP. Key为stmt->id. 而后返回客户端stmt->id等信息。mysql

2） Execute 接收客户端stmt->id和参数等信息。注意这里客户端不须要再发sql过来。服务器根据stmt->id在preparestatement cache中查找获得硬解析后的stmt, 并设置参数，就能够继续后面的优化和执行了。git

Prepare在execute阶段能够节省硬解析的时间。若是sql只执行一次，且以prepare的方式执行，那么sql执行需两次与服务器交互（Prepare和execute）, 而以普通（非prepare）方式，只须要一次交互。这样使用prepare带来额外的网络开销，可能得不偿失。咱们再来看同一sql执行屡次的状况，好比以prepare方式执行10次，那么只须要一次硬解析。这时候额外的网络开销就显得微乎其微了。所以prepare适用于频繁执行的SQL。github

Prepare的另外一个做用是防止sql注入，不过这个是在客户端jdbc经过转义实现的，跟服务器没有关系。 sql

硬解析的比重

压测时经过perf 获得的结果，硬解析相关的函数比重都比较靠前（MYSQLparse 4.93%, lex_one_token 1.79%, lex_start 1.12%）总共接近8%。所以，服务器使用prepare是能够带来较多的性能提高的。缓存

jdbc与prepare

jdbc服务器端的参数：服务器

useServerPrepStmts：默认为false. 是否使用服务器prepare开关网络

jdbc客户端参数：mybatis

cachePrepStmts：默认false.是否缓存prepareStatement对象。每一个链接都有一个缓存，是以sql为惟一标识的LRU cache. 同一链接下，不一样stmt能够不用从新建立prepareStatement对象。

prepStmtCacheSize：LRU cache中prepareStatement对象的个数。通常设置为最经常使用sql的个数。

prepStmtCacheSqlLimit：prepareStatement对象的大小。超出大小不缓存。

Jdbc对prepare的处理过程：

useServerPrepStmts=true时Jdbc对prepare的处理

1）建立PreparedStatement对象，向服务器发送COM_PREPARE命令，并传送带问号的sql. 服务器返回jdbc stmt->id等信息

2）向服务器发送COM_EXECUTE命令,并传送参数信息。

useServerPrepStmts=false时Jdbc对prepare的处理

1）建立PreparedStatement对象，此时不会和服务器交互。

2）根据参数和PreparedStatement对象拼接完整的SQL，向服务器发送QUERY命令

咱们再看参数cachePrepStmts打开时在useServerPrepStmts为true或false时，均缓存PreparedStatement对象。只不过useServerPrepStmts为的true缓存PreparedStatement对象包含服务器的stmt->id等信息，也就是说若是重用了PreparedStatement对象，那么就省去了和服务器通信（COM_PREPARE命令）的开销。而useServerPrepStmts=false是，开启cachePrepStmts缓存PreparedStatement对象只是简单的sql解析信息，所以此时开启cachePrepStmts意义不是太大。

咱们来开看一段java代码

            Connection con = null; PreparedStatement ps = null; String sql = "select * from user where id=?"; ps = con.prepareStatement(sql); ps.setInt(1, 1);‍‍ ps.executeQuery(); ps.close(); ps = con.prepareStatement(sql); ps.setInt(1, 3); ps.executeQuery(); ps.close();

这段代码在同一会话中两次prepare执行同一语句，而且之间有ps.close();

useServerPrepStmts=false时，服务器会两次硬解析同一SQL。

useServerPrepStmts=true, cachePrepStmts=false时服务器仍然会两次硬解析同一SQL。

useServerPrepStmts=true, cachePrepStmts=true时服务器只会硬解析一次SQL。

若是两次prepare之间没有ps.close();那么cachePrepStmts=true，cachePrepStmts=false也只需一次硬解析.

所以，客户端对同一sql,频繁分配和释放PreparedStatement对象的状况下，开启cachePrepStmts参数是颇有必要的。

测试

1)作了一个简单的测试，主要测试prepare的效果和useServerPrepStmts参数的影响.

        cnt = 5000; // no prepare
        String sql = "select biz_order_id,out_order_id,seller_nick,buyer_nick,seller_id,buyer_id,auction_id,auction_title,auction_price,buy_amount,biz_type,sub_biz_type,fail_reason,pay_status,logistics_status,out_trade_status,snap_path,gmt_create,status,ifnull(buyer_rate_status, 4) buyer_rate_status from tc_biz_order_0030 where " +
        "parent_id = 594314511722841 or parent_id =547667559932641;"; begin = new Date(); System.out.println("begin:" + df.format(begin)); stmt = con.createStatement(); for (int i = 0; i < cnt; i++) { stmt.executeQuery(sql); } end = new Date(); System.out.println("end:" + df.format(end)); long temp = end.getTime() - begin.getTime(); System.out.println("no perpare interval:" + temp); // test prepare 
        sql = "select biz_order_id,out_order_id,seller_nick,buyer_nick,seller_id,buyer_id,auction_id,auction_title,auction_price,buy_amount,biz_type,sub_biz_type,fail_reason,pay_status,logistics_status,out_trade_status,snap_path,gmt_create,status,ifnull(buyer_rate_status, 4) buyer_rate_status from tc_biz_order_0030 where " +
                "parent_id = 594314511722841 or parent_id =?;"; ps = con.prepareStatement(sql); BigInteger param = new BigInteger("547667559932641"); begin = new Date(); System.out.println("begin:" + df.format(begin)); for (int i = 0; i < cnt; i++) { ps.setObject(1, param); ps.executeQuery(); } end = new Date(); System.out.println("end:" + df.format(end)); temp = end.getTime() - begin.getTime(); System.out.println("prepare interval:" + temp);

经屡次采样测试结果以下

	非prepare和prepare时间比
useServerPrepStmts=true	0.93
useServerPrepStmts=false	1.01

结论：

useServerPrepStmts=true时，prepare提高7%；

useServerPrepStmts=false时，prepare与非prepare性能至关。

若是将语句简化为select * from tc_biz_order_0030 where parent_id =?。那么测试的结论useServerPrepStmts=true时，prepare仅提高2%；sql越简单硬解析的时间就越少，prepare的提高就越少。

注意：这个测试是在单个链接，单条sql的理想状况下进行的，线上会出现多链接多sql,还有sql执行频率，sql的复杂程度等不一样，所以prepare的提高效果会随具体环境而变化。

2）prepare 先后的perf top 对比

如下为非prepare

     6.46% mysqld mysqld [.] _Z10MYSQLparsePv 3.74%   mysqld  libc-2.12.so [.] __memcpy_ssse3 2.50% mysqld mysqld [.] my_hash_sort_utf8 2.15% mysqld mysqld [.] cmp_dtuple_rec_with_match 2.05% mysqld mysqld [.] _ZL13lex_one_tokenPvS_ 1.46% mysqld mysqld [.] buf_page_get_gen 1.34% mysqld mysqld [.] page_cur_search_with_match 1.31% mysqld mysqld [.] _ZL14build_templateP19row_prebuilt_structP3THDP5TABLEj 1.24% mysqld mysqld [.] rec_init_offsets 1.11%   mysqld  libjemalloc.so.1 [.] free 1.09% mysqld mysqld [.] rec_get_offsets_func 1.01%   mysqld  libjemalloc.so.1 [.] malloc 0.96%   mysqld  libc-2.12.so [.] __strlen_sse42 0.93% mysqld mysqld [.] _ZN4JOIN8optimizeEv 0.91% mysqld mysqld [.] _ZL15get_hash_symbolPKcjb 0.88% mysqld mysqld [.] row_search_for_mysql 0.86% mysqld [kernel.kallsyms] [k] tcp_recvmsg

如下为perpare

     3.46%   mysqld  libc-2.12.so [.] __memcpy_ssse3 2.32% mysqld mysqld [.] cmp_dtuple_rec_with_match 2.14% mysqld mysqld [.] _ZL14build_templateP19row_prebuilt_structP3THDP5TABLEj 1.96% mysqld mysqld [.] buf_page_get_gen 1.66% mysqld mysqld [.] page_cur_search_with_match 1.54% mysqld mysqld [.] row_search_for_mysql 1.44% mysqld mysqld [.] btr_cur_search_to_nth_level 1.41%   mysqld  libjemalloc.so.1 [.] free 1.35% mysqld mysqld [.] rec_init_offsets 1.32% mysqld [kernel.kallsyms] [k] kfree 1.14%   mysqld  libjemalloc.so.1 [.] malloc 1.08% mysqld [kernel.kallsyms] [k] fget_light 1.05% mysqld mysqld [.] rec_get_offsets_func 0.99% mysqld mysqld [.] _ZN8Protocol24send_result_set_metadataEP4ListI4ItemEj 0.90% mysqld mysqld [.] sync_array_print_long_waits 0.87% mysqld mysqld [.] page_rec_get_n_recs_before 0.81% mysqld mysqld [.] _ZN4JOIN8optimizeEv 0.81%   mysqld  libc-2.12.so [.] __strlen_sse42 0.78% mysqld mysqld [.] _ZL20make_join_statisticsP4JOINP10TABLE_LISTP4ItemP16st_dynamic_array 0.72% mysqld [kernel.kallsyms] [k] tcp_recvmsg 0.63%   mysqld  libpthread-2.12.so [.] __pthread_getspecific_internal 0.63% mysqld [kernel.kallsyms] [k] sk_run_filter 0.60% mysqld mysqld [.] _Z19find_field_in_tableP3THDP5TABLEPKcjbPj 0.60% mysqld mysqld [.] page_check_dir 0.57%   mysqld  mysqld              [.] _Z16dispatch_command19enum_server_commandP3THDP

对比能够发现 MYSQLparse lex_one_token在prepare时已优化掉了。

思考

1 开启cachePrepStmts的问题，前面谈到每一个链接都有一个缓存，是以sql为惟一标识的LRU cache. 在分表较多，大链接的状况下，可能会个应用服务器带来内存问题。这里有个前提是ibatis是默认使用prepare的。在mybatis中，标签statementType能够指定某个sql是不是使用prepare.

statementType Any one of STATEMENT, PREPARED or CALLABLE. This causes MyBatis to use Statement, PreparedStatement orCallableStatement respectively. Default: PREPARED.

这样能够精确控制只对频率较高的sql使用prepare，从而控制使用prepare sql的个数，减小内存消耗。遗憾的是目前集团貌似大多使用的是ibatis 2.0版本，不支持statementType

标签。

2 服务器端prepare cache是一个HASH MAP. Key为stmt->id,同时也是每一个链接都维护一个。所以也有可能出现内存问题，待实际测试。若有必要需改形成Key为sql的全局cache，这样不一样链接的相同prepare sql能够共享。

3 oracle prepare与mysql prepare的区别：

mysql与oracle有一个重大区别是mysql没有oracle那样的执行计划缓存。前面咱们讲到SQL执行过程包括如下阶段词法分析->语法分析->语义分析->执行计划优化->执行。oracle的prepare实际上包括如下阶段：词法分析->语法分析->语义分析->执行计划优化，也就是说oracle的prepare作了更多的事情，execute只须要执行便可。所以，oracle的prepare比mysql更高效。