Why "INSERT ... ON CONFLICT DO NOTHING/UPDATE" Good for performance

最新推荐文章于 2024-05-30 17:35:37 发布
最新推荐文章于 2024-05-30 17:35:37 发布
阅读量2.2k 收藏 2
点赞数
分类专栏： 转载 文章标签： postgresql 性能优化 数据库 性能

Postgres2015全国用户大会将于11月20至21日在北京丽亭华苑酒店召开。本次大会嘉宾阵容强大，国内顶级PostgreSQL数据库专家将悉数到场，并特邀欧洲、俄罗斯、日本、美国等国家和地区的数据库方面专家助阵:

  • Postgres-XC项目的发起人铃木市一(SUZUKI Koichi)
  • Postgres-XL的项目发起人Mason Sharp
  • pgpool的作者石井达夫(Tatsuo Ishii)
  • PG-Strom的作者海外浩平(Kaigai Kohei)
  • Greenplum研发总监姚延栋
  • 周正中(德哥), PostgreSQL中国用户会创始人之一
  • 汪洋，平安科技数据库技术部经理
  • ……
 
  • 2015年度PG大象会报名地址：http://postgres2015.eventdove.com/
  • PostgreSQL中国社区： http://postgres.cn/
  • PostgreSQL专业1群： 3336901（已满）
  • PostgreSQL专业2群： 100910388
  • PostgreSQL专业3群： 150657323


PostgreSQL 9.5 新增了存在则更新或啥也不干的原子操作。
这个特性有什么好处呢？
如果你的应用程序不做保护，直接插入，可能会导致大量的违反唯一约束的错误，这种错误除了会写数据库日志，还会带来一定的问题。
例子： 

   
   

    
    

     
     postgres=# create table uk_test(id int primary key,info text,crt_time timestamp);
    
    

    
    

     
     CREATE TABLE
    
    

   
   

   
   

    
    

     
     postgres=# insert into uk_test values (1,'test',now());
    
    

    
    

     
     INSERT 0 1
下面插入几个违反唯一约束的报错。 

   
   

    
    postgres=# insert into uk_test values (1,'test',now());
   
   

   
   

    
    ERROR:  duplicate key value violates unique constraint "uk_test_pkey"
   
   

   
   

    
    DETAIL:  Key (id)=(1) already exists.
   
   

   
   

    
    postgres=# insert into uk_test values (1,'test',now());
   
   

   
   

    
    ERROR:  duplicate key value violates unique constraint "uk_test_pkey"
   
   

   
   

    
    DETAIL:  Key (id)=(1) already exists.
   
   

   
   

    
    postgres=# insert into uk_test values (1,'test',now());
   
   

   
   

    
    ERROR:  duplicate key value violates unique constraint "uk_test_pkey"
   
   

   
   

    
    DETAIL:  Key (id)=(1) already exists.
以上操作实际上已经形成了HEAP tuple，但是没有形成index linepoint，同时在clog中标记为事务失败。
这些其实是有负面影响的，
1. 消耗了事务号，我们知道事务号是一个UINT32的整型，每20亿必须做一次frozen。所以这种回滚事务实际上是浪费事务号的。
2. 浪费XLOG空间，虽然事务回滚了，但是同样形成了块的变更，在XLOG中也是有记录的。
3. 浪费了空间，同时还需要垃圾回收进程来回收它。
看看ctid就明白了。 

   
   

    
    postgres=# insert into uk_test values (2,'test',now());
   
   

   
   

    
    INSERT 0 1
   
   

   
   

    
    postgres=# select ctid,* from uk_test ;
   
   

   
   

    
     ctid  | id | info |          crt_time          
   
   

   
   

    
    -------+----+------+----------------------------
   
   

   
   

    
     (0,1) |  1 | test | 2015-06-23 15:00:33.452243
   
   

   
   

    
     (0,5) |  2 | test | 2015-06-23 15:00:37.431145
   
   

   
   

    
    (2 rows)

使用on conflict ... do nothing;可以有效的避免垃圾的产生： 

   
   

    
    postgres=# truncate uk_test ;
   
   

   
   

    
    TRUNCATE TABLE
   
   

   
   

    
    postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do nothing;
   
   

   
   

    
    INSERT 0 1
   
   

   
   

    
    postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do nothing;
   
   

   
   

    
    INSERT 0 0
   
   

   
   

    
    postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do nothing;
   
   

   
   

    
    INSERT 0 0
   
   

   
   

    
    postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do nothing;
   
   

   
   

    
    INSERT 0 0
   
   

   
   

    
    postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do nothing;
   
   

   
   

    
    INSERT 0 0
   
   

   
   

    
    postgres=# insert into uk_test values (2,'test',now());
   
   

   
   

    
    INSERT 0 1
   
   

   
   

    
    postgres=# select ctid,* from uk_test ;
   
   

   
   

    
     ctid  | id |  info  |          crt_time          
   
   

   
   

    
    -------+----+--------+----------------------------
   
   

   
   

    
     (0,1) |  1 | digoal | 2015-06-23 15:00:59.137141
   
   

   
   

    
     (0,2) |  2 | test   | 2015-06-23 15:01:05.143134
   
   

   
   

    
    (2 rows)
从上面的ctid可以看到，没有产生任何垃圾。

使用on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;，提供了原子操作，减少了应用和数据库的交互，对性能提升也是非常明显的。
更新操作和普通的更新没有区别，产生新的版本。 

   
   

    
    

     
     postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;
    
    

    
    

     
     INSERT 0 1
    
    

    
    

     
     postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;
    
    

    
    

     
     INSERT 0 1
    
    

    
    

     
     postgres=# select ctid,* from uk_test ;
    
    

    
    

     
      ctid  | id |  info  |          crt_time          
    
    

    
    

     
     -------+----+--------+----------------------------
    
    

    
    

     
      (0,2) |  2 | test   | 2015-06-23 15:01:05.143134
    
    

    
    

     
      (0,4) |  1 | digoal | 2015-06-23 15:01:27.715183
    
    

    
    

     
     (2 rows)
    
    

    
    

     
     

    
    

    
    

     
     postgres=# insert into uk_test values (1,'digoal',now()) on conflict on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;
    
    

    
    

     
     INSERT 0 1
    
    

    
    

     
     postgres=# select ctid,* from uk_test ;
    
    

    
    

     
      ctid  | id |  info  |          crt_time          
    
    

    
    

     
     -------+----+--------+----------------------------
    
    

    
    

     
      (0,2) |  2 | test   | 2015-06-23 15:01:05.143134
    
    

    
    

     
      (0,5) |  1 | digoal | 2015-06-23 15:01:34.485177
    
    

    
    

     
     (2 rows)
    
    

   
   

   
   

    
    

   
   

   
   

    
    

     
     postgres=# update uk_test set info='new',crt_time=now() where id=1;
    
    

    
    

     
     UPDATE 1
    
    

    
    

     
     postgres=# select ctid,* from uk_test ;
    
    

    
    

     
      ctid  | id | info |          crt_time          
    
    

    
    

     
     -------+----+------+----------------------------
    
    

    
    

     
      (0,2) |  2 | test | 2015-06-23 15:01:05.143134
    
    

    
    

     
      (0,6) |  1 | new  | 2015-06-23 15:02:12.968176
    
    

    
    

     
     (2 rows)

性能测试对比：
传统的最靠谱的存在则更新，不存在则插入的方法： 

  
  

   
   

    
    postgres=# create or replace function ins_update (v_id int) returns void as $$
   
   

   
   

    
    declare
   
   

   
   

    
    begin
   
   

   
   

    
      perform 1 from uk_test where id=v_id limit 1;
   
   

   
   

    
      if found then
   
   

   
   

    
        update uk_test set info='test',crt_time=now() where id=v_id;
   
   

   
   

    
      else
   
   

   
   

    
        insert into uk_test values(v_id,'test',now());
   
   

   
   

    
      end if;
   
   

   
   

    
      exception when others then
   
   

   
   

    
        return;
   
   

   
   

    
    end;
   
   

   
   

    
    $$ language plpgsql;
   
   

   
   

    
    CREATE FUNCTION
   
   

  
  

  
  

   
   

  
  

  
  

   
   

  
  

  
  

   
   性能：
  
  

  
  

   
   

    
    postgres=# select pg_stat_reset_single_table_counters('uk_test'::regclass);
   
   

   
   

    
    postgres=# truncate uk_test ;
   
   

   
   

    
    postgres=# checkpoint;
   
   

  
  

  
  

   
   

  
  

  
  

   
   

    
    pg95@db-172-16-3-150-> vi test.sql
   
   

   
   

    
    \setrandom id 1 5000000
   
   

   
   

    
    select ins_update(:id);
   
   

  
  

  
  

   
   

  
  

  
  

   
   

    
    pg95@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -P 1 -c 32 -j 32 -T 60
   
   

   
   

    
    progress: 1.0 s, 44468.6 tps, lat 0.638 ms stddev 1.028
   
   

   
   

    
    progress: 2.0 s, 46454.6 tps, lat 0.687 ms stddev 1.078
   
   

   
   

    
    progress: 3.0 s, 46644.0 tps, lat 0.685 ms stddev 1.112
   
   

   
   

    
    progress: 4.0 s, 46005.8 tps, lat 0.693 ms stddev 1.116
   
   

   
   

    
    progress: 5.0 s, 45636.1 tps, lat 0.700 ms stddev 1.107
   
   

   
   

    
    progress: 6.0 s, 45518.6 tps, lat 0.701 ms stddev 1.117
   
   

   
   

    
    progress: 7.0 s, 45674.2 tps, lat 0.699 ms stddev 1.090
   
   

   
   

    
    progress: 8.0 s, 45288.2 tps, lat 0.705 ms stddev 1.150
   
   

   
   

    
    progress: 9.0 s, 45074.2 tps, lat 0.708 ms stddev 1.125
   
   

  
  

  
  

   
   ......
  
  

  
  

   
   

    
    progress: 56.0 s, 36654.9 tps, lat 0.871 ms stddev 1.590
   
   

   
   

    
    progress: 57.0 s, 36694.7 tps, lat 0.870 ms stddev 1.530
   
   

   
   

    
    progress: 58.0 s, 36511.4 tps, lat 0.875 ms stddev 1.577
   
   

   
   

    
    progress: 59.0 s, 37118.4 tps, lat 0.860 ms stddev 1.502
   
   

   
   

    
    progress: 60.0 s, 36207.2 tps, lat 0.880 ms stddev 1.556
   
   

   
   

    
    transaction type: Custom query
   
   

   
   

    
    scaling factor: 1
   
   

   
   

    
    query mode: prepared
   
   

   
   

    
    number of clients: 32
   
   

   
   

    
    number of threads: 32
   
   

   
   

    
    duration: 60 s
   
   

   
   

    
    number of transactions actually processed: 2456377
   
   

   
   

    
    latency average: 0.778 ms
   
   

   
   

    
    latency stddev: 1.327 ms
   
   

   
   

    
    tps = 40934.377749 (including connections establishing)
   
   

   
   

    
    tps = 41005.456116 (excluding connections establishing)
   
   

   
   

    
    statement latencies in milliseconds:
   
   

   
   

    
            -0.001878       \setrandom id 1 5000000
   
   

   
   

    
            0.775430        select ins_update(:id);
   
   

  
  

  
  

   
   

  
  

  
  

   
   

    
    postgres=# select * from pg_stat_all_tables where relname='uk_test';
   
   

   
   

    
    -[ RECORD 1 ]-------+------------------------------
   
   

   
   

    
    relid               | 16930
   
   

   
   

    
    schemaname          | public
   
   

   
   

    
    relname             | uk_test
   
   

   
   

    
    seq_scan            | 0
   
   

   
   

    
    seq_tup_read        | 0
   
   

   
   

    
    idx_scan            | 13841219
   
   

   
   

    
    idx_tup_fetch       | 3655255
   
   

   
   

    
    n_tup_ins           | 1941192
   
   

   
   

    
    n_tup_upd           | 515185
   
   

   
   

    
    n_tup_del           | 0
   
   

   
   

    
    n_tup_hot_upd       | 482125
   
   

   
   

    
    n_live_tup          | 1941184
   
   

   
   

    
    n_dead_tup          | 36686
   
   

   
   

    
    n_mod_since_analyze | 0
   
   

   
   

    
    last_vacuum         | 
   
   

   
   

    
    last_autovacuum     | 2015-06-23 16:03:39.271969+08
   
   

   
   

    
    last_analyze        | 
   
   

   
   

    
    last_autoanalyze    | 2015-06-23 16:04:38.928135+08
   
   

   
   

    
    vacuum_count        | 0
   
   

   
   

    
    autovacuum_count    | 1
   
   

   
   

    
    analyze_count       | 0
   
   

   
   

    
    autoanalyze_count   | 2

使用insert into ... on conflict ... update set ...
性能： 

  
  

   
   postgres=# select pg_stat_reset_single_table_counters('uk_test'::regclass);
  
  

  
  

   
   postgres=# truncate uk_test ;
  
  

  
  

   
   postgres=# checkpoint;
  
  

  
  

   
   

  
  

  
  

   
   

    
    pg95@db-172-16-3-150-> vi test.sql
   
   

   
   

    
    \setrandom id 1 5000000
   
   

   
   

    
    insert into uk_test values (:id,'test',now()) on conflict on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;
   
   

  
  

  
  

   
   

  
  

  
  

   
   

    
    

     
     pg95@db-172-16-3-150-> pgbench -M prepared -n -r -f ./test.sql -P 1 -c 32 -j 32 -T 60
    
    

    
    

     
     progress: 1.0 s, 62283.4 tps, lat 0.430 ms stddev 0.823
    
    

    
    

     
     progress: 2.0 s, 64971.9 tps, lat 0.490 ms stddev 0.969
    
    

    
    

     
     progress: 3.0 s, 65560.7 tps, lat 0.486 ms stddev 0.937
    
    

    
    

     
     progress: 4.0 s, 64161.9 tps, lat 0.496 ms stddev 0.956
    
    

    
    

     
     progress: 5.0 s, 64003.1 tps, lat 0.498 ms stddev 0.994
    
    

    
    

     
     progress: 6.0 s, 63739.1 tps, lat 0.499 ms stddev 1.007
    
    

    
    

     
     progress: 7.0 s, 62974.2 tps, lat 0.505 ms stddev 1.005
    
    

    
    

     
     progress: 8.0 s, 62266.2 tps, lat 0.512 ms stddev 1.006
    
    

   
   

   
   

    
    ......
   
   

   
   

    
    

     
     

      
      progress: 33.0 s, 53306.1 tps, lat 0.598 ms stddev 1.239
     
     

     
     

      
      progress: 34.0 s, 52924.6 tps, lat 0.602 ms stddev 1.275
     
     

     
     

      
      progress: 35.0 s, 52799.8 tps, lat 0.603 ms stddev 1.268
     
     

     
     

      
      progress: 36.0 s, 52527.6 tps, lat 0.607 ms stddev 1.264
     
     

     
     

      
      progress: 37.0 s, 51948.2 tps, lat 0.613 ms stddev 1.303
     
     

     
     

      
      progress: 38.0 s, 51547.3 tps, lat 0.618 ms stddev 1.330
     
     

     
     

      
      progress: 39.0 s, 50852.2 tps, lat 0.626 ms stddev 1.348
     
     

    
    

   
   

   
   

    
    ......
   
   

   
   

    
    

     
     

      
      progress: 57.0 s, 45127.5 tps, lat 0.707 ms stddev 1.614
     
     

     
     

      
      progress: 58.0 s, 44983.0 tps, lat 0.708 ms stddev 1.573
     
     

     
     

      
      progress: 59.0 s, 45179.3 tps, lat 0.706 ms stddev 1.585
     
     

     
     

      
      progress: 60.0 s, 45045.4 tps, lat 0.708 ms stddev 1.579
     
     

     
     

      
      随着数据重复率越来越高，更新越来越多，TPS呈现下降趋势。
     
     

     
     

      
      

     
     

     
     

      
      transaction type: Custom query
     
     

     
     

      
      scaling factor: 1
     
     

     
     

      
      query mode: prepared
     
     

     
     

      
      number of clients: 32
     
     

     
     

      
      number of threads: 32
     
     

     
     

      
      duration: 60 s
     
     

     
     

      
      number of transactions actually processed: 3237650
     
     

     
     

      
      latency average: 0.589 ms
     
     

     
     

      
      latency stddev: 1.264 ms
     
     

     
     

      
      tps = 53954.428043 (including connections establishing)
     
     

     
     

      
      tps = 54087.133269 (excluding connections establishing)
     
     

     
     

      
      statement latencies in milliseconds:
     
     

     
     

      
              -0.002449       \setrandom id 1 5000000
     
     

     
     

      
              0.586167        insert into uk_test values (:id,'test',now()) on conflict on constraint uk_test_pkey do update set info=excluded.info,crt_time=excluded.crt_time;
     
     

    
    

    
    

     
     

    
    

   
   

  
  

  
  

   
   

  
  

  
  

   
   

    
    postgres=# select * from pg_stat_all_tables where relname='uk_test';
   
   

   
   

    
    -[ RECORD 1 ]-------+------------------------------
   
   

   
   

    
    relid               | 16930
   
   

   
   

    
    schemaname          | public
   
   

   
   

    
    relname             | uk_test
   
   

   
   

    
    seq_scan            | 0
   
   

   
   

    
    seq_tup_read        | 0
   
   

   
   

    
    idx_scan            | 10869657
   
   

   
   

    
    idx_tup_fetch       | 2624947
   
   

   
   

    
    n_tup_ins           | 2383669
   
   

   
   

    
    n_tup_upd           | 853982
   
   

   
   

    
    n_tup_del           | 1
   
   

   
   

    
    n_tup_hot_upd       | 800533
   
   

   
   

    
    n_live_tup          | 2360714
   
   

   
   

    
    n_dead_tup          | 27022
   
   

   
   

    
    n_mod_since_analyze | 811433
   
   

   
   

    
    last_vacuum         | 
   
   

   
   

    
    last_autovacuum     | 2015-06-23 16:01:41.707076+08
   
   

   
   

    
    last_analyze        | 
   
   

   
   

    
    last_autoanalyze    | 2015-06-23 16:01:42.553299+08
   
   

   
   

    
    vacuum_count        | 0
   
   

   
   

    
    autovacuum_count    | 1
   
   

   
   

    
    analyze_count       | 0
   
   

   
   

    
    autoanalyze_count   | 1

可以看到性能提升是非常明显的。

[参考]
Postgresql中国用户会
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
PostgreSQL ON CONFLICT冲突时进行额外操作
一碗清深的博客
09-26 2765
使用ON CONFLICT需设置键，否则报错“没有匹配ON CONFLICT说明的唯一或者排除约束”。
PostgreSQL的upsert功能（on conflict do）的用法
旧尘夕的博客
02-23 6881
ON CONFLICT 只在 PostgreSQL 9.5 以上可用 PostgreSQL 的 upsert 功能就是当执行INSERT操作时，如果数据表中不存在对应的记录，PostgreSQL 执行插入操作；如果数据表中存在对应的记录，则执行更新操作。这就是为什么将其称为upsert（update or insert）的原因。 <update id="updatePersonInfo" paramterType="com.test.pojo.Person"> insert...
insert on conflict - 合并写 （消除不必要更新）
weixin_33935505的博客
05-06 2359
标签 PostgreSQL , 合并写 , insert on conflict , 不必要更新 背景 合并更新的应用非常广泛，存在则更新，不存在则写入。 但是在某些场景中，存在并不一定要更新，原因是新的内容可能和老的内容完全一致。这种更新操作是完全没有必要的。 因为PG是多版本的，更新会产生新的TUPLE版本，如果这种没必要的更新很多，只会给数据库...
PostgreSQL并发场景处理insert 主键、唯一索引冲突
最新发布
li6909096的博客
05-30 362
当尝试向表中插入数据时，如果已存在相同的主键或唯一约束，就会触发这个子句。在这种情况下，使用 ON CONFLICT DO NOTHING 会导致插入操作被忽略，并且不会插入任何数据，同时也不会报错。ON CONFLICT DO NOTHING 是一种在 PostgreSQL 中处理唯一约束冲突的方法，它允许你在插入数据时忽略冲突，而不会插入任何数据或报错。由于 ‘name’ 字段有唯一约束，并且已经存在一个名为 ‘Alice’ 的学生，因此这次插入操作会被忽略，并且表中的数据保持不变。
【PostgreSQL】PostgreSQL的upsert功能(insert on conflict do)的用法
fuyun6363的博客
07-08 3921
PostgreSQL 的 upsert 功能：当记录不存在时，执行插入；否则，进行更新。
postgresql|数据库|SQL语句冲突的解决
zsk_john的技术分享专用博客
10-30 1321
postgresql数据库是比较复杂的一个关系型数据库，而有些时候，即使是简单的插入更新操作也是有很多复杂的机制。 那么，什么是冲突？什么时候会遇到冲突（也就是冲突的常见场景）？如果有冲突我们应该怎么去解决？这些问题我想应该是在此文章中详细说明的。
upsert:测试脚本基准测试“INSERT...ON CONFLICT UPDATE”
07-03
插入测试用例 Peter Geoghegan - ..../main.sh 还可以执行更有针对性的压力测试，而不是使用“main.sh”在无限循环中运行所有通用测试。 例如： ./cardinality.sh 压力测试“torture.sh”主要具有历史意义
A climate of conflict.doc
02-20
A climate of conflict.doc
redhat 7.x的rpm包spec文件重建
11-05
安装rpm包的时候出现conflicts with file from package filesystem；即可使用rpmrebuild -pe {packbagname}.rpm；禁用报错的行。
Mysql中Insert into xxx on duplicate key update问题
09-11
例如，在PostgreSQL中，你可以使用`ON CONFLICT DO UPDATE`语句来达到相同的效果。 总的来说，`INSERT INTO ... ON DUPLICATE KEY UPDATE`提供了一种灵活且强大的方式来处理数据插入和更新，尤其适用于需要确保数据...
git-2.11.0.tar.gz
10-23
如果没有特殊需求，可以直接运行`./configure`。 4. **编译和安装**: 编译源代码并进行安装： ``` make sudo make install ``` `make`命令会使用GCC或其他C编译器编译源代码，而`sudo make install`将编译后...
金仓数据库KingbaseES 数据插入更新操作
arthemis_14的博客
05-30 1526
数据库使用过程中，经常会遇到一种场景：业务系统对数据进行dml操作，当数据库中数据不存在时，将数据做为新记录插入到表中，当数据库中数据存在时，对现有数据进行更新操作。下面介绍KingbaseES中对上述的业务场景的应对方式。
on conflict do update
小林子的博客
05-30 2698
相比于传统的INSERT和UPDATE两个步骤执行，使用ON CONFLICT DO UPDATE可以将这两个步骤合并为一个数据库操作，从而减少了通信和锁定的开销，提高了插入数据的性能。在PostgreSQL中，这个语句通常使用在INSERT INTO语句中，用于在插入新行时，如果遇到重复的键值，则执行UPDATE操作。此外，ON CONFLICT DO UPDATE也可能会引入一些复杂性，特别是针对涉及多个列的行和需要执行更复杂逻辑的更新操作的情况。
PostgreSQL upsert功能（on conflict do）插入更新
热门推荐
lixinkuan的博客
09-06 1万+
近期有一个需求，向一张数据库表插入数据，如果是新数据则执行插入动作，如果插入的字段和已有字段重复，则更新该行对应的部分字段 1. 创建测试表 create table meta_data ( id serial, user_id varchar(128) DEFAULT NULL, file_name varchar(1024) DEFAULT NULL, file_path varchar(1024) DEFAULT NULL,
PostgreSQL merge insert(insert into on conflict) ERRCODE_CARDINALITY_VIOLATION （Ensure that no rows ...
weixin_34242658的博客
10-05 3296
标签 PostgreSQL , insert into on conflict , merge insert 背景 使用insert into on conflict 合并插入，如果一条SQL语句中，对一个KEY（冲突键，或冲突约束）多次发生冲突时，会报错。 原因： * It is the user'...
org.postgresql.util.PSQLException: 错误: 没有匹配ON CONFLICT说明的唯一或者排除约束
freshman2020的博客
09-13 4641
org.postgresql.util.PSQLException: 错误: 没有匹配ON CONFLICT说明的唯一或者排除约束 pgSQL使用upsert进行插入或更新操作时，报错: 没有匹配ON CONFLICT说明的唯一或者排除约束。 由于进行操作的表包含4个主键，而在conflict中只设置了两个主键，导致报错: 没有匹配ON CONFLICT说明的唯一或者排除约束。 解决方法：将4个主键均包含其中，或者取消未包含的主键。 具体原因未深入研究，并不知晓。 ...
Postgresql:INSERT INTO ON CONSTRAINT pk_key_id do nothing
qq_40985985的博客
09-13 1203
一、Postgresql在插入数据有主键或者唯一键冲突时，可以不做任何操作，也可以update 1. do nothing INSERT INTO t_test(id,name) VALUES (10,‘Lily’) ON CONFLICT ON CONSTRAINT pk_test_id do nothing; 2. update INSERT INTO t_test(id,name) VALUES ( 104,‘赵六’ ) ON CONFLICT ON CONSTRAINT pk_test_i
Postgresql on conflict do update 设置当前值，原始值，当前值与原始值相加值
qq_40985985的博客
08-13 5119
**Postgresql插入时主键冲突会报错，可采取冲突不做任何处理或者进行更新——俩种方式避免报错；更新时可以保存新值，保存新值与旧值表达式。**
postgresql insert on conflict 不存在则插入，存在则更新
weixin_58494422的博客
05-23 692
postgresql insert on conflict 不存在则插入，存在则更新
Opengauss怎么使用 ON CONFLICT DO NOTHING
05-23
在Opengauss中，ON CONFLICT DO NOTHING用于在插入数据时处理重复键冲突。如果插入的数据违反了唯一性约束，那么可以使用ON CONFLICT DO NOTHING忽略这些重复数据而不是抛出错误。 下面是一个例子： ``` INSERT INTO my_table (id, name) VALUES (1, 'Alice') ON CONFLICT DO NOTHING; ``` 如果表my_table中已经存在id为1的记录，则该语句不会插入任何数据，也不会抛出错误。如果不存在，则插入一条新记录，id为1，name为'Alice'。 在使用ON CONFLICT DO NOTHING时，需要注意以下几点： 1. 只有在存在唯一性约束时才能使用ON CONFLICT DO NOTHING。 2. 如果想要在冲突发生时更新已有记录，可以使用ON CONFLICT DO UPDATE语句。 3. 在某些情况下，ON CONFLICT DO NOTHING可能会影响性能，因此应该根据具体情况进行选择。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值