首页
学习
活动
专区
圈层
工具
发布

关于update语句的性能测试(62天)

今天对表的update进行了性能测试,收获不小。在linux 64位的环境中测试, 数据量是按照40万左右的标准进行的测试。...没有考虑索引(没有添加索引),没有考虑执行计划优化的影响,为了保证每次执行的环境基本一致,每次执行sql语句之前都先清空buffer cache....为了横向比较结果,缩小结果的误差,对表test使用了两条类似的sql语句,比较执行的结果,看看有多大的误差。...使用的sql语句为: update test set test='a'; update test set test=''; 基本上可以看出一些数据的执行情况, 在表为noparallel的情况下,使用...logging,nologging没有明显的性能提升,而且使用session级别的parallel,生成的redo和执行时间也没有任何提升。

1.5K70
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    性能评测:MyBatis 与 Hibernate 的性能差异

    当前流行的方案有Hibernate与myBatis。 两者各有优劣。竞争激烈,其中一个比较重要的考虑的地方就是性能。 因此笔者通过各种实验,测出两个在相同情景下的性能相关的指数,供大家参考。...测试目标 以下测试需要确定几点内容: 性能差异的场景; 性能不在同场景下差异比; 找出各架框优劣,各种情况下的表现,适用场景。 测试思路 测试总体分成:单表插入,关联插入,单表查询,多表查询。...其中hibernate非懒加载情况下与myBatis性能差异也是相对其他测试较大,平均值小于1ms。 这个差异的原因主要在于,myBatis加载的字段很干净,没有太多多余的字段,直接映身入关联中。...关联时一个差异比较大的地方则是懒加载特性。其中hibernate可以特别地利用POJO完整性来进行缓存,可以在一级与二级缓存上保存对象,如果对单一个对象查询比较多的话,会有很明显的性能效益。...然而myBatis则比直接,主要是做关联与输出字段之间的一个映射。其中sql基本是已经写好,直接做替换则可,不需要像hibernate那样去动态生成整条sql语句。

    2.7K30

    常与无常:SQL语句中常量的处理及性能差异解析

    第三个等式由于对列进行了运算,因此不能使用这个列上的常规索引。当然这种情况可以使用函数索引,但是显然函数索引的通用性不好,而且要求函数索引的表达式与查询的表达式要完全匹配。...对于这种情况,完全没有必要使用函数索引,而且如果使用函数索引除了增加系统的开销外,没有任何的好处。 CBO不使用索引本身就会极大地影响性能,但这还只是第三个等式的一个缺点而已。...简单地说,全表扫描多少记录,就会执行多少次的减法操作,因此当数据量大的时候,必然会带来一定的性能损害。 下面通过一个简单的例子来直观地说明问题,首先构造一个大数据量的测试用表。...它们的执行计划也完全一样,都是全表扫描,然后分别执行这些语句并记录所需的时间。 为了避免数据缓存带来的误差,每个SQL都执行两次,这里列出的都是第二次执行的时间。 语句1:推荐写法,也是标准的写法。...语句4:最差的一种写法。

    1.3K90

    自己动手做数据库系统:解释执行 update 和 delete 对应的 sql 语句

    在上一节我们完成了 select 语句的解释执行,本节我们看看 Update 和 Delete 对应的语句如何解释执行,当然他们的实现原理跟我们前面实现的 select 语句执行大同小异。...无论是 update还是 delete 都是对数据表的修改,因此他们的实现方法基本相同。...假设我们要执行如下 sql 语句: update STUDENT set MajorId=20 where MajorId=30 and GradYear=2020 delete from STUDENT...where MajorId=30 and GradYear=2020 要完成上面的代码,我们需要 scan底层的文件块,找到所有满足 where 条件的记录,如果语句是 update,那么把找到的记录修改掉...和 SelectPlan 找出要修改的记录,然后进行相应的操作,在上面代码实现中我们留有与索引相关的操作没有实现,因为索引是我们后续章节的一个重要内容。

    32110

    美团一面:如何干掉可恶的SQL注入?

    ,因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,...) 的 sql 语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了 SQL 注入问题。...,因此当使用不当时,会导致注入问题与使用 JDBC 不同的是,MyBatis 使用 #{} 和 ${} 来进行参数值替换。...org.example.User"> SELECT * FROM user WHERE name = '${name}' limit 1 name 值为 ' or '1'='1,实际执行的语句为...正确的用法: 位置参数 (Positional parameter) Query query = session.createQuery("from User where name = ?"

    1.3K40

    如何干掉恶心的 SQL 注入?

    JDBC 说明 直接使用 JDBC 的场景,如果代码中存在拼接 SQL 语句,那么很有可能会产生注入,如 // concat sql String sql = "SELECT * FROM users...,因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,...) 的 sql 语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了 SQL 注入问题。...,因此当使用不当时,会导致注入问题与使用 JDBC 不同的是,MyBatis 使用 #{} 和 ${} 来进行参数值替换。...正确的用法: 位置参数 (Positional parameter) Query query = session.createQuery("from User where name = ?"

    93010

    彻底干掉恶心的 SQL 注入漏洞, 一网打尽!

    ) 所有 Java 持久层技术都基于 JDBC 说明 直接使用 JDBC 的场景,如果代码中存在拼接 SQL 语句,那么很有可能会产生注入,如 // concat sql String sql = "...,因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,...) 的 sql 语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了 SQL 注入问题。...,因此当使用不当时,会导致注入问题与使用 JDBC 不同的是,MyBatis 使用 #{} 和 ${} 来进行参数值替换。...正确的用法: 位置参数 (Positional parameter) Query query = session.createQuery("from User where name = ?"

    4.4K40

    如何干掉恶心的 SQL 注入?

    直接使用 JDBC 的场景,如果代码中存在拼接 SQL 语句,那么很有可能会产生注入,如 // concat sql String sql = "SELECT * FROM users WHERE name...,因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,...) 的 sql 语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了 SQL 注入问题。...,因此当使用不当时,会导致注入问题与使用 JDBC 不同的是,MyBatis 使用 #{} 和 ${} 来进行参数值替换。...正确的用法: 位置参数 (Positional parameter) Query query = session.createQuery("from User where name = ?"

    90220

    彻底干掉恶心的 SQL 注入漏洞, 一网打尽!

    JDBC 更多请参考http://www.oracle.com/technetwork/java/javase/jdbc/index.html 说明 直接使用JDBC的场景,如果代码中存在分解SQL语句...因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了PreparedStatement 并不意味着不会产生注入,如果在使用PreparedStatement之前,存在拆分sql语句,那么仍然会导致注入...的sql语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了SQL注入问题。...,因此当使用不当时,会导致注入问题 与使用JDBC不同的是,MyBatis使用#{}和${}来进行参数值替换 使用#{}语法时,MyBatis会自动生成PreparedStatement,使用参数绑定(...query.getSingleResult(); 这里的User为类名,和原生SQL类似,拼接会导致注入 正确的用法: 位置参数(位置参数) Query query = session.createQuery

    1.8K10

    【SQL实用技巧】update,inner join与select语句的联合使用

    在实际操作数据库的时候,经常使用将update和select结合使用,例如使用select统计数据,然后update到对应的表,按照常规的实现方式,先select出来对应的数据,然后再执行update语句...先建两个测试表table1和table2,两个表的数据很简单,其记录条数分别为2和4,具体如下: ​假如现在要统计table1的id对应在table2中有多少条记录,保存在total字段里,这是经常会遇到的需求...如果按照常规的实现,就会先用select语句从table2中统计好数值,然后再写一个update语句更新到table1中,更新语句还得循环。...这个过程还有很多问题,例如如果更新语句中,有些成功,有些失败,这时怎么处理,这是比较难搞的问题。 可以如下实现: ​执行完成之后,table1中的total字段的值就会被改成2和4。...其实就是update可以和inner join联合使用,这样就可以使用另一个表的数据更新到当前的表。 这个很实用,只是以前一直没有注意。

    5.5K10

    Java SQL注入危害这么大,该如何来防止呢?

    ,因此可以使用白名单的方式来限制参数值 这里需要注意的是,使用了 PreparedStatement 并不意味着不会产生注入,如果在使用 PreparedStatement之前,存在拼接 sql 语句,...) 的 sql 语句只会被编译一次,之后执行只是将占位符替换为用户输入,并不会再次编译/解释,因此从根本上防止了 SQL 注入问题。...,因此当使用不当时,会导致注入问题 与使用 JDBC 不同的是,MyBatis 使用 #{} 和 ${} 来进行参数值替换 使用 #{} 语法时,MyBatis 会自动生成 PreparedStatement...org.example.User"> SELECT * FROM user WHERE name = '${name}' limit 1 name 值为 ' or '1'='1,实际执行的语句为...value="'%' + name + '%'" /> SELECT * FROM user WHERE name LIKE #{pattern} 语句内的

    1.5K40

    Spring全家桶之SpringData——Spring 整合Hibernate与Hibernate Jpa

    ,要先查询 ,根据id删除 Hibernate JPA中的HQL语句 Hibernate JPA中的SQL语句 Hibernate JPA中的SQL语句的QBC查询 实体类 接口类 接口实现类 测试类...-- hibernateProperties属性:配置与hibernate相关的内容,如显示sql语句,开启正向工程 --> 的对象 hibernateTemplate(增删改查方法如下) hibernateTemplate.save(users); hibernateTemplate.delete(users); hibernateTemplate.update...(Users users) { this.hibernateTemplate.delete(users); } public void update(Users users) { this.hibernateTemplate.update...(非主键列)-HQL查询 介绍 HQL:Hibernate Query Language HQL 的语法:就是将原来的sql 语句中的表与字段名称换成对象与属性的名称 接口类 List<Users

    3.4K20
    领券