mycat cobar amoebar报告

1、目录第1章 引言11.1 编写目的11.2 项目背景1第2章 测试概要12.1 cobar 1.2.712.1.1 测试目的12.1.2 测试环境12.1.3 测试数据22.1.4 测试用例和运行方式22.2 mycat32.2.1 测试目的32.2.2 测试环境32.2.3 测试数据42.2.4 测试用例52.3 大表72.3.1 概念描述72.3.2测试目的72.3.3 测试环境82.3.4 测试用例9第3章 测试结果153.1 cobar 1.2.7153.1.1 cobar 性能测试153.1.2 cobar稳定性测试163.1.3 cobar测试局限性163.2 mycat173.2

2、.1 mycat性能测试173.2.3 mycat测试局限性183.2.2 mycat之mysql函数关键字测试183.3 大表193.3.1 大表查询与原查询之间的执行时间比较193.3.2 不同数据量之间的执行时间比较203.3.3 优化前后大表查询性能的比较21第4章 测试结论与建议234.1 测试结论234.2建议23第1章 引言第1章 引言1.1 编写目的本测试报告为MySQL代理项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果。预期参考人员包括测试人员，项目管理者和其他需要阅读本报告的相关人员。1.2 项目背景随着传统的数据库技术日趋成熟，计算机网络技术的飞速发展和应用范

3、围的扩充，数据库应用已经普遍建立于计算机网络之上，这时集中式数据库系统表现出它的不足：集中式处理，势必造成性能瓶颈应用程序集中在一台计算机上运行，一旦该计算机发生故障，则整个系统受到影响，可靠性不高。集中式处理引起系统的规模和配置都不够灵活，系统的可扩充性差。在这种形势下，集中式数据库将向分布式数据库发展成为一种必然的趋势，而cobar，mycat均致力于mysql的分布式数据库前端代理层，对cobar及mycat进行相关的测试是将其应用于实际的首要前提。24第2章 测试概要第2章 测试概要本项目主要针对mysql的代理中间件进行了性能，稳定性，功能测试，分别对cobar及Mycat进行了相关

4、的测试，下面就cobar及mycat的测试情况分别展开。2.1 cobar .1 测试目的对cobar1.2.7进行性能测试及稳定性测试，其中性能测试是通过其与MYSQL的对比，及对其自身的性能评估来进行的。2.1.2 测试环境本实验采用分布式架构，使用了四台服务器，其中两台服务器作为mysql服务器，一台作为cobar服务器，一台用作Jmeter监听服务器，如图2.1所示：服务器ACobar服务器CMysql服务器 AJmeter服务器BCobar 图 2.1 cobar测试环境架构图1） 硬件环境主机/ip硬件配置操作系统及内核版本服务器A16CP

5、U8 ×Intel(R) Xeon(R) CPU    E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器B17CPU8 ×Intel(R) Xeon(R) CPU   E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M

6、服务器C18CPU8 ×Intel(R) Xeon(R) CPU     E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M2） 软件环境软件名称版本备注1JDK1.6.0_25服务器A、B、C2mysql5.1.40服务器C3Jdbc Driver5.1.16服务器A4Cobar1.2.7服务器B，C2.1.3 测试数据1) 单字段拆分，拆分字段为int类型2) 16个分库3

7、) 所有select场景，拆分库16个分库一共90w条数据，平均分布于每个分库，每次查询的数据平均落在各查询分库。2.1.4 测试用例和运行方式cobar性能测试用例1.cobar1.2.7 与 mysql 对比选取单条语句插入或查询与Mysql进行对比，每条sql语句插入或者查询的数据量分别为128B，2K和64K2.cobar自身评估1) 所有cobar1.2.7相关的场景（除拆分库无拆分字段和非拆分库）都比较了sql中带schema和不带schema的差别2) 除1.中的对比场景中运行的场景之外，加入单条记录64K的查询语句以及多种插入语句场景。多值插入场景，每条记录大小128B，2K，

8、64K，记录随机分布1-16个库中，只有当记录大小为64K时，每条插入语句的记录条数为128，其余仍为1000。3) cobar1.2.7不同分库情况下性能对比。分别4个分库和16个分库进行比较，只比较查询效率，查询时结果平均分布在4个库或16个库中。cobar稳定性测试用例采用多个场景混合运行的方式测试cobar的稳定性，包括不同并发，不同分库下的插入和查询，单条记录数据量分别为128B，2K，64K，多库情况下，每条sql访问的记录数为2-1000，分别落入1-16个分库cobar性能运行方式每个用例选取不同并发，每个并发运行3分钟cobar 稳定性测试运行方式多用例混合运行：每个用例一个

9、并发，同时运行所有用例。注：每条sql访问1-1000个记录不等。2.2 mycat2.2.1 测试目的在分布式的环境中对mycat进行性能，功能及mysql中的函数，关键字在mycat中可用性测试，找出mycat的性能瓶颈，测试出mysql中哪些函数或关键字在进行跨库的数据操作时会出现错误。2.2.2 测试环境实验在分布式环境下进行，一共使用4台服务器，其中3台作为mysql服务器，一台作为mycat服务器，其架构图如图2.2所示：Mycat服务器Mysql服务器2Mysql服务器1Mysql服务器3图2.2 mycat测试环境架构图1）硬件环境主机/ip硬件配置操作系统及内核版本服务器12

10、16CPU8 ×Intel(R) Xeon(R) CPU    E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器217CPU8 ×Intel(R) Xeon(R) CPU   E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x8

11、6_64内存32G网络1000M服务器318CPU8 ×Intel(R) Xeon(R) CPU     E5420  2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M2）软件环境软件名称版本备注1JDK1.6.0_25服务器A、B、C2mysql5.1.40服务器C3Jdbc Driver5.1.16服务器A4Cobar1.2.7服务器B，C2.2.3 测试数据测试数据由两部分数据组成：

12、TPC-H数据和自定义数据。TPC-H数据由TPC-H数据生成器生成，生成因子分别别SF = 0.2；SF=2。TPC-H的表结构如下图所示，在SF=2时生成的数据大小包括（lineitem表12000000行，orders表3000000行，partsupp表1600000行，part表400000行，customer表300000行，supplier表20000行，nation固定为25行，region固定为5行），其中lineitem表大约为500M的数据：自定义数据由JAVA程序生成，由简单的单表构成，生成数据量为100万tuples、500万tuples和1000万tuples，表结

13、构包括id和name两列，id为int类型，name为100个字符的char类型，用于数据插入及并发测试。2.2.4 测试用例TPC-H测试用例包括TPC-H的语句Q1、Q6和Q13，涵盖了分组，聚集，连接，子查询等多种操作。具体的查询语句如下：Q1：selectl_returnflag,l_linestatus,sum(l_quantity) as sum_qty,sum(l_extendedprice) as sum_base_price,sum(l_extendedprice*(1-l_discount) as sum_disc_price,sum(l_extendedprice*(1-

14、l_discount)*(1+l_tax) as sum_charge,avg(l_quantity) as avg_qty,avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc,count(*) as count_orderfromlineitemwherel_shipdate <= date '1998-12-01' - interval 'DELTA' day (3)group byl_returnflag,l_linestatusorder byl_returnflag,l_l

15、inestatus;Q6：selectsum(l_extendedprice*l_discount) as revenuefromlineitemwherel_shipdate >= date 'DATE'and l_shipdate < date 'DATE' + interval '1' yearand l_discount between DISCOUNT - 0.01 and DISCOUNT + 0.01and l_quantity < QUANTITY;Q13：selectc_count, count(*) as c

16、ustdistfrom (selectc_custkey,count(o_orderkey)fromcustomer left outer join orders onc_custkey = o_custkeyand o_comment not like %WORD1%WORD2%group byc_custkey)as c_orders (c_custkey, c_count)group byc_countorder bycustdist desc,c_count desc;自定义测试数据集的测试用例主要包括：1. 并发查询测试语句：Select * From test Where id=$

17、Random(0,10000000)2. 模拟插入语句insert into test (id, name) values (?, ?) 通过java连接到数据库中间件，进行插入并发插入操作，并发线程数为4到500。2.3 大表2.3.1 概念描述将现有数据表中的每个属性值都存放在一张表的同一列中，同时存入该属性值所在表的名称、所在列的名称以及原表中所属行号信息，具体表结构如表2.1所示：表2.1 大表newtable的表结构字段名类型是否为空备注RowIDint(11)not null主键，自增，大表唯一IDTableNamevarchar(50)null原表中数据所在表的名称TupleNu

18、mint(11)null原表中数据所属行号PropertyNamevarchar(50)null原表中数据所在列名ElementValuevarchar(150)null数据值2.3.2测试目的由于我们对数据存储的表结构进行了修改，所以针对原有表的SQL语句无法直接应用在大表上，需要对其进行修改，并通过多个查询语句模拟实现原来的SQL，从而达到原SQL语句的效果。此外，由于大表结构的特殊性导致整张表的容量一定大于原有表的总和，而且其存储的元组数也远大于先前。由于存在着上述两个因素，针对大表的查询效率一定会有所下降，所以基于大表的查询效率就成了重点关注的方面。我们需要针对不同数据量大小的大表进行

19、查询，并且分别在单结点和MyCat分布式结点上进行测试与比较。通过测试，我们能够发现查询的瓶颈，并针对瓶颈提出优化方案，例如进行数据压缩、建立不同类型的索引、修改查询语句等优化操作，通过测试结果分析是否有提高效率的可能，最终找到最佳优化方案。2.3.3 测试环境我们将测试分为两大块：单机测试以及以mycat为代理的分布式环境测试。单机环境目前实验室中的服务器安装的是64位CentOS 6.4版本的 Linux操作系统，网络带宽可以达到1000M，详细配置见表2.2。表2.2单节点服务器配置名称说明服务器硬件配置：操作系统：CPU：8×Intel(R) Xeon(R) CPU 

20、;E5420 2.40GHzCentOS release 6.4 (Final)内存：32G网络带宽：1000MMysql版本：5.1.66服务器集群环境实验室环境中有3台服务可供测试使用，所以集群中可以设置3个结点，3个结点的配置信息以及IP地址在表2.3中列出。表2.3 服务器集群配置主机/ip硬件配置操作系统及内核版本服务器A16CPU8×Intel(R) Xeon(R) CPU E5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服

21、务器B17CPU8×Intel(R) Xeon(R) CPU E5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M服务器C18CPU8×Intel(R) Xeon(R) CPU E5420 2.40GHzCentOS release 6.4 (Final)Linux version 2.6.32-358.el6.x86_64内存32G网络1000M此外，服务器集群中的mysql版本以及

22、部署的mycat代理版本信息见表2.4。表2.4 集群环境的软件配置Mysql版本：5.1.66Mycat版本： 测试用例采用TPC-H生成的数据进行测试，其中包括8张数据表，分别是customer, lineitem, nation, orders, part, partsupp, supplier和region表。各个数据表中的列及其关系如图4.1所示。TPC-H的标准SQL查询语句有22条，在测试过程中，我们选择了一些基本查询操作以及这22条查询中的部分SQL语句，对其进行了重写以便能够在新的大表结构中完成同样的查询操作。重写后的第4条查询语句：SELECTtable2.

23、ElementValue AS O_ORDERPRIORITY,COUNT(*) AS order_countFROMnewtable table1,newtable table2WHEREtable1.TableName = "orders"AND table1.PropertyName = "O_ORDERDATE"AND STR_TO_DATE(table1.ElementValue,"%Y-%m-%d") >= '1993-07-01'AND STR_TO_DATE(table1.ElementValue

24、,"%Y-%m-%d") < '1993-07-01' + INTERVAL '3' MONTHAND table2.TableName = table1.TableNameAND table2.TupleNum = table1.TupleNumAND table2.PropertyName = "O_ORDERPRIORITY"AND EXISTS (SELECT*FROMnewtable table5,newtable table6WHEREtable5.TableName = "lineitem&q

25、uot;AND table5.PropertyName = "L_COMMITDATE"AND table6.TableName = "lineitem"AND table6.PropertyName = "L_RECEIPTDATE"AND STR_TO_DATE(table5.ElementValue,"%Y-%m-%d %k:%i:%s") < STR_TO_DATE(table6.ElementValue,"%Y-%m-%d %k:%i:%s")GROUP BYO_ORDERPRI

26、ORITYORDER BYO_ORDERPRIORITY;重写后的第6条查询语句SELECTsum(val_extendedprice.ElementValue + 0.0) * (val_discount.ElementValue + 0.0) AS revenueFROM(SELECT DISTINCTt_result.TupleNumFROM(SELECTt_shipdate.TupleNumFROMnewtable t_shipdateWHEREt_shipdate.TableName = "lineitem"AND t_shipdate.PropertyName

27、= "l_shipdate"AND STR_TO_DATE( t_shipdate.ElementValue,"%Y-%m-%d" ) >= '1994-01-01'AND STR_TO_DATE( t_shipdate.ElementValue, "%Y-%m-%d" ) < '1994-01-01' + INTERVAL '1' YEAR)UNION ALL(SELECTt_quantity.TupleNumFROMnewtable t_quantityWHEREt_qu

28、antity.TableName = "lineitem"AND t_quantity.PropertyName = "l_quantity"AND (t_quantity.ElementValue + 0) < 24)UNION ALL(SELECTt_discount.TupleNumFROMnewtable t_discountWHEREt_discount.TableName = "lineitem"AND t_discount.PropertyName = "l_discount"AND (t_di

29、scount.ElementValue + 0) BETWEEN0.06 - 0.01 AND 0.06 + 0.01) AS t_resultGROUP BYt_result.TupleNumHAVINGCOUNT(*) > 2) AS t_tuple,newtable val_extendedprice,newtable val_discountWHEREval_discount.TableName = "lineitem"AND val_discount.PropertyName = "l_discount"AND val_discount.

30、TupleNum = t_tuple.TupleNumAND val_extendedprice.TableName = "lineitem"AND val_extendedprice.PropertyName = "l_extendedprice"AND val_extendedprice.TupleNum = t_tuple.TupleNum;重写后的第12条查询语句SELECTt_l_shipmode.ElementValue AS L_SHIPMODE,sum(CASEWHEN t_o_orderpriority.ElementValue = &

31、#39;1-URGENT'OR t_o_orderpriority.ElementValue = '2-HIGH' THEN1ELSE0END) AS high_line_count,sum(CASEWHEN t_o_orderpriority.ElementValue <> '1-URGENT'AND t_o_orderpriority.ElementValue <> '2-HIGH' THEN1ELSE0END) AS low_line_countFROM(SELECTt_result.TupleNumFROM

32、(SELECTt_receiptdate.TupleNumFROMnewtable t_receiptdate,newtable t_commitdateWHEREt_receiptdate.TableName = "lineitem"AND t_receiptdate.PropertyName = "l_receiptdate"AND STR_TO_DATE(t_receiptdate.ElementValue,"%Y-%m-%d") >= date '1994-01-01'AND STR_TO_DATE(t_

33、receiptdate.ElementValue,"%Y-%m-%d") < date '1994-01-01' + INTERVAL '1' YEARAND t_commitdate.TableName = "lineitem"AND t_commitdate.PropertyName = "l_commitdate"AND t_commitdate.TupleNum = t_receiptdate.TupleNumAND STR_TO_DATE(t_commitdate.ElementValu

34、e,"%Y-%m-%d %k:%i:%s") < STR_TO_DATE(t_receiptdate.ElementValue,"%Y-%m-%d %k:%i:%s")UNION ALLSELECTt_shipdate.TupleNumFROMnewtable t_shipdate,newtable t_commitdateWHEREt_shipdate.TableName = "lineitem"AND t_shipdate.PropertyName = "l_shipdate"AND t_commitda

35、te.TableName = "lineitem"AND t_commitdate.PropertyName = "l_commitdate"AND t_commitdate.TupleNum = t_shipdate.TupleNumAND STR_TO_DATE(t_shipdate.ElementValue,"%Y-%m-%d %k:%i:%s") < STR_TO_DATE(t_commitdate.ElementValue,"%Y-%m-%d %k:%i:%s")UNION ALLSELECTt_s

36、hipmode.TupleNumFROMnewtable t_shipmodeWHEREt_shipmode.TableName = "lineitem"AND t_shipmode.PropertyName = "l_shipmode"AND t_shipmode.ElementValue IN ('MAIL', 'SHIP') AS t_resultGROUP BYt_result.TupleNumHAVINGCOUNT(*) > 2) AS t_tuple,newtable t_l_shipmode,newta

37、ble t_o_orderpriority,newtable t_o_orderkey,newtable t_l_orderkeyWHEREt_l_shipmode.TableName = "lineitem"AND t_l_shipmode.PropertyName = "l_shipmode"AND t_l_shipmode.TupleNum = t_tuple.TupleNumAND t_l_orderkey.TableName = "lineitem"AND t_l_orderkey.PropertyName = "

38、l_orderkey"AND t_l_orderkey.TupleNum = t_tuple.TupleNumAND t_o_orderkey.TableName = "orders"AND t_o_orderkey.PropertyName = "o_orderkey"AND t_o_orderkey.ElementValue = t_l_orderkey.ElementValueAND t_o_orderpriority.TableName = "orders"AND t_o_orderpriority.Property

39、Name = "o_orderpriority"AND t_o_orderpriority.TupleNum = t_o_orderkey.TupleNumGROUP BYL_SHIPMODEORDER BYL_SHIPMODE;第3章 测试结果第3章 测试结果3.1 cobar .1 cobar 性能测试1.cobar1.2.7 与 mysql对比1） insert 语句： 5个并发以内，mysql 的处理能力大约是cobar的2倍，单条insert语句包含的数据量越大，性能差异会越小。大于5个并发后，cobar与mysql处理能力趋于一致。cobar在8

40、个并发左右达到处理瓶颈，mysql在5个并发左右达到处理瓶颈2） select语句 ：20个并发以内，mysql 的处理能力大约是cobar的2倍，单条select语句包含的数据量越大，性能差异越小。大于20个并发后，cobar与mysql的处理能力趋于一致。cobar 在30-40个并发左右达到处理瓶颈，mysql在10-20个并发后达到处理瓶颈3） cobar1.2.7与mysql性能测试数据对比如表3.1所示表3.1 性能测试数据对比图语句单条数据量并发cobar1.2.7MysqlTPSRT（ms）TPSRT（ms）insert128B48017.19 0.50 14541.64 0.

41、28 1213397.00 0.90 15394.49 0.78 2K44547.64 0.88 7746.71 0.52 126310.11 1.90 6688.23 1.79 64K4435.16 9.19 486.56 8.22 12370.33 32.40 459.34 26.12 select128B1017786.97 0.56 32011.03 0.31 5047672.21 1.26 46781.77 1.06 2K1012066.67 0.83 26873.43 0.37 5038876.89 1.54 42348.76 1.42 64K101139.89 8.77 1745

42、.59 5.73 501468.81 40.85 1784.26 33.63 2.cobar1.2.7 自身评估1） 并发数较小的时候，并发数的多少对Cobar的性能影响较大2） 限于网络带宽的限制，并发量和单条数据的大小密切相关3） Sql查询中带schema 与不带schema性能差距较小4） 各测试情况下性能数据如表3.2所示：表3.2 性能测试结果单条数据量数据量数据分布128BSelectInsert并发TPS并发TPS128B100016个分库10117.27 637.81 4个分库20123.87 -2016个分库103397.70 81459.84 4个分库205556.59

43、-2K100016个分库2038.21 88.21 4个分库2043.44 -2016个分库201561.56 12344.70 4个分库201762.79 -64K1000（插入128）16个分库200.10 43.04 4个分库41.46 -2016个分库2075.20 1222.56 4个分库2082.29 -3.1.2 cobar稳定性测试多场景混合运行：运行4小时，未发生任何异常。3.1.3 cobar测试局限性1) 由于测试机器有限， mysql很多场景下，尤其是多库的场景，load非常高，而cobar并未到达其自身处理能力最大值2) 压力工具选用的jmeter，由于jmeter对

44、于响应时间不足1ms情况不能精确显示，因此响应时间是通过TPS数据计算而得3) 由于场景过多，性能测试每个小场景只运行3分钟，每隔30s取一次TPS数据进行计算，因此，场景初始化时的一些不稳定的TPS容易对测试总体结果造成一些小影响。3.2 mycat3.2.1 mycat性能测试1.分片表的插入性能测试；取较大并发线程，100；插入的数据，分别为100万、500万、1000万；测试结果如表3.3所示：表3.3 mycat插入性能测试结果1000000500000010000000平均TPSMyCAT1.2.3166391586815218MySQL156011492114243总时间（s）M

45、yCAT1.2.360315657MySQL64335702就插入性能来讲，MyCAT1.2.3的插入性能大概是MySQL的88%-94%左右；查询性能测试以1000万的数据为准；分片表的查询性能测试；取较大并发线程：100；取的查询次数分别为：1000000、5000000、10000000，其测试结果如表3.4 所示：表3.4 mycat查询性能测试结果100000020000005000000平均TPSMyCAT1.2.311978171118836MySQL164542053610542总时间（s）MyCAT1.2.384117崩溃MySQL6197崩溃从结果来看，当执行1000000

46、次查询时，MyCAT1.2.3的性能是MySQL的70%，当执行2000000条查询时，性能约为83%；3.更新性能测试；分片表的更新性能测试；取较大并发线程：100；取的更新语句分别为：10000、50000、100000，其测试结果如表3.5所示：表3.5 mycat更新性能测试结果10000500001000002000005000001000000平均TPSMyCAT1.2.332261219514085141841312312642MySQL2439980410989116961039510091总时间（s）MyCAT1.2.3347143879MySQL459174899更新性能测

47、试来讲，更新100000条数据时，性能比是75%，当数据量为50000时，性能比是80%，数据量为100000时，性能比约为82%，50万时性能比约为79%，100万条时性能比约为80%。3.2.2 mycat稳定性测试在插入测试中，利用500并发线程插入1000万条数据，会发生部分数据丢失的情况，丢失的比率约为万分之一，插入时平均CPU占用率约为50-60%。在1000万行的数据上做查询操作，100线程并发，进行1000000次查询耗时84s，CPU占用率65%左右，进行2000000次查询耗时117s，CPU占用率80% 左右，5000000次查询等待2000s以上无响应。3.2.3 my

48、cat测试局限性1) 由于测试机器有限， mysql很多场景下，尤其是多库的场景，load非常高，而mycat并未到达其自身处理能力最大值2) 压力工具选用的jmeter，由于jmeter对于响应时间不足1ms情况不能精确显示，因此响应时间是通过TPS数据计算而得3) MyCAT不支持批量插入，以上的测试都是在非批量插入的情况下进行的测试，但MySQL是支持批量插入的，但这种场景下，我们没有办法比较两者之间批量插入的性能差异；同时，由于测量工具有限，不能对所有方面进行全面的比较，这也是我们测试的一个重大局限方面。3.2.2 mycat之mysql函数关键字测试经测试跨库操作会导致出错的函数如表

49、3.6所示：表3.6 出错函数表函数类型函数测试用例错误描述聚合函数Avgselect avg（c_custkey）from customer where c_custkey>49950 and c_custkey<50050;数据分布在多个节点时，返回结果错误group_concatselect group_concat(c_nationkey) from customer group by c_nationkey;Mycat不支持该函数关键字Group byselect * from customer where c_custkey between 49910 and 5002

50、0 group by c_nationkey;数据分布在多个节点上，返回的结果没有归并的操作Distinctselect distinct(c_nationkey) from customer where c_custkey between 49910 and 50080 order by c_nationkey;数据分布在多个节点上，返回的结果没有归并的操作ANALYZEANALYZE table customer;Mycat不支持该函数Cross.joinselect * from orders cross JOIN customer on orders.o_custkey=custome

51、r.c_custkey where c_custkey=49910;Mycat不支持该函数数字类型转换函数Convertselect convert(12,signed)Mycat不支持该函数字符串函数INSERTselect INSERT('Quadratic', 3, 1, 'What');Mycat不支持该函数Charselect CHAR(77,121,83,81,76)3.3 大表3.3.1 大表查询与原查询之间的执行时间比较这里我们将在两种数据量规模下进行测试：(1).第一个测试是在TPC-H生成的原数据量为10MB情况下测试的，此时通过我们的多线程

52、导入程序将8个分表转换成大表的结构存储在服务器端的Mysql中，转换后大表的数据量为33.95MB，是原数据量的3.4倍。表3.7描述了不同查询的执行时间：表3.7大表数据量为34MB的查询耗时对比分析表(单位：秒)测试1实验环境：单机；大表数据769108条，数据长度33.95 MB原查询(10MB)大表查询(33.95MB)耗时对比说明第4条查询0.0190.263大表查询的耗时是原查询的13.8倍第6条查询0.0380.463大表查询的耗时是原查询的12.2倍第12条查询0.0322.187大表查询的耗时是原查询的68.3倍(2).测试2中的原数据量为20MB，转换后大表的数据量为99.63MB，是原数据量的5倍。测试结果如表5-2所示，当数据规模增大时，大表查询的耗时会相应增长，但增长的幅度会根据查询语句的不同而有所差异，例如第4条查询与第12条查询的时间增长幅度较小，而第6条查询语句的幅度增长较大。与原查询相比，大表查询的耗时平均比原查询多16.8倍。图3.8也可以直观看出大表查询与原查询之间的耗时对比。表3.8 大表数据量为100MB的查询耗时对比分析表(单位：秒)测试2实