主页 / dba / 问题

问题[c](dba)

Martin Hope
machineghost
Asked: 2025-04-09 02:14:35 +0800 CST
  • 5

我正在尝试在一台新的（Linux Mint）电脑上安装 PostgreSQL。一切正常，直到我尝试访问数据库。当我以自己的用户身份访问数据库时，出现了以下（预期的）错误：

$ psql 
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "me" does not exist

这很合理，因为 Linux 上有一个单独的postgres用户拥有数据库访问权限。我尝试使用它们：

$ sudo su postgres
[sudo] password for me:
$ psql
Password for user postgres:  psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: fe_sendauth: no password supplied

这时我有点困惑：postgres用户应该可以无密码访问所有 PostgreSQL 数据库。此外，我尝试设置pg_hba.conf文件以允许所有用户本地访问：

# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

但是，即使在我重新启动 PostgreSQL （使用/etc/init.d/postgresql reload）之后，系统仍然提示我输入用户的数据库密码postgres。

谁能帮助我理解：

  1. postgres当我尝试以用户身份（全新安装）访问数据库时，为什么会提示我输入密码？
  2. 为什么即使将 IPv4/IPv6 本地连接设置为 后仍然会收到提示trust？
  3. 我怎样才能使我的postgres用户像其他 Linux 系统一样（即没有任何数据库密码，但仍然能够访问所有数据库）
postgresql
Martin Hope
Dolphin
Asked: 2025-04-08 18:14:48 +0800 CST
  • 6

我想在 PostgreSQL 选择块中选择多行。然后我尝试使用 row 函数在 PostgreSQL 15 中执行查询，如下所示：

select c.a from ( select row(1 as a, 2 as b) as c)

显示错误ERROR: syntax error at or near "as，我也尝试过：

select (c).a from ( select row(1 , 2 ) as c(a,b))

我是不是漏掉了什么？或者如何获取行值？我发现这个方法很好用：

select * from ( select row(1 , 2 ) ) a

如何得到 1 或 2？我试过：

select a[0] from ( select row(1 , 2 ) ) a

似乎没有起作用。

postgresql
Martin Hope
ErikEV
Asked: 2025-04-08 07:59:48 +0800 CST
  • 9

介绍

我读过很多关于从数据库中删除数据以及使用 shrink 命令的风险的文章。但是，我有机会将数据库迁移到一台停机时间较长的新服务器，因此我打算重置数据库并缩减其大小（以提高性能并节省托管环境中的成本）。

背景

  • 现有的SQL Server是2016Web版。
  • 新的 SQL Server 2022 标准版。
  • 数据库大小~120GB。
  • 一些大表以及这些大表上的索引构成了其中的大部分。
  • 我只想专注于数据库大小的缩减。对于创建新服务器的其他部分，我感觉还算满意。

拟议流程

停电前

  1. 运行使用语法的存储过程DELETE FROM。我已经仔细测试过了。它们会批量删除，并且会在几天内运行。
  2. 监视日志文件和日志磁盘以仔细检查是否有足够的空间。
  3. 确保在到达停机时间时删除处理已经完成。

停电期间

  1. 对数据库进行完整备份并放在安全的地方。
  2. 删除最大的索引（我将针对大约 3 或 4 个）。
  3. 将数据库置于简单恢复模式。
  4. 尽可能缩小日志和数据库文件。
  5. 备份数据库。
  6. 将备份文件复制到新服务器。
  7. 将数据库还原到正确的文件位置
  8. 应用已删除的索引。
  9. 重建所有索引。
  10. 更新统计数据。
  11. 将数据库恢复到完整恢复模式。
  12. 测试和重启应用程序
sql-server
Martin Hope
raphael
Asked: 2025-04-08 02:17:40 +0800 CST
  • 5

我们正在尝试根据最近的地理距离将事件与线路进行匹配

--pseudo code
LATERAL JOIN (
    SELECT line_id, geom 
    FROM lines 
    ORDER by distance(lines.geom, events.geom) 
    LIMIT 1) nearest_line

有时，值得注意的是，会出现平局。我们希望确保如果使用相同的数据集再次运行我们的 ETL 管道，返回的结果会相同。一个想法是将其包含line_id在 中ORDER BY，但这可能会使我们的匹配结果偏向更低的line_id。如果我们的 ETL 必须在相同的数据集上重新运行，有没有办法随机打破平局，从而产生相同的输出？

我正在考虑类似的方法，但要根据和 的random()组合来设置种子。像在 ID 上使用 这样的方法可以吗？event_idline_idmod()

postgresql
Martin Hope
Jukurrpa
Asked: 2025-04-07 23:16:01 +0800 CST
  • 5

在两个仅行数不同的表（约 7.8M vs 约 1.4M）上运行相同的查询，会得到两个不同的计划，这听起来很合理。但是在较小的表上执行速度要慢 4 到 5 倍，我想知道原因。

表格定义如下：

   Column   |           Type           | Collation | Nullable | Default 
------------+--------------------------+-----------+----------+---------
 image_id   | bigint                   |           | not null | 
 h3_cell    | h3index                  |           | not null | 
 created_at | timestamp with time zone |           | not null | 
 location   | geometry(PointZ,4326)    |           | not null | 
Indexes:
    "images_a_pkey" PRIMARY KEY, btree (image_id)
    "images_a_created_at_idx" btree (created_at)
    "images_a_h3_cell_idx" btree (h3_cell)

查询如下

h3_cells AS (
    SELECT UNNEST(h3_linestring_to_cells(:line_string, 13, 1)) AS cell
)
SELECT COUNT(*)
FROM images
JOIN h3_cells hc ON images.h3_cell = hc.cell

该h3_linestring_to_cells()函数返回一个数组，h3index其大小在某些情况下可能高达数万个值。在下面的示例中，它返回的值约为 50,000 个。

在具有 7.8M 行的表中，计划和执行条目如下（为简洁起见，删除了数组值）：

Aggregate  (cost=347404.47..347404.48 rows=1 width=8) (actual time=74.311..74.312 rows=1 loops=1)
  Buffers: shared hit=154681 read=328
  I/O Timings: shared read=1.362
  ->  Nested Loop  (cost=0.43..346724.23 rows=272093 width=0) (actual time=0.051..74.246 rows=833 loops=1)
        Buffers: shared hit=154681 read=328
        I/O Timings: shared read=1.362
        ->  ProjectSet  (cost=0.00..256.90 rows=51377 width=8) (actual time=0.002..4.113 rows=51377 loops=1)
              ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.000..0.001 rows=1 loops=1)
        ->  Index Only Scan using images_a_h3_cell_idx on images_a  (cost=0.43..6.68 rows=5 width=8) (actual time=0.001..0.001 rows=0 loops=51377)
              Index Cond: (h3_cell = (unnest('{...}'::h3index[])))
              Heap Fetches: 354
              Buffers: shared hit=154681 read=328
              I/O Timings: shared read=1.362
Planning Time: 139.421 ms
Execution Time: 74.345 ms

而在较小的 1.4M 行表上，计划和执行如下：

Aggregate  (cost=105040.78..105040.79 rows=1 width=8) (actual time=327.586..327.587 rows=1 loops=1)
  Buffers: shared hit=148358 read=6315 written=41
  I/O Timings: shared read=26.521 write=0.327
  ->  Merge Join  (cost=4791.05..104802.14 rows=95455 width=0) (actual time=321.174..327.575 rows=118 loops=1)
        Merge Cond: (ptilmi.h3_cell = (unnest('{...}'::h3index[])))
        Buffers: shared hit=148358 read=6315 written=41
        I/O Timings: shared read=26.521 write=0.327
        ->  Index Only Scan using images_b_h3_cell_idx on images_b ptilmi  (cost=0.43..95041.10 rows=1415438 width=8) (actual time=0.026..245.897 rows=964987 loops=1)
              Heap Fetches: 469832
              Buffers: shared hit=148358 read=6315 written=41
              I/O Timings: shared read=26.521 write=0.327
        ->  Sort  (cost=4790.62..4919.07 rows=51377 width=8) (actual time=11.181..13.551 rows=51390 loops=1)
              Sort Key: (unnest('{...}'::h3index[]))
              Sort Method: quicksort  Memory: 1537kB
              ->  ProjectSet  (cost=0.00..256.90 rows=51377 width=8) (actual time=0.002..3.716 rows=51377 loops=1)
                    ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.000..0.001 rows=1 loops=1)
Planning Time: 146.617 ms
Execution Time: 327.626 ms

对于较小的源数组（例如大小为 25,000），较小表上的计划更改为第一个（嵌套循环），并且其执行时间变得更符合预期（比较大的表更快）。

我不明白是什么促使计划改变为效率更低的计划。

请注意，我使用的是 CTE+JOIN 而不是 eg WHERE h3_cell = ANY(h3_linestring_to_cells(:line_string, 13, 1))，因为生成的数组通常很大，而且我发现在这种情况下前者通常更高效。有趣的是，对于包含 50,000 个条目的数组，这种= ANY()方法在较小的表上速度更快，而对于包含 25,000 个条目的数组，这种方法速度较慢。

postgresql
Martin Hope
BotskoNet
Asked: 2025-04-07 13:32:09 +0800 CST
  • 6

我需要一个查询，可以针对用户的 Postgres 数据库运行，并确定他们是否有权创建过程/函数？它只需要一个查询，因为这是我分发的软件的启动检查，用户会将其连接到他们自己的数据库，这些数据库有时是共享的，而他们没有过程权限。

我需要一种仅使用 SQL 的方法来判断他们是否能够使用CREATE FUNCTION。文档中指出：

为了能够创建函数，您必须对参数类型和返回类型具有 USAGE 权限。

我尝试使用这个 SQL，但我不确定它是否有用”

SELECT * FROM information_schema.role_usage_grants 
WHERE grantee = 'postgres';

postgres    postgres    prism_v4    information_schema  cardinal_number DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  character_data  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  sql_identifier  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  time_stamp  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  yes_or_no   DOMAIN  USAGE   YES

在 MySQL 中我可以使用SHOW GRANTS FOR CURRENT_USER();并检查CREATE_ROUTINE

postgresql
Martin Hope
Alex
Asked: 2025-04-06 16:45:49 +0800 CST
  • 7

我有一堆属性（数据库中的列），它们应该具有来自预定义值列表的字符串值，例如active，，inactive。pending

在数据库之外，即 javascript（前端是 deno+react），我真的希望将它们作为字符串枚举，而不是整数，因为它增加了代码的清晰度，并实际上减少了需要编写的代码量。

在数据库中我有两个选项，要么按原样存储它们（字符串），要么smallint在数据库选择/插入期间将它们转换为字符串/从字符串转换。

第二种选择的问题在于它需要在代码中进行额外的转换，而当使用 typescript 时，这种转换并不像简单的映射那么简单，因为 ts 不允许你将不同的类型重新分配给现有的 props，所以你需要复制并做更多的事情……

无论如何，我只是想问一下，如果我将它们也直接作为字符串存储在数据库中以消除转换步骤，postgres 的性能和/或大小开销是多少？我想象如果我从更改为，每条记录将增加大约 20 个字节，smallint这text会对性能产生某种影响吗？此外，这些列必须被索引，这会为每条记录增加另外 20 个字节

postgresql
Martin Hope
Joel
Asked: 2025-04-05 05:01:50 +0800 CST
  • 6

我的数据库中的所有表和列都使用 utf8mb4 字符集和 utf8mb4_unicode_ci 排序规则。我想迁移到 utf8mb4_0900_ai_ci 排序规则，但convert to在我的大型表中使用 utf8mb4_0900_ai_ci 排序规则是不允许的，除非我使用 gh-ost 或 pt-osc。

我觉得这convert to应该没有必要，因为字符集没有变化，但我找不到任何文档来证实或否认这一点。convert to在这种情况下我需要使用吗？还是就alter table ... modify col ... collate ...足够了？

我查看了“使用转换为字符集来仅更改排序规则？”这个问题，它提出了一个非常类似的问题，但由于这个问题的年代久远，答案有些过时了。即便如此，一个答案似乎暗示这convert to是不必要的。另一个答案深入探讨了字符集转换以及如何使用 pt-osc，而我希望避免这种情况。

mysql
Martin Hope
Daylon Hunt
Asked: 2025-04-05 02:56:29 +0800 CST
  • 7

我有两个不同的查询，需要将它们合并在一起，然后将每个费率类型组聚合到最终表中。对于每个费率组（Rate_001mo、Rate_003mo 等）

SELECT EffectiveDate, 
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR012M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR024M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR036M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
FROM dbo.STAGING_FhlbRates WHERE EffectiveDate = '20250131'
group by EffectiveDate

UNION

SELECT EffectiveDate,
    SUM(CASE WHEN RateName = 'USOSFRA' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
    SUM(CASE WHEN RateName = 'USOSFRC' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
    SUM(CASE WHEN RateName = 'USOSFRF' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
    SUM(CASE WHEN RateName = 'USOSFR1' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
    SUM(CASE WHEN RateName = 'USOSFR2' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
    SUM(CASE WHEN RateName = 'USOSFR3' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
    FROM dbo.STAGING_SofrOisRates WHERE EffectiveDate = '20250131'
    GROUP BY EffectiveDate

最终结果表的列应包括生效日期，然后是每个费率组（Rate_001mo、Rate_003mo 等）

aggregate
Martin Hope
Tomek Stankowski
Asked: 2025-04-05 01:07:06 +0800 CST
  • 7

我在 10.6.21-MariaDB-ubu2004 中遇到了死锁。我的架构如下：

CREATE TABLE INT_CHANNEL_MESSAGE
(
    MESSAGE_ID       CHAR(36)     NOT NULL,
    GROUP_KEY        CHAR(36)     NOT NULL,
    CREATED_DATE     BIGINT       NOT NULL,
    MESSAGE_PRIORITY BIGINT,
    MESSAGE_SEQUENCE BIGINT       NOT NULL AUTO_INCREMENT UNIQUE,
    MESSAGE_BYTES    BLOB,
    REGION           VARCHAR(100) NOT NULL,
    PRIMARY KEY (REGION, GROUP_KEY, CREATED_DATE, MESSAGE_SEQUENCE)
) ENGINE = InnoDB;

CREATE INDEX INT_CHANNEL_MSG_DELETE_IDX ON INT_CHANNEL_MESSAGE (REGION, GROUP_KEY, MESSAGE_ID);

最初，表中只有一行。假设每行的值都是唯一的、唯一的REGION并且GROUP_KEY是固定的。

INSERT事务＃1使用单独的语句插入两行：

INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)

首先执行插入操作，然后事务挂起。事务 1 的隔离级别为REPEATABLE_READ（尽管已尝试更改为READ_COMMITED）。

事务 #2 在事务 #1 的第一次插入操作执行后立即启动（由应用程序触发）。隔离级别设置为READ_COMMITED。选择初始行进行更新，然后事务在DELETE调用时挂起：

    SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED

DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?

SHOW ENGINE INNODB STATUS输出：

| InnoDB |      | 
=====================================
2025-04-04 16:06:44 0x7fc6241b3700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 21 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 0 srv_active, 0 srv_shutdown, 2376 srv_idle
srv_master_thread log flush and writes: 2376
----------
SEMAPHORES
----------
------------
TRANSACTIONS
------------
Trx id counter 1646
Purge done for trx's n:o < 1646 undo n:o < 0 state: running
History list length 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 1643, ACTIVE 31 sec
2 lock struct(s), heap size 1128, 1 row lock(s), undo log entries 1
MariaDB thread id 76, OS thread handle 140489014748928, query id 8535 172.21.0.1 nbs 
---TRANSACTION 1640, ACTIVE 31 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1
MariaDB thread id 75, OS thread handle 140488995890944, query id 8537 172.21.0.1 nbs Updating
SET STATEMENT SQL_SELECT_LIMIT=1 FOR DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID='ce0ce618-2430-0b4c-727b-7250e5388f15' and GROUP_KEY='cb18446f-633c-3a46-b5ac-95ab539126d1' and REGION='DEFAULT'
------- TRX HAS BEEN WAITING 31293172 us FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 3 n bits 320 index PRIMARY of table `nbs_biometric`.`INT_CHANNEL_MESSAGE` trx id 1640 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 7; hex 44454641554c54; asc DEFAULT;;
 1: len 30; hex 63623138343436662d363333632d336134362d623561632d393561623533; asc cb18446f-633c-3a46-b5ac-95ab53; (total 36 bytes);
 2: len 8; hex 80000196018d82b2; asc         ;;
 3: len 8; hex 8000000000000012; asc         ;;
 4: len 6; hex 00000000066b; asc      k;;
 5: len 7; hex bf000001410110; asc     A  ;;
 6: len 30; hex 63623533326436662d343362352d393164352d636561612d623965616434; asc cb532d6f-43b5-91d5-ceaa-b9ead4; (total 36 bytes);
 7: SQL NULL;
 8: len 30; hex aced0005737200346f72672e737072696e676672616d65776f726b2e6d65; asc     sr 4org.springframework.me; (total 1252 bytes);

------------------
---TRANSACTION (0x7fc6388d7180), not started
0 lock struct(s), heap size 1128, 0 row lock(s)
--------
FILE I/O
--------
Pending flushes (fsync) log: 0; buffer pool: 0
166 OS file reads, 332 OS file writes, 594 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 891776
Log flushed up to   891776
Pages flushed up to 42676
Last checkpoint at  42664
0 pending log flushes, 0 pending chkp writes
334 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 167772160
Dictionary memory allocated 931712
Buffer pool size   8112
Free buffers       7349
Database pages     763
Old database pages 261
Modified db pages  621
Percent of dirty pages(LRU & free pages): 7.654
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 0, flush list 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 152, created 611, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 763, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 read views open inside InnoDB
Process ID=0, Main thread ID=0, state: sleeping
Number of rows inserted 63, updated 0, deleted 18, read 1182
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
 |

当事务 #1 插入单行时，不会发生死锁。我该如何避免这种情况？

我附加了应用程序日志以供更广泛的了解：

2025-04-04 18:06:13,426 [tx1]: TX START
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL update
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL query
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL statement [   SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED]
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL update
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL statement [DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?]
2025-04-04 18:07:03,430  [tx2]: Error: 1205-HY000: Lock wait timeout exceeded; try restarting transaction
2025-04-04 18:07:03,432 [tx2]: Extracted SQL state class 'HY' from value 'HY000'
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL update
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:07:03,435 [tx2]: Resetting isolation level of JDBC Connection [HikariProxyConnection@1449683964 wrapping org.mariadb.jdbc.Connection@5b1420f9] to 4
2025-04-04 18:07:03,436  [tx1]: TX END
mariadb