# Sql语句过长报错、查询慢优化方案探索

原创 已于 2022-10-16 16:54:15 修改 · 6.2k 阅读 · 13 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
标签
#sql #数据库 #内存表 #临时表 #sql过长
于 2022-08-10 08:29:04 首次发布

Sql 过长查询报错、in过多、查询慢优化方案探索

目录

文章目录

背景描述

  • 当不能直接进行sql联表查询的时候，一些中间数据需要写到表中进行查询从而解决一些无法解决的问题

  • Sql中通过sql in or in 的方式拼接sql会导致sql长度过长，Sql执行报错。

  • 使用 in 查询效率较慢

select * from test where id in('1001','1002')  or id in('1001')
  • in的内容过长后，sql超过数据库对sql长度的设定后会报错

解决方案

方案1（内存中过滤）

  • in中的内容超过一定的阈值后，超过阈值数据的字段在内存中进行过滤，先查出其它条件符合的数据（sql不做分页查询 ），加载到内存中，最后进行内存分页
/**
  * 内存分页
  *
  * @param list     数据
  * @param pageNum  当前页
  * @param pageSize 分页条数
  * @return List
  */
public <T> List<T> pageOperateInMemory(List<T> list, Integer pageNum, Integer pageSize) {
    if (CollectionUtils.isEmpty(list)) {
        return Collections.emptyList();
    }
    // 根据当前页和分页条数 从总记录数中取数据
    return list.stream().skip((long) pageSize * (pageNum - 1)).limit(pageSize)
        .collect(Collectors.toList());
}
存在问题
  • 主表数据过大的时候，查询全部数据过慢

方案2 In 查询的内容写入固化表

  • 创建一张固化表保存In里面的数据，每次查询的时候先写表，再用这张表做关联查询
# 方式 1 子查询
select * from master_table x where col_one in(select code from table_temp y where x.col_one=y.code)
select * from test x where  exists (select id from test y where y.id=x.id  )
# 方式 2 inner join
select x.* from master_table x inner join  table_temp y on x.col_one = y.code
  • 一次查询完成后用id删除数据
固化表格式如下
  • table_temp
标识名称含义
idid一次查询生成的 uuid
code值in中的值
type类型类型
request_id查询id查询id
写多张固化表思路
  • 每次查询生成一个查询id
  • 创建多张固化表，每次查询随机hash到随机表进行写表
  • 使用多线程写表（存在问题见存在的问题描述）
存在问题
  • 本地测试15万数据写入空表5秒左右，当表中数据越来越多的时候，写入速度变慢
  • 使用多项成写表的时候，数据量比较大的时候，写表速度不是特别理想，在并发情况下数据库处理大量sql不是很理想、并且在写完表后还有后续查询逻辑，sql查询不是特别理想
  • 此种方法不推荐

方案2 改进使用 left join

  • 写固化表在使用 join方式比 in 子查询的方式快
  • 使用 in子查询在遇到分页的问题的时候会比较慢，推荐优先使用 join方式

方案3（精确查询条件）

  • sql拼接更加精确的条件，减少 in的查询范围

方案4 使用临时表

方案5 固化写表使用事务特性

  • 手动控制事务，写表之后事务不提交，等所有查询语句执行完成之后，回滚事务
  • 这种方案比较好，整体速度快

查询执行过程性能分析

  • table_temp 共有 15万

写表性能分析

写入固化表
单条插入
  • mybatis insert方式
private void insertOneByOne(List<TempDO> tempDOList) {
    StopWatch stopWatch = new StopWatch("task1");
    stopWatch.start();
    int i = 0;
    for (TempDO tempDO : tempDOList) {
        testMapper.insertSelective(tempDO);
        i++;
        if (i == 10000) {
            stopWatch.stop();
            logger.info(String.valueOf(stopWatch.getTotalTimeMillis()));
            i = 0;
        }
    }
}
// 10000 条 需要 4分29秒
  • jdbcTemplate方式
private void insertOneByOneJdbcExcute(List<TempDO> tempDOList) {
    String sql = "INSERT INTO table_temp_one (ID,VER,CODE,ORGCODE,NAME,SHORTNAME,VALIDTIME,INVALIDTIME,PARENTCODE,ORDINAL,CREATEUSER,CREATETIME,PARENTS) VALUES\n" +
        "\t (?,?,?,?,?,?,?,?,?,?,?,?,?);\n";
    List<Object[]> objectList = new ArrayList<>();
    for (TempDO tempDO : tempDOList) {
        Object[] object = {
            tempDO.getId(), tempDO.getVer(), tempDO.getCode(), tempDO.getOrgcode(), tempDO.getName(), tempDO.getShortname(), tempDO.getValidtime(), tempDO.getInvalidtime(),
            tempDO.getParentcode(), tempDO.getOrdinal(), tempDO.getCreateuser(), tempDO.getCreatetime(), tempDO.getParents()
        };
        objectList.add(object);
    }
    StopWatch stopWatch = new StopWatch("task1");
    stopWatch.start();
    int i = 0;
    for (Object[] objects : objectList) {
        jdbcTemplate.update(sql, objects);
        i++;
        if (i == 10000) {
            stopWatch.stop();
            logger.info(String.valueOf(stopWatch.getTotalTimeMillis()));
            i = 0;
        }
    }
}
// 10000 条 需要 4分 36秒
批处理
sql 多values
@Insert("<script>INSERT INTO table_temp\n" +
        "        (id,request_id,code,type)\n" +
        "        values\n" +
        "        <foreach collection=\"list\" item=\"item\" separator=\",\">\n" +
        "            (#{item.id}, #{item.requestId}, #{item.code}, #{item.type})\n" +
        "        </foreach></script>")
int insertBatch(TempDO tempDO);

写入 10000 条执行耗时：{}937
写入 10000 条执行耗时：{}734
写入 10000 条执行耗时：{}925
写入 10000 条执行耗时：{}1241
写入 10000 条执行耗时：{}959
写入 10000 条执行耗时：{}999
写入 10000 条执行耗时：{}701
写入 10000 条执行耗时：{}352
写入 10000 条执行耗时：{}582
写入 10000 条执行耗时：{}390
写入 10000 条执行耗时：{}527
写入 10000 条执行耗时：{}388
写入 10000 条执行耗时：{}357
写入 10000 条执行耗时：{}491
写入 10000 条执行耗时：{}300
写入 10000 条执行耗时：{}23
写入 150000 条执行耗时：{}9915
------------------------------------
写入 150000 条执行耗时：{}6206 
------------------------------------
写入 150000 条执行耗时：{}5658
写入 150000 条执行耗时：{}6674
写入 150000 条执行耗时：{}7744
手动提交事务
SqlSessionFactory sqlSessionFactory = ApplicationContextRegister.getBean(SqlSessionFactory.class);
SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH);
InsertTestMapper mapper = sqlSession.getMapper(InsertTestMapper.class);

List<List<TempDO>> lists = splitList(list, 10000);
StopWatch stopWatch = new StopWatch("totalTask");
stopWatch.start();
for (List<TempDO> tempDOList : lists) {
    StopWatch stopWatch1 = new StopWatch("task1");
    stopWatch1.start();
    mapper.insertBatch(tempDOList);
    stopWatch1.stop();
    System.out.println("写入 10000 条执行耗时：{}" + stopWatch1.getTotalTimeMillis());
}
sqlSession.commit();
stopWatch.stop();
System.out.println("写入 150000 条执行耗时：{}" + stopWatch.getTotalTimeMillis());

---------------------------------------------------------------
写入 10000 条执行耗时：{}159
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}139
写入 10000 条执行耗时：{}109
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}133
写入 10000 条执行耗时：{}107
写入 10000 条执行耗时：{}107
写入 10000 条执行耗时：{}107
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}107
写入 10000 条执行耗时：{}121
写入 10000 条执行耗时：{}0
写入 150000 条执行耗时：{}4734
---------------------------------------------------------------------
写入 10000 条执行耗时：{}130
写入 10000 条执行耗时：{}105
写入 10000 条执行耗时：{}105
写入 10000 条执行耗时：{}127
写入 10000 条执行耗时：{}135
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}105
写入 10000 条执行耗时：{}133
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}107
写入 10000 条执行耗时：{}111
写入 10000 条执行耗时：{}106
写入 10000 条执行耗时：{}159
写入 10000 条执行耗时：{}142
写入 10000 条执行耗时：{}138
写入 10000 条执行耗时：{}0
写入 150000 条执行耗时：{}6495
PreparedStatement executeBatch 方式
Connection connection = SpringContextUtils.getBean(JdbcTemplate.class).getDataSource().getConnection();
String sql = "insert into table_temp(id, request_id,code,type) VALUES (?,?,?,?)";
PreparedStatement ps = null;
try {
    ps = connection.prepareStatement(sql);
    // 取消自动提交
    connection.setAutoCommit(false);
    StopWatch stopWatch = new StopWatch("totalTask");
    stopWatch.start();
    for (int i = 1; i <= list.size(); i++) {
        TempDO tempDO = list.get(i - 1);
        ps.setObject(1, tempDO.getId());
        ps.setObject(2, tempDO.getRequestId());
        ps.setObject(3, tempDO.getCode());
        ps.setObject(4, tempDO.getType());
        ps.addBatch();
        if (i % 10000 == 0) {
            StopWatch stopWatch1 = new StopWatch("task1");
            stopWatch1.start();
            ps.executeBatch();
            ps.clearBatch();
            stopWatch1.stop();
            System.out.println("写入 10000 条执行耗时：{}" + stopWatch1.getTotalTimeMillis());
        }
    }
    ps.executeBatch();
    ps.clearBatch();
    connection.commit();//所有语句都执行完毕后才手动提交sql语句
    stopWatch.stop();
    System.out.println("写入 150000 条执行耗时：{}" + stopWatch.getTotalTimeMillis());
} catch (SQLException e) {
    e.printStackTrace();
} finally {
    connection.close();
}

写入 10000 条执行耗时：{}1696
写入 10000 条执行耗时：{}1423
写入 10000 条执行耗时：{}1192
写入 10000 条执行耗时：{}1273
写入 10000 条执行耗时：{}1203
写入 10000 条执行耗时：{}1445
写入 10000 条执行耗时：{}1226
写入 10000 条执行耗时：{}1298
写入 10000 条执行耗时：{}1666
写入 10000 条执行耗时：{}1251
写入 10000 条执行耗时：{}1190
写入 10000 条执行耗时：{}1364
写入 10000 条执行耗时：{}1263
写入 10000 条执行耗时：{}1191
写入 10000 条执行耗时：{}1682
写入 150000 条执行耗时：{}20753
--------------------------------------------------------------------
写入 10000 条执行耗时：{}1579
写入 10000 条执行耗时：{}1859
写入 10000 条执行耗时：{}1483
写入 10000 条执行耗时：{}1470
写入 10000 条执行耗时：{}1488
写入 10000 条执行耗时：{}1059
写入 10000 条执行耗时：{}1112
写入 10000 条执行耗时：{}1164
写入 10000 条执行耗时：{}1426
写入 10000 条执行耗时：{}1202
写入 10000 条执行耗时：{}1315
写入 10000 条执行耗时：{}1654
写入 10000 条执行耗时：{}1301
写入 10000 条执行耗时：{}1134
写入 10000 条执行耗时：{}1529
写入 150000 条执行耗时：{}21168
写临时表插入
  • 先创建临时表，在执行插入，使用完之后删除
多values方式
写入 10000 条执行耗时：{}1267
写入 10000 条执行耗时：{}440
写入 10000 条执行耗时：{}352
写入 10000 条执行耗时：{}524
写入 10000 条执行耗时：{}380
写入 10000 条执行耗时：{}306
写入 10000 条执行耗时：{}457
写入 10000 条执行耗时：{}303
写入 10000 条执行耗时：{}301
写入 10000 条执行耗时：{}804
写入 10000 条执行耗时：{}333
写入 10000 条执行耗时：{}297
写入 10000 条执行耗时：{}323
写入 10000 条执行耗时：{}325
写入 10000 条执行耗时：{}324
写入 150000 条执行耗时：{}6746
---------------------------------------------------------------
写入 10000 条执行耗时：{}372
写入 10000 条执行耗时：{}409
写入 10000 条执行耗时：{}302
写入 10000 条执行耗时：{}303
写入 10000 条执行耗时：{}302
写入 10000 条执行耗时：{}302
写入 10000 条执行耗时：{}370
写入 10000 条执行耗时：{}300
写入 10000 条执行耗时：{}724
写入 10000 条执行耗时：{}302
写入 10000 条执行耗时：{}299
写入 10000 条执行耗时：{}303
写入 10000 条执行耗时：{}299
写入 10000 条执行耗时：{}301
写入 10000 条执行耗时：{}301
写入 150000 条执行耗时：{}5196
手动提交数据
写入 10000 条执行耗时：{}379
写入 10000 条执行耗时：{}219
写入 10000 条执行耗时：{}174
写入 10000 条执行耗时：{}165
写入 10000 条执行耗时：{}162
写入 10000 条执行耗时：{}155
写入 10000 条执行耗时：{}227
写入 10000 条执行耗时：{}239
写入 10000 条执行耗时：{}163
写入 10000 条执行耗时：{}202
写入 10000 条执行耗时：{}157
写入 10000 条执行耗时：{}175
写入 10000 条执行耗时：{}166
写入 10000 条执行耗时：{}160
写入 10000 条执行耗时：{}169
写入 150000 条执行耗时：{}4348

查询Sql性能分析

  • 主表数据50万
  • 固化表（table_temp）数据50万
Sql in 子查询方式
  • 查询 2s之内
SELECT *
FROM MASTER_TABLE
WHERE  
 (MASTER_TABLE.CODE in (select code from table_temp))
使用 exist 过滤
  • 查询用时 3-4 s
SELECT *
FROM MASTER_TABLE 
WHERE  exists (
select code from table_temp y where MASTER_TABLE.CODE = y.code 
)
join 方式
  • 查询 2s之内
SELECT *
FROM MASTER_TABLE 
inner join table_temp x on MASTER_TABLE.CODE = x.code

性能分析结论

写表性能分析

  • 15万数据

  • 10000条一次比5000、1000条一次写入速度快

  • 固化表增加code索引后写入变慢

  • 手动提交事务比自动提交事务快

  • 固化表追加方式写的时候越往后越慢

1000条一次
  • 写入 150000 条执行耗时：9995
  • 写入 150000 条执行耗时：9924
10000条写一次
  • 固化表只有主键
比较项插入数据量固化表固化表（追加数据）临时表临时表（追加数据）
单条插入10000条4分29秒
多values方式插入自动提交事务15万3次平均6.624秒3次平均 7.313 秒3次（每次重新创建临时表）平均4.9秒越往后越慢
多values方式插入手动提交事务15万3次/6.15秒3次平均6.01秒3次（每次重新创建临时表）平均4秒3次（第一次创建临时表，后面两次追加）平均5.8秒
  • 固化表 code设置索引
比较项插入数据量固化表固化表（追加数据）
多values方式插入自动提交事务15万3次平均7.25秒3次平均 9.04 秒
多values方式插入手动提交事务15万3次/7.24秒3次平均9.43秒
5000条写一次
  • 固化表只有主键
插入数据量比较项固化表固化表（追加数据）
15万多values方式插入自动提交事务3次平均5.938秒：5606、6587、56213次平均 8.386 秒：7510、8408、9240
15万多values方式插入手动提交事务3次/6.050秒：5728、6762、56613次平均6.582秒：5661、6462、7625
  • 固化表 code设置索引
比较项插入数据量固化表固化表（追加数据）
多values方式插入自动提交事务15万3次平均7.839秒：7840、7662、80153次平均 9.15 秒：7373、9185、10921
多values方式插入手动提交事务15万3次/6.916秒：6427、7139、71663次平均9.276秒：6781、9278、11769

查询性能分析

  • 固化表 code增加索引后三种方式秒出

  • 固化表不加 code索引、join 方式查询最快

  • 固化表只有主键

比较项主表数据50万（固化表）数据45万
in 作为子查询2.584s、2.547s、2.546s
exist 查询5.72s、5.91s、5.94s
inner join 查询1.638s、1.661s、1.640s
  • 固化表 code设置索引
比较项主表数据50万（固化表）数据45万
in 作为子查询秒出
exist 查询秒出
inner join 查询秒出

总结

  • 使用固化表存储插入的时候使用批量手动提交事务的方式插入
  • sql 插入多 values方式速度比较快
  • sql查询使用 left join 比使用 in子查询的方式快很多
  • 使用数据库临时表是最好的方案

临时表、内存表、视图

数据库临时表

  • 临时表只在当前连接可见，当关闭连接时，Mysql会自动删除表并释放所有空间。

  • 外部临时表：通过CREATE TEMPORARY TABLE 创建的临时表，这种临时表称为外部临时表。这种临时表只对当前用户可见，当前会话结束的时候，该临时表会自动关闭。这种临时表的命名与非临时表可以同名（同名后非临时表将对当前会话不可见，直到临时表被删除）。

  • 内部临时表：内部临时表是一种特殊轻量级的临时表，用来进行性能优化。这种临时表会被MySQL自动创建并用来存储某些操作的中间结果。内部临时表在SQL语句的优化过程中扮演着非常重要的角色， MySQL中的很多操作都要依赖于内部临时表来进行优化。但是使用内部临时表需要创建表以及中间数据的存取代价，所以用户在写SQL语句的时候应该尽量的去避免使用临时表。

  • 如果超出了临时表的容量，临时表会转换成磁盘表

Mysql 使用临时表的情况
创建临时表
  • MySQL用于存储一些中间结果集的表，临时表只在当前连接可见，当关闭连接时，Mysql会自动删除表并释放所有空间。
# 创建 临时表语句
create temporary table tb_temporay(id varchar(36),name varchar(30),code varchar(30));
  • 查看sql元数据信息并没有这张表
    请添加图片描述
group by 语句
  • 先通过索引范围扫描得到需要的数据，然后将数据存入临时表，然后再进行排序和分组操作来完成 GROUP BY。
select count(*) from tb_data group by string1;

请添加图片描述

distinct
  • EXPLAIN 查看执行计划结果的 Extra 列中，如果包含 Using Temporary 就表示会用到临时表。
    请添加图片描述
临时表的应用
  • 当某一个SQL语句关联的表在2张及以上，并且和一些小表关联。可以采用将大表进行分拆并且得到比较小的结果集合存放在临时表中。
  • 程序执行过程中可能需要存放一些临时的数据，这些数据在整个程序的会话过程中都需要用的等等。
  • 临时表默认的是MyISAM,但是可以修改。
  • 可以把一些经常访问的数据放到临时表中，这样访问时会快一些,因为数据是在服务器内存中,另外每次查询的时候，数据库都需要生成一些临时数据在临时表里

数据库内存表

内存表介绍

  • 内存表的表结构建立在磁盘里面，数据放在内存里面；

  • 当MySQL断开当前连接后，临时表的表结构和表数据都没了，但内存表的表结构和表数据都存在；当MySQL服务重启之后，内存表的数据会丢失，但表结构依旧存。

创建内存表
  • 内存表与创建普通表一样，使用CREATE TABLE语句，但需要将存储引擎设置为：ENGINE = MEMORY
create  table tb_one (id varchar(36),name varchar(30),code varchar(30))ENGINE = MEMORY;
insert into tb_one(id,name,code) values('1','2','3')
内存表引用
  • 内存表使用哈希散列索引把数据保存在内存中，因此具有极快的速度，适合缓存中小型数据库。
  • 一旦服务器重启，所有内存表数据丢失，但是表结构仍然存在，因为表结构是存放在实际数据库路径下的，不会自动删除。重启之后，内存表将被清空，这时候对内存表的查询结果都是空的。

临时表和内存表区别

临时表内存表
存储表结构和数据都存储在内存中表结构存储在磁盘中，表数据存储在内存中
会话单个会话独享的，是会话级别的可以多个会话共享
引擎临时表默认，myisam内存表默认，memory
断开连接表结构和表数据都没了表结构和表数据都存在
服务重启表结构和表数据都没了表结构存在，表数据不存在
性能由于表数据都是存放在内存中，所以相对来说，查询速度较快，但是数据的维护较为困难

数据库视图

  • 视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。
  • 一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻辑意义上建立的新关系。
  • 视图适合于多表连接浏览时使用，不适合增、删、改。

临时表实战

使用临时表详情：https://blog.csdn.net/qq_37248504/article/details/127349776

解决奇葩业务场景in条件过多导致sql超长问题
wjs970410888的博客
09-13 1387
开发过程中遇到一个奇葩业务，in条件过多导致sql长度超过postgresql限制的最大参数字节，将long集合修改为数组类型，使用Join替代in条件查询得以解决。
MyBatis批量保存（Oracle）MyBatis批量插入、批量更新时，组装SQL过长会有问题，一定要根据批量插入数据量进行切割，再批次提交保存！！！
Be_insighted的博客
12-14 2412
Mybatis向Oracle中批量插入数据，MyBatis批量插入、更新时，组装SQL过长会有问题，一定要根据批量插入数据量进行切割，再批次提交保存！！！
Oracle ora-12733 正则表达式太长 regexp_like(字段名,'||||||||||||||||||')
guxu_com的博客
05-11 3959
regexp_like(字段名,’||||||||||||||||||’) 执行这个语句每个“|”，前后都有关键字，意思就是可以like这些关键字。但是今天写了一个特别长的语句，一直报错过不去。查了一下限额好像是512，小于那个数，可是就是过不去。一直报相同的错误，后来发现中间有重复的关键字，删除重复就过去了。也可能是我删除重复后就没有超过最大限额了。我的算上“|”有四百多个字符吧。 ...
分批调用函数，解决数据库SQL in超长问题
Machine的博客
12-04 3325
背景：在使用PG查询时，我们常常会用到in，当in的个数过多时，会发生一个语句超长的问题。 错误提示如下： An I/O error occurred while sending to the backend.、Tried to send an out-of-range integer as a 2-byte value: 39887 Caused by: org.postgresql.util.PSQLException: An I/O error occurred while sending to th
sql语句过长的问题
weixin_34296641的博客
09-18 1841
sql语句长度超过限制，一般有两种情况： 1.字段的值过长，比如新闻的内容等 解决办法： declareaclob:='超长值'; begin insertintoTABLE(字段名)values(a); end; 当然该字段要设成clob类型的 2.动态生成sql语句时整体超过长度限制，比如“ in （‘1’，‘2’，。。。，‘n’）”，当然不只是这一种情...
MySQL之慢 SQL 定位、性能优化实践
weixin_74412978的博客
01-07 1154
SQL语句优化，尽量精简，去除非必要语句索引优化，让所有SQL都能够走索引如果是表的瓶颈问题，则分表，单表数据量维持在2000W（理论上）以内如果是单库瓶颈问题，则分库，读写分离如果是物理机器性能问题，则分多个数据库节点。
Hive大分区表查询不带分区，查询慢
编程技术、独立开发、技术资讯以及编程感悟等内容
01-31 1004
Hive 大分区表查询不带分区，查询慢
SQL语句 in+集合过长的问题
lqf1533436335的博客
03-22 4760
解决SQL语句 in 集合过长的问题思路 – –
MySQL 慢查询堆积拖垮网站，怎么开启日志并优化索引语句？
最新发布
恒创科技Henghost
06-11 366
作为常年服务企业集群、香港服务器数据库运维的IDC服务商，我们遇到大量案例：单条SQL执行耗时几秒甚至十几秒，海量慢查询持续堆叠，占用数据库连接、磁盘IO、线程资源，直接拖垮全站动态加载能力。本文用轻松易懂、落地性极强的方式，完整讲解 MySQL慢查询日志开启、日志分析方法、执行计划解读、索引优化、SQL语句整改、长效防堆积方案，帮助运维和开发者彻底解决慢查询导致的网站卡顿、数据库过载问题，适配单机、集群、跨境服务器全场景。网站卡顿、接口超时、数据库负载异常，80%的隐性故障都源于MySQL慢查询堆积。
presto sql 报错_使用Presto SQL一些常见问题总结
weixin_39983404的博客
12-24 1402
查询速度慢, 如何优化?解决方法1: 避免单节点处理虽然Presto是分布式查询引擎, 但是一些操作是必须在单节点中处理的. 例如:count(distinct x)考虑使用approx_distinct(x)代替但是需要注意这个函数有个大约在2.3%的标准误差, 如果需要精确统计的情况, 请绕道.UNIONUNION有个功能是: 如果两条记录一样, 会只保留一条记录(去重).如果不考虑去重的情况...
oracle 正则表达式太长,Oracle正则表达式(REGEXP_LIKE)太长错误——ORA-12733。
weixin_33321522的博客
04-03 3071
I have to validate an IPv6 address in PL/SQL. I came up with the regular expression from here: Regular Expression (RegEx) for IPv6 Separate from IPv4我必须在PL/SQL中验证IPv6地址。我从这里得到了正则表达式:正则表达式(RegEx)与IPv4分...
​【香菇带你学Mysql】Mysql超长执行sql定位和优化【建议收藏】
cnzzs的博客
08-12 507
本文为MySQL数据库管理员和开发人员提供了一套全面的超时SQL定位和优化解决方案。通过合理运用这些方法和技巧，可以显著提升MySQL数据库的性能和稳定性，减少超时SQL语句的发生，确保数据库的高效运行。0. 引言最近某个Mysql数据库频繁告警，监控系统提醒有执行时间超长sql(基本上是执行时间超过1800秒)的语句。之...
mysql远程执行sql语句过长 包太大，出现提示“ERROR Got a packet bigger than XXXX”解决
chenhao0568的专栏
12-18 934
1024。
mysql超长sql查询_超长SQL怎么查询?MySQL列长度限制有哪些 | 学步园
weixin_39987138的博客
01-19 1992
MySQL字符串的限制长度看似重要性不要，其实和整个MySQL数据库的安全性是息息相关的，很值得我们去深入研究分析。SQL注入攻击一直都在被广泛的讨论，然而人们却忽略了今天我将要介绍的这两个安全隐患，那就是超长SQL查询和单列SQL字符长度限制可能会带来的问题。下面学步园小编来讲解下超长SQL怎么查询?MySQL列长度限制有哪些?超长SQL怎么查询max_packet_size这个东西是用来限制m...
oracle mybatis批量插入报sql语句过长
谨
12-28 3438
现象：在做读者信息导入的时候，导入的读者信息量有点大，结果sql报错，错误原因是执行的sql语句太长了。 原因：经断点跟踪代码，发现底层mybati xml中插入读者信息方法是个批量插入，采用union all 把所有的insert语句拼接成一个语句，然而因为导入的读者信息数据量过大，导致拼接的sql语句长度超过了6000个字符，导致报错。以下是网上查询资料结果： mybatis-oracle批量插入问题： 如上图所示：如果插入的数据量很大，union all后，sql语句都会非常的长，数据量
mybatis in查询条件过长的解决方法
abcafdsgr123456789的博客
08-14 759
mybatis in查询条件过长的解决方法
MySQL解决Too many connections报错：连接数爆满排查、优化与永久解决方案
ULIi096kr的博客
06-09 230
在MySQL线上运维中，Too many connections（连接数过多）是优先级最高的故障之一。一旦出现该报错，所有新的业务请求都无法连接数据库，直接导致接口全部瘫痪、用户无法访问、业务全面停摆。很多团队的常规应急操作是临时修改max_connections最大连接数，短暂恢复业务，但过一段时间后连接数再次打满，故障反复出现。连接泄露、空闲连接不释放、长事务阻塞、SQL卡死、连接配置不合理。
跨表OR导致SQL查询中断&慢查询优化（UNION ALL改造方案）
2301_81205080的博客
01-03 741
本文介绍了union all代替跨表or优化sql的方案
JAVA线上查询报错如何定位问题
weixin_39304656的博客
10-02 1432
定位 Java 应用系统的线上查询报错问题，通常需要从多个层面进行排查，包括日志分析、分布式追踪、数据库排查、系统资源监控、网络排查等。查看日志：分析应用程序的日志，尤其是异常堆栈和 SQL 查询相关日志。分布式追踪：通过分布式追踪工具查看跨服务调用链中的异常。数据库检查：查看数据库日志、执行 SQL 查询，分析是否有慢查询或连接池问题。系统资源监控：检查服务器的 CPU、内存、磁盘 I/O 以及 JVM 的 GC 状态。网络与依赖服务：检查网络延迟和依赖服务的可用性。调试与重现。
达梦数据库 SQL 错误 [22000]:列[xxx]长度超出定义——笔记
qq_39960204的博客
05-31 7765
今天碰到一个看表结构字段长度是够的；但是执行sql的时候报字段长度不够的问题；记录一下大概场景就是新增一条数据，在插入数据库的时候，一个varchar字段在报 SQL 错误 [22000]:列[xxx]长度超出定义把这个字段拿出来单独查 LENGTH() 函数，长度是在字段长度范围内的；后来大佬让查了一下 LENGTHB() 函数，发现长度是超出字段长度范围的；最后根据 这个长度重新设置了一下字段长度，就正常了；
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

全栈程序员

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值