想到两种方案：
一、用企业版打开审计功能
二、TiCDC
这两种有人使用吗，需要注意什么呢？
个人见解，审计日志侧重于安全合规与原始操作追踪，TiCDC 侧重于实时数据同步与行级变更追踪。 如果你的核心需求是安全审计、合规检查、追踪谁在什么时间执行了什么原始 SQL，选择企业版审计日志，如果你的核心需求是数据同步、灾备、或者将行级数据变更推送到下游系统进行历史分析，那就选择 TiCDC。
1 个赞
ticdc应该不能用作审计，监管不认的。
如果组件没混布，负载不高，评估下是否可以开generallog，都说开启消耗资源很大，但是我遇到过开的MySQL库，看着还可以。
TiCDC 无法拿到上游执行的【原始完整 DML SQL】，不能满足合规审计「记录原始 SQL」需求；仅 DDL 可以拿到原始 SQL。
注意下作用域，进每个实例都设置一下。
脱敏 , 操作多吗?
建议优先使用企业版审计功能，配置简单且对性能影响可控。开启方法：在tidb.toml或集群配置中设置 security.enable-audit=true，审计日志默认输出到tidb-audit.log。注意审计会记录所有SQL，生产环境建议按需过滤（如只记录DDL或慢查询），避免日志膨胀影响磁盘。
TiCDC主要用于数据同步，不适合做完整审计。它会记录变更事件（Insert/Update/Delete），但无法捕获查询语句。另外CDC需要额外部署组件，维护成本较高。
线上两种方案都有人使用，简单说下差异： 企业版审计：原生支持抓取完整 SQL（含 SELECT），开箱即用，但社区版没有；高并发场景需要关注存储与性能开销。 TiCDC：社区版可用，只能捕获 DML/DDL 变更数据，无法拿到原始 SQL，也捕获不到 SELECT，更适合数据同步，不能作为全量 SQL 审计方案。
- 企业版原生审计 = 标准合规审计首选（记录原始 SQL、账号、客户端 IP、执行结果、登录 / 权限操作），专门做「操作留痕、溯源、等保合规」；
- TiCDC 本质是「数据行变更同步工具」，拿它当审计属于歪路子，只能拿到最终数据变更结果，拿不到原始执行 SQL、查询语句、DCL、只读操作；
- 生产两种方案都有人在用，但适用场景完全割裂，不能互相替代。
留个痕迹，回来学习
不用脱敏哦，就想记录每条操作记录
可是会产生大量的日志，也会影响性能。官方写着不建议长期开启，可用于临时排查。
开的MySQL库是什么意思呀
我见过开generallog的MySQL库，对系统产生的负载还是可控的。
当然，这个取决于硬件以及业务系统当前的负载。
中中中
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。