支付系统 ES 实战案例：从索引创建到真实业务查询

在支付系统中，MySQL 负责核心事务与资金存储，但客服查单、运营对账、流水检索、异常排查这类灵活、模糊、多条件、大分页的查询场景，MySQL 完全扛不住。

所以行业统一方案：MySQL存真实数据，ES做所有检索查询。

本文带你从零落地一个生产级支付流水 ES 案例：

支付流水 ES 索引设计（Mapping）
字段类型、分词、检索场景设计
5个真实高频支付业务查询 DSL
对比 MySQL 为什么做不到
阿里云 DTS 实时同步架构

一、业务场景说明

我们模拟支付系统最核心的表：支付流水表 pay_transaction

日常业务查询场景非常杂乱：

根据手机号、订单号、商户单号模糊搜索订单
按时间、渠道、金额、支付状态多条件组合筛选
排查某时间段支付失败、回调异常订单
财务批量导出流水、深度分页查询
根据备注关键词检索可疑交易（风控）

以上所有场景，MySQL 亿级数据必崩，ES 秒级返回。

二、支付流水 ES 索引创建（生产级 Mapping）

索引名：pay_transaction_log

设计原则：

精准字段（状态、渠道、ID）：不分词，keyword 精确匹配
检索字段（手机号、备注、订单号）：分词/模糊检索
时间、金额：数值类型，用于范围筛选

完整 ES Mapping 语句

java 复制代码

{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "1s"
  },
  "mappings": {
    "properties": {
      "id": {"type": "keyword"},
      "order_no": {"type": "text", "fields": {"keyword": {"type": "keyword", "ignore_above": 64}}},
      "pay_no": {"type": "text", "fields": {"keyword": {"type": "keyword", "ignore_above": 64}}},
      "user_phone": {"type": "text", "fields": {"keyword": {"type": "keyword"}}},
      "merchant_id": {"type": "keyword"},
      "channel_code": {"type": "keyword"},
      "pay_status": {"type": "integer"},
      "refund_status": {"type": "integer"},
      "pay_amount": {"type": "double"},
      "create_time": {"type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
      "callback_result": {"type": "keyword"},
      "remark": {"type": "text"}
    }
  }
}

新增支付流水数据写入

业务需求 ：用户支付成功后，业务侧同步写入ES支付流水文档，用于后续检索查询，完全适配上文定义的 pay_transaction_log 索引结构。

该场景为DTS同步兜底补充，极端DTS延迟场景下，可业务主动写入，保障检索数据实时性。

XML 复制代码

{
  "id": "20260528123456789",
  "order_no": "ORD20260528001001",
  "pay_no": "PAY20260528001001001",
  "user_phone": "13800138000",
  "merchant_id": "MERCHANT2026001",
  "channel_code": "WECHAT",
  "pay_status": 1,
  "refund_status": 0,
  "pay_amount": 99.9,
  "create_time": "2026-05-28 14:30:25",
  "callback_result": "SUCCESS",
  "remark": "微信小程序正常支付"
}

写入方式（POST单条新增）

XML 复制代码

POST /pay_transaction_log/_doc
{
  "id": "20260528123456789",
  "order_no": "ORD20260528001001",
  "pay_no": "PAY20260528001001001",
  "user_phone": "13800138000",
  "merchant_id": "MERCHANT2026001",
  "channel_code": "WECHAT",
  "pay_status": 1,
  "refund_status": 0,
  "pay_amount": 99.9,
  "create_time": "2026-05-28 14:30:25",
  "callback_result": "SUCCESS",
  "remark": "微信小程序正常支付"
}

业务说明：

数据字段完全贴合前文索引Mapping规范，字段类型、格式一一对应，无字段不匹配、写入报错问题；
支付状态、回调结果、渠道编码均使用业务枚举值，贴合真实支付生产场景；
正常业务无需手动写入，依托阿里云DTS自动同步MySQL数据，此写入方式仅用于数据修复、兜底补数、测试验证场景。

✅ ES优势：支持实时单条/批量写入，写入延迟低、适配灵活补数场景

❌ 无需MySQL介入，仅作为数据修复兜底手段，不干预核心事务流程

字段设计解读（支付重点）

order_no、pay_no、user_phone：text+keyword 双类型
- keyword：精准匹配订单号
- text：支持模糊、部分匹配、客服搜单号
remark 备注 text 类型：支持风控关键词检索（刷单、异常、投诉）
时间、金额、状态：数值类型，用于区间筛选、统计聚合
渠道、商户ID：keyword 精准过滤，不分词

三、数据同步架构（阿里云生产标准）

MySQL 不做任何查询，只负责写入事务

通过 阿里云 DTS 实时订阅 MySQL binlog：

INSERT → ES 新增文档
UPDATE → ES 实时覆盖更新
DELETE → ES 删除文档

配合定时5分钟校对任务，保证最终一致性。

四、5个真实支付生产级 ES 查询案例（核心）

下面全部是每天在线运行的真实业务查询，对应客服、运营、风控、财务场景。

案例1：客服模糊查询用户订单（最常用）

业务需求：用户报手机号/部分订单号，模糊匹配所有交易记录

XML 复制代码

{
  "from": 0,
  "size": 10,
  "query": {
    "multi_match": {
      "query": "13800138000",
      "fields": ["user_phone","order_no","pay_no"]
    }
  },
  "sort": [{"create_time":"desc"}]
}

✅ ES 优势：毫秒级模糊检索

❌ MySQL：like %13800% 全表扫描，亿级数据直接超时

案例2：多条件组合筛选（运营后台核心）

业务需求：查询今日微信支付、已支付、金额1-100元的成功订单

XML 复制代码

{
  "from": 0,
  "size": 20,
  "query": {
    "bool": {
      "must": [
        {"term": {"channel_code":"WECHAT"}},
        {"term": {"pay_status":1}},
        {"range": {"pay_amount":{"gte":1,"lte":100}}},
        {"range": {"create_time":{"gte":"2026-05-28 00:00:00","lte":"2026-05-28 23:59:59"}}}
      ]
    }
  },
  "sort": [{"create_time":"desc"}]
}

✅ ES 优势：任意字段自由组合，无需建索引

❌ MySQL：组合条件太多，无法建全覆盖索引，极易全表扫描

案例3：排查支付失败、回调异常订单

业务需求：查询近期支付成功但回调失败的异常订单

XML 复制代码

{
  "query": {
    "bool": {
      "must": [
        {"term":{"pay_status":1}},
        {"term":{"callback_result":"FAIL"}}
      ]
    }
  },
  "sort": [{"create_time":"desc"}]
}

案例4：关键词检索风控可疑订单

业务需求：检索备注中包含"测试、重复、异常"的交易记录

XML 复制代码

{
  "query": {
    "match": {
      "remark": "测试 异常 重复"
    }
  }
}

✅ ES 支持中文分词、关键词匹配

❌ MySQL 完全不支持全文语义检索

案例5：财务大分页流水导出（生产刚需）

业务需求：深度分页导出历史流水（避免MySQL limit深度分页灾难）

XML 复制代码

{
  "size": 1000,
  "search_after": [1620000000000],
  "sort": [{"create_time":"desc"},{"id":"desc"}]
}

✅ ES search_after 无痛深度分页，不崩服务

❌ MySQL limit 100000,1000 超级慢、IO爆炸

五、最终生产架构总结

写操作、资金事务、对账：MySQL（唯一权威）
数据同步：阿里云 DTS 实时 binlog 同步 MySQL→ES
所有查询、检索、排查、导出：统一走 ES
最终一致性兜底：定时任务校对修复

六、总结

通过本文完整实战案例可以看出：ES 在支付不是"锦上添花"，而是刚需。

MySQL 强在事务、资金安全；ES 强在检索、模糊查询、灵活筛选。

一套标准的支付生产架构：

MySQL + 阿里云DTS + ES

满足：高并发、秒级检索、无数据丢失、最终一致、可运维、金融级稳定。

对技术感兴趣的朋友，推荐阅读我今年5月11日上架的《金融支付架构实战指南》新书，拼多多/京东/淘宝/当当有售。