PostgreSQL 字符集双重转义击穿 磁盘 I/O

背景与问题表现

某线上交易核心库（PostgreSQL 分区表架构）突发磁盘 I/O 告警，多条业务查询出现严重堆积。监控大盘显示存储层读吞吐与延迟急剧攀升，部分核心查询执行时间超过 1.5 小时（4,900s ~ 5,700s），应用连接池近乎耗尽。

登录数据库查看活跃会话视图：

SELECT pid, application_name, client_addr, state, wait_event_type, wait_event, state_change, query
FROM pg_stat_activity 
WHERE query LIKE '%SELECT listing_id FROM table_listing WHERE name_utf =%'
  AND pid <> pg_backend_pid()
ORDER BY state_change DESC;

抓取到异常连接特征如下：

   pid   |    application_name    |  state  | wait_event_type |  wait_event  | state_duration  |                                                  query                                                   
---------+------------------------+---------+-----------------+--------------+-----------------+----------------------------------------------------------------------------------------------------------
 2446286 | PostgreSQL JDBC Driver | active  | IO              | BufferIO     | 01:22:58.519826 | SELECT listing_id FROM table_listing WHERE name_utf = E'×\u0094×\u009C...' AND tld_id = 0 ORDER BY date_created DESC LIMIT 1
 2446257 | PostgreSQL JDBC Driver | active  | IO              | DataFileRead | 01:22:58.559502 | SELECT listing_id FROM table_listing WHERE name_utf = E'×\u0094×\u009C...' AND tld_id = 0 ORDER BY date_created DESC LIMIT 1
 2196392 | PostgreSQL JDBC Driver | active  | IO              | BufferIO     | 01:28:58.722631 | SELECT listing_id FROM table_listing WHERE name_utf = E'×\u0094×\u009C...' AND tld_id = 0 ORDER BY date_created DESC LIMIT 1

异常现场核心特征

1. 周期性堆积 ：每隔约 6 分钟由同一客户端机器打入一条查询，全部处于 active 状态。
2. 底层阻塞 ：等待事件全部集中在 DataFileRead（物理磁盘读）和 BufferIO（共享缓冲区读锁争用）。
3. 入参诡异 ：过滤条件带入了大量形如 E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094' 的异常转义串。

---

根因推导与执行计划解构

1. 执行计划对比实验

在 psql 控制台分别对乱码入参 与正常多语言入参执行计划分析：

场景 A：乱码入参（故障真实场景）

EXPLAIN (COSTS, BUFFERS) 
SELECT listing_id FROM table_listing 
WHERE name_utf = E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094' AND tld_id = 0 
ORDER BY date_created DESC LIMIT 1 OFFSET 0;

QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1.00..618412.10 rows=1 width=12)
   ->  Merge Append  (cost=1.00..7420934.15 rows=12 width=12)
         Sort Key: table_listing.date_created DESC
         ->  Index Scan Backward using active_listing_domain_datecre_regid_listid_idx on active_listing_domain table_listing_1
               Filter: ((name_utf = '×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094'::text) AND (tld_id = 0))
         ->  Index Scan Backward using inactive_listing_domain_datecre_regid_listid_idx on inactive_listing_domain table_listing_2
               Filter: ((name_utf = '×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094'::text) AND (tld_id = 0))

场景 B：正常字符入参（如希伯来文 הללויה）

EXPLAIN (COSTS, BUFFERS) 
SELECT listing_id FROM table_listing 
WHERE name_utf = E'הללויה' AND tld_id = 0 
ORDER BY date_created DESC LIMIT 1 OFFSET 0;

QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
 Limit  (cost=463.69..463.69 rows=1 width=12)
   ->  Sort  (cost=463.69..463.72 rows=12 width=12)
         Sort Key: table_listing.date_created DESC
         ->  Append  (cost=174.46..463.63 rows=12 width=12)
               ->  Bitmap Heap Scan on active_listing_domain
                     Recheck Cond: (name_utf = 'הללויה'::text)
                     ->  Bitmap Index Scan on active_listing_domain_name_utf_idx
               ->  Bitmap Heap Scan on inactive_listing_domain
                     Recheck Cond: (name_utf = 'הללויה'::text)
                     ->  Bitmap Index Scan on inactive_listing_domain_name_utf_idx

2. 优化器的致命"早停策略"陷阱

对比发现，两个入参的估算成本相差高达 16,000 倍（Cost 463 vs 7,420,934）：

• 正常字符 ：优化器在统计信息（MCV / 频率柱状图）中识别到该词频度，选择走 name_utf 字段的索引过滤出符合条件的少量记录，然后在内存中按 date_created 排序，毫秒级完成。
• 乱码字符 ：因为是数据库从未见过的生僻串，优化器预估满足 name_utf = 乱码 的数据量接近于 0。当它面对 ORDER BY date_created DESC LIMIT 1 时，基于代价模型做出了极端假设：

"直接顺着 date_created 倒序扫描索引，只要在回表时撞上第一条符合条件的记录，触发 LIMIT 1 就能立即早停退出，省掉整体物化与排序开销。"

灾难在此发生 ：全表中根本不存在 字面等于该乱码的记录。PostgreSQL 顺着时间索引将大表所有分区的所有历史冷数据从头到尾全部回表过滤了一遍。

3. 为什么是 DataFileRead 与 BufferIO？

• DataFileRead ：分区表数据量庞大，海量历史冷数据不在 shared_buffers 内存池内，进程被迫发起持续同步的物理磁盘 I/O。
• BufferIO：业务端定时调度不断发起相同的大查询，6 个进程同时顺着时间线对冷数据块发起物理读。当并发进程试图访问同一个正在由其他进程从磁盘加载的数据块时，会被挂入等待队列，引起严重的内存锁与 I/O 争用，最终单次查询执行时间被无限放大到 1.5 小时。

---

字符集取证：正推与逆推完整闭环

该乱码串通过 PostgreSQL 内置的编码转换函数可以直接完成正向模拟与逆向还原取证。

1. 正推证明：UTF-8 字节被 Latin-1 强制解析

希伯来语单词 הללויה（哈利路亚，IDN 域名常见测试词）在 UTF-8 下由 6 个希伯来字母组成，每个字母占用 2 个字节。将这串原始字节按 Latin-1 (ISO-8859-1) 逐字节还原：

SELECT 
    'הללויה' AS original_hebrew,
    
    -- 1. 查看希伯来文的原始 UTF-8 十六进制字节（每2个字节代表1个希伯来字母）
    encode(convert_to('הללויה', 'UTF8'), 'hex') AS utf8_hex,
    
    -- 2. 将这串 UTF-8 原始字节，强制按 Latin-1 (ISO-8859-1) 进行解码
    convert_from(convert_to('הללויה', 'UTF8'), 'LATIN1') AS mangled_result,
    
    -- 3. 对比：转换结果与数据库收到的乱码是否完全相等
    convert_from(convert_to('הללויה', 'UTF8'), 'LATIN1') = E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094' AS is_identical;

执行输出：

 original_hebrew |         utf8_hex         |                mangled_result                | is_identical 
-----------------+--------------------------+----------------------------------------------+--------------
 הללויה          | d794d79cd79cd795d799d794 | ×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094 | t
(1 row)

输出 is_identical = t，直接证实线上收到的乱码就是 Latin-1 错误解码产物。

---

2. 逐字节映射解析：还原每个字符的产生机制

使用 get_byte() 将底层 12 个字节展开成清晰的编码映射：

WITH raw_bytes AS (
    SELECT convert_to('הללויה', 'UTF8') AS b
)
SELECT 
    i + 1 AS byte_pos,
    '0x' || lpad(to_hex(get_byte(b, i)), 2, '0') AS hex_val,
    get_byte(b, i) AS dec_val,
    chr(get_byte(b, i)) AS latin1_char,
    CASE 
        WHEN get_byte(b, i) = 215 THEN '乘号 (×)'
        ELSE 'Unicode 控制符 (\u00' || to_hex(get_byte(b, i)) || ')'
    END AS char_meaning
FROM raw_bytes, generate_series(0, octet_length(b) - 1) AS i;

执行输出：

 byte_pos | hex_val | dec_val | latin1_char |        char_meaning        
----------+---------+---------+-------------+----------------------------
        1 | 0xd7    |     215 | ×           | 乘号 (×)
        2 | 0x94    |     148 | \u0094      | Unicode 控制符 (\u0094)
        3 | 0xd7    |     215 | ×           | 乘号 (×)
        4 | 0x9c    |     156 | \u009C      | Unicode 控制符 (\u009c)
        5 | 0xd7    |     215 | ×           | 乘号 (×)
        6 | 0x9c    |     156 | \u009C      | Unicode 控制符 (\u009c)
        7 | 0xd7    |     215 | ×           | 乘号 (×)
        8 | 0x95    |     149 | \u0095      | Unicode 控制符 (\u0095)
        9 | 0xd7    |     215 | ×           | 乘号 (×)
       10 | 0x99    |     153 | \u0099      | Unicode 控制符 (\u0099)
       11 | 0xd7    |     215 | ×           | 乘号 (×)
       12 | 0x94    |     148 | \u0094      | Unicode 控制符 (\u0094)
(12 rows)

• 高位字节全部为 0xD7（十进制 215） ：在 ISO-8859-1 (Latin-1) 字符集中，0xD7 对应可打印字符乘号 ×。
• 低位字节为 0x94, 0x9C, 0x95, 0x99**：落在 ISO-8859-1 的 C1 控制字符区（0x80~0x9F），被数据库客户端转义为 \u0094、 \u009C** 等。

---

3. 逆推证明：从乱码无损还原回希伯来文

通过将乱码字符串按 LATIN1 重新打包为底层字节流，再用 UTF8 重新反序列化，可无损逆向还原：

SELECT 
    -- 乱码输入
    E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094' AS mangled_input,

    -- 逆向恢复核心逻辑
    convert_from(
        convert_to(E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094', 'LATIN1'), 
        'UTF8'
    ) AS restored_hebrew,

    -- 验证是否与正确的希伯来文完全相等
    convert_from(
        convert_to(E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094', 'LATIN1'), 
        'UTF8'
    ) = 'הללויה' AS is_match;

执行输出：

               mangled_input                | restored_hebrew | is_match 
--------------------------------------------+-----------------+----------
 ×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094 | הללויה          | t
(1 row)

输出 is_match = t，正推与逆推形成完整技术证据链。

---

修复前 vs 修复后的全链路对比

【修复前（故障链路）】
外部输入/存储源（希伯来文: הללויה）
   │
   ▼ 字节流: 0xD7 0x94 0xD7 0x9C ... (UTF-8)
Java 读取 / 解析环节 ❌
   │
   ▼ 错误使用 ISO-8859-1 解码（单字节逐个对应）
内存中的 String 变成: "×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094" (12个字符)
   │
   ▼ JDBC 拼装 / 传参
数据库接收并执行: WHERE name_utf = E'×\u0094×\u009C×\u009C×\u0095×\u0099×\u0094' (不存在的字符)
   │
   ▼
结果: 触发 Index Scan Backward 倒序扫穿全表，耗时 1.5+ 小时，卡死数据库

────────────────────────────────────────────────────────────────────────

【修复后（正常链路）】
外部输入/存储源（希伯来文: הללויה）
   │
   ▼ 字节流: 0xD7 0x94 0xD7 0x9C ... (UTF-8)
Java 读取 / 解析环节 ✔ (显式指定 UTF-8)
   │
   ▼ 正确识别双字节 Unicode
内存中的 String 保持: "הללויה" (6个希伯来文字符)
   │
   ▼ JDBC PreparedStatement 参数绑定 (ps.setString(1, nameUtf))
数据库接收并执行: WHERE name_utf = 'הללויה'
   │
   ▼
结果: 精准命中 active_listing_domain_name_utf_idx 索引，毫秒级返回

---

DBA 治理与防御建议

从高可用与数据库稳定性出发，治理必须落实三层防线：

1. 紧急止损（会话清理）

释放当前被卡死的物理读会话，使磁盘 I/O 恢复基线：

SELECT pg_terminate_backend(pid) 
FROM pg_stat_activity 
WHERE application_name = 'PostgreSQL JDBC Driver'
  AND state = 'active'
  AND wait_event IN ('BufferIO', 'DataFileRead')
  AND query LIKE '%table_listing%';

2. 数据库级防御：复合索引兜底

优化器之所以能够选择走 date_created 的倒序索引，本质是因为缺乏一个能够"同时覆盖精准过滤与排序规则"的高效复合索引。

在核心分区表上并发建立联合索引：

CREATE INDEX CONCURRENTLY idx_active_listing_tld_name_date 
ON active_listing_domain (tld_id, name_utf, date_created DESC);

CREATE INDEX CONCURRENTLY idx_inactive_listing_tld_name_date 
ON inactive_listing_domain (tld_id, name_utf, date_created DESC);

收益：

• 当再次遇到任何不存在的词或乱码查询时，PostgreSQL 可以在 (tld_id, name_utf) 复合索引分支首层直接判定无数据，在 0.1 毫秒内直接返回空集。
• 彻底消除优化器在缺失过滤索引时退化为 Index Scan Backward 导致整表扫穿的风险。

3. 应用层代码治理

推动业务研发排查 Java 端多语言域名输入与处理链路：

1. 检查所有涉及 new String(bytes)、InputStreamReader 的调用，显式注入 StandardCharsets.UTF_8。
2. 检查应用层与外部系统（消息队列、第三方 API、导入文件）交互的字符集声明，杜绝将多字节 UTF-8 输入当做单字节 ISO-8859-1 解码。
3. 检查 JDBC 连接串参数，明确配置 characterEncoding=UTF-8 与 stringtype=unspecified。